Taco, let me discuss it here instead of reopening the issue.
I've decided not to attempt to fix this, there are too many tricky scanning issues surrounding this.
I understand that and I don't want to type explicit invalid UTF-8 strings. Nobody writes binary code from the keyboard I guess :)
If you want to create 8bit strings directly from within a document, create you'll just have to build up the string programmatically.
The point is you actually *cannot* make that programmatically (lpdflib.c:406): if (!lua_isstring(L, -1)) /* !string-s t */ luaL_error(L, "pdf.obj(): \"string\" must be string for stream object"); So once you say pdf.obj{type = "stream", string = string.char(255)} pdf.obj("stream", string.char(255)) you don't use an explicit string, but you still get the error. As shown in note 0000309, moving the stuff to external file is not the complete solution either. Since binary streams are not likely to be valid UTF-8, using \pdfobj or pdf.obj() with "stream" keyword doesn't seem usable at all. But since we're not limited to strings, perhaps pdf stream data could be provided as: -- lua function returning the stream once called? pdf.obj{type = "stream", data = function() return string.char(255) end} -- array of integers representing bytes to be written? pdf.obj{type = "stream", data = {255}} Am I missing some workaround? How do you guys handle it in context? Regards, Paweł -- Pawe/l Jackowski P.Jackowski@gust.org.pl