Re: [Dev-luatex] [luatex 0000283]: PDF streams data should not be validated in UTF-8 regime
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
Paweł Jackowski wrote:
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.
can't you use the Output in byte-sized chunks can be achieved by using characters just outside of the valid Unicode range, starting at the value 1;114;112 (0x110000). When the times comes to print a character c> = 1;114;112, LuaTEX will actually print the single byte corresponding to c minus 1,114,112. trick?
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}}
brrr
Am I missing some workaround? How do you guys handle it in context?
what exactly do you want to write to the pdf? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
can't you use the
Output in byte-sized chunks can be achieved by using characters just outside of the valid Unicode range, starting at the value 1;114;112 (0x110000). When the times comes to print a character c> = 1;114;112, LuaTEX will actually print the single byte corresponding to c minus 1,114,112.
trick?
Meybe, but dunno how to use it for pdf stream generated on my own.
what exactly do you want to write to the pdf?
Lets take pdf function -- /FunctionType 0 -- a continuous sequence of bits forming arbitrary bytes. Or take a lookup of /Indexed color spaces that may also contain arbitrary data. How would you write byte 255 to those streams? I cannot find anything smarter then dumping the data to some external file and let luatex load it from there using "file" keyword. -- Pawe/l Jackowski P.Jackowski@gust.org.pl
Hi, Paweł Jackowski wrote:
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.
This error we can avoid with a simple patch to luatex. Currently the stream is still converted to a token list, while there is absolutely no reason to do so. Reopened the tracker Best wishes, Taco
Taco Hoekwater wrote:
Hi,
Paweł Jackowski wrote:
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.
This error we can avoid with a simple patch to luatex.
Currently the stream is still converted to a token list, while there is absolutely no reason to do so.
And will be just perfect!
-- 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}}
brrr
And then absolutely agree with Hans brrr ;) Thank you, Paweł -- Pawe/l Jackowski P.Jackowski@gust.org.pl
On Fri, 20 Nov 2009, Taco Hoekwater wrote:
Pawe? Jackowski wrote:
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.
This error we can avoid with a simple patch to luatex.
Currently the stream is still converted to a token list, while there is absolutely no reason to do so.
Reopened the tracker
fwiw, pdf.obj{type = "stream", immediate=true, string = string.char(255)} should already work (no token list used). i'll try to fix the non-immediate case (likely by luaL_ref()). Regards, Hartmut
Hi, Hartmut Henkel wrote:
On Fri, 20 Nov 2009, Taco Hoekwater wrote:
Pawe? Jackowski wrote:
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. This error we can avoid with a simple patch to luatex.
Currently the stream is still converted to a token list, while there is absolutely no reason to do so.
Reopened the tracker
fwiw,
pdf.obj{type = "stream", immediate=true, string = string.char(255)}
should already work (no token list used). i'll try to fix the non-immediate case (likely by luaL_ref()).
I hope you don't mind that I fixed it. I want to release 0.46 this afternoon. Best wishes, Taco
Hartmut
should already work (no token list used). i'll try to fix the non-immediate case (likely by luaL_ref()).
Taco
I hope you don't mind that I fixed it. I want to release 0.46 this afternoon.
Both immediate and non-immediate cases works perfect. Thank you! -- Pawe/l Jackowski P.Jackowski@gust.org.pl
participants (4)
-
Hans Hagen -
Hartmut Henkel -
Paweł Jackowski -
Taco Hoekwater