November 2010 - ntg-pdftex - NTG Mailing Lists

[pdftex-Bugs][4321] Illegal entry in bfrange block in ToUnicode CMap
by pdftex-bugs＠sarovar.org 26 Nov '10

26 Nov '10

Bugs item #4321, was opened at 2010-11-25 15:21 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Illegal entry in bfrange block in ToUnicode CMap Category: None Group: None Resolution: Accepted Initial Comment: Hello, pdfTeX complains Error: Illegal entry in bfrange block in ToUnicode CMap for valid cmap entries, when a PDF file is included. The CMap entries are, for example: 1 beginbfrange <0041><0041><0041> endbfrange The error disappears in case of 1 beginbfrange <41><41><0041> endbfrange The error is in function CharCodeToUnicode::parseCMap1 in file libs/xpdf-3.02/xpdf/CharCodeToUnicode.cc In case of poppler the problem is already reported with patch: http://lists.freedesktop.org/archives/poppler-bugs/2010-April/004931.html The appended test file can be processed by "pdftex --ini", "pdftex" or "pdflatex". Yours sincerely Heiko ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2010-11-26 08:19 Message: ToUnicode is a little odd because it uses CMap syntax with a few extra limitations that are only in the pdf reference, and these seem to come from a really weird bit of Acroread implementation code. I have not looked at the input closely, so I could be missing the point a little, but this could be the problem: The hex number scanning in AR is closely related to the begincodespacerange ... endcodespacerange block. If the code space range is one byte, then all hex numbers have to be specified in two digits, and if the code space range is two bytes, then all further hex numbers have to be given in four digits. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-11-26 03:32 Message: we would apply the mentioned patch from poppler. Regards the case <0041><0041><0042> it works fine with Preview (osx) and acrobat 9, so I think it's a browser issue. Thanh ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2010-11-25 15:48 Message: Hello, I have made further experiments by replacing the last <0041> by <0042>. The "A" of the input file should then get converted to "B" by copy&paste. This works for the line <41><41><0042> with AR7/Linux, however it fails ("A" instead of "B") in case of <0041><0041><0042> The PDF specification shows in section "5.9 Extraction of Text Content" entries with four hexadecimal digits. Can someone bring some light to this obscurity? Yours sincerely Heiko ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4321&group_id=106

1 0

[pdftex-Bugs][4321] Illegal entry in bfrange block in ToUnicode CMap
by pdftex-bugs＠sarovar.org 25 Nov '10

25 Nov '10

Bugs item #4321, was opened at 2010-11-25 14:21 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Illegal entry in bfrange block in ToUnicode CMap Category: None Group: None >Resolution: Accepted Initial Comment: Hello, pdfTeX complains Error: Illegal entry in bfrange block in ToUnicode CMap for valid cmap entries, when a PDF file is included. The CMap entries are, for example: 1 beginbfrange <0041><0041><0041> endbfrange The error disappears in case of 1 beginbfrange <41><41><0041> endbfrange The error is in function CharCodeToUnicode::parseCMap1 in file libs/xpdf-3.02/xpdf/CharCodeToUnicode.cc In case of poppler the problem is already reported with patch: http://lists.freedesktop.org/archives/poppler-bugs/2010-April/004931.html The appended test file can be processed by "pdftex --ini", "pdftex" or "pdflatex". Yours sincerely Heiko ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-11-26 02:32 Message: we would apply the mentioned patch from poppler. Regards the case <0041><0041><0042> it works fine with Preview (osx) and acrobat 9, so I think it's a browser issue. Thanh ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2010-11-25 14:48 Message: Hello, I have made further experiments by replacing the last <0041> by <0042>. The "A" of the input file should then get converted to "B" by copy&paste. This works for the line <41><41><0042> with AR7/Linux, however it fails ("A" instead of "B") in case of <0041><0041><0042> The PDF specification shows in section "5.9 Extraction of Text Content" entries with four hexadecimal digits. Can someone bring some light to this obscurity? Yours sincerely Heiko ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4321&group_id=106

1 0

[pdftex-Bugs][4321] Illegal entry in bfrange block in ToUnicode CMap
by pdftex-bugs＠sarovar.org 25 Nov '10

25 Nov '10

Bugs item #4321, was opened at 2010-11-25 15:21 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Illegal entry in bfrange block in ToUnicode CMap Category: None Group: None Resolution: None Initial Comment: Hello, pdfTeX complains Error: Illegal entry in bfrange block in ToUnicode CMap for valid cmap entries, when a PDF file is included. The CMap entries are, for example: 1 beginbfrange <0041><0041><0041> endbfrange The error disappears in case of 1 beginbfrange <41><41><0041> endbfrange The error is in function CharCodeToUnicode::parseCMap1 in file libs/xpdf-3.02/xpdf/CharCodeToUnicode.cc In case of poppler the problem is already reported with patch: http://lists.freedesktop.org/archives/poppler-bugs/2010-April/004931.html The appended test file can be processed by "pdftex --ini", "pdftex" or "pdflatex". Yours sincerely Heiko ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2010-11-25 15:48 Message: Hello, I have made further experiments by replacing the last <0041> by <0042>. The "A" of the input file should then get converted to "B" by copy&paste. This works for the line <41><41><0042> with AR7/Linux, however it fails ("A" instead of "B") in case of <0041><0041><0042> The PDF specification shows in section "5.9 Extraction of Text Content" entries with four hexadecimal digits. Can someone bring some light to this obscurity? Yours sincerely Heiko ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4321&group_id=106

1 0

[pdftex-Bugs][4321] Illegal entry in bfrange block in ToUnicode CMap
by pdftex-bugs＠sarovar.org 25 Nov '10

25 Nov '10

Bugs item #4321, was opened at 2010-11-25 15:21 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Illegal entry in bfrange block in ToUnicode CMap Category: None Group: None Resolution: None Initial Comment: Hello, pdfTeX complains Error: Illegal entry in bfrange block in ToUnicode CMap for valid cmap entries, when a PDF file is included. The CMap entries are, for example: 1 beginbfrange <0041><0041><0041> endbfrange The error disappears in case of 1 beginbfrange <41><41><0041> endbfrange The error is in function CharCodeToUnicode::parseCMap1 in file libs/xpdf-3.02/xpdf/CharCodeToUnicode.cc In case of poppler the problem is already reported with patch: http://lists.freedesktop.org/archives/poppler-bugs/2010-April/004931.html The appended test file can be processed by "pdftex --ini", "pdftex" or "pdflatex". Yours sincerely Heiko ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4321&group_id=106

1 0

[pdftex-Bugs][4315] pdftex manual is not up-to-date
by pdftex-bugs＠sarovar.org 16 Nov '10

16 Nov '10

Bugs item #4315, was opened at 2010-07-30 08:49 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: pdftex manual is not up-to-date Category: Documentation Group: None Resolution: Accepted Initial Comment: The manual needs some correction: \pdfelapsedtime: poor wording \letterspacefont: missing \pdfinclusioncopyfonts: missing ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2010-11-16 22:50 Message: FYI: The manual in the qstex branch has some updates. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-09-17 09:05 Message: \pdfstrcmp: missing ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4315&group_id=106

1 0

[pdftex-Support Requests][4319] jbig2 resolution
by pdftex-supportrequests＠sarovar.org 09 Nov '10

09 Nov '10

Support Requests item #4319, was opened at 2010-11-06 13:18 Status: Open Priority: 3 Submitted By: Boris Okun (okun) Assigned to: Nobody (None) Summary: jbig2 resolution Category: None Group: None Resolution: None Initial Comment: When including a jbig2enc generated file, the x,y-resolutions seem to be completely off. I think the problem is with the lines 701-702 in writejbig2.c img_xres(img) = (int) (pip->xres * 0.0254 + 0.5); img_yres(img) = (int) (pip->yres * 0.0254 + 0.5); The file has resolution set to 600dpi, according to my hex browser, if I manually change it to 600/0.0254=2362, I get the expected output. Or, perhaps, I and/or jbig2enc misunderstand the format of jbig2 files. Thanks, Boris ---------------------------------------------------------------------- Comment By: Boris Okun (okun) Date: 2010-11-09 19:43 Message: Hartmut, Thank you for the exhaustive explanation. It looks like a bug in jbig2enc. Boris ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2010-11-09 14:59 Message: The parameters img_xres(img) and img_yres(img) are handled in pixels/inch within pdftex (see also calculations for PNG ang JPG images). The JBIG2 standard (file fcd14492.pdf) specifies in section 7.4.8.3 and 7.4.8.4 that the resolution must be stated in pixels/meter (not inch!). You expect your JBIG2 file to have a resolution of 600 dpi; when you divide by 0.0254, you get pixels/meter. So in your JBIG2 file there should indeed be 23622 as resolution, not 600. It looks as if there is some calculation bug when generating the JBIG2 file. ---------------------------------------------------------------------- Comment By: Boris Okun (okun) Date: 2010-11-08 08:14 Message: I am attaching: original: tetra.tiff compressed: jbig2 -s tetra.tiff > tetra.jbig2 tex: tetra.tex Thanks for looking into this, Boris ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-11-08 06:26 Message: can you please attach the image? Regards, Thanh ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4319&group_id=106

1 0

[pdftex-Support Requests][4319] jbig2 resolution
by pdftex-supportrequests＠sarovar.org 09 Nov '10

09 Nov '10

Support Requests item #4319, was opened at 2010-11-06 19:18 Status: Open Priority: 3 Submitted By: Boris Okun (okun) Assigned to: Nobody (None) Summary: jbig2 resolution Category: None Group: None Resolution: None Initial Comment: When including a jbig2enc generated file, the x,y-resolutions seem to be completely off. I think the problem is with the lines 701-702 in writejbig2.c img_xres(img) = (int) (pip->xres * 0.0254 + 0.5); img_yres(img) = (int) (pip->yres * 0.0254 + 0.5); The file has resolution set to 600dpi, according to my hex browser, if I manually change it to 600/0.0254=2362, I get the expected output. Or, perhaps, I and/or jbig2enc misunderstand the format of jbig2 files. Thanks, Boris ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2010-11-09 21:59 Message: The parameters img_xres(img) and img_yres(img) are handled in pixels/inch within pdftex (see also calculations for PNG ang JPG images). The JBIG2 standard (file fcd14492.pdf) specifies in section 7.4.8.3 and 7.4.8.4 that the resolution must be stated in pixels/meter (not inch!). You expect your JBIG2 file to have a resolution of 600 dpi; when you divide by 0.0254, you get pixels/meter. So in your JBIG2 file there should indeed be 23622 as resolution, not 600. It looks as if there is some calculation bug when generating the JBIG2 file. ---------------------------------------------------------------------- Comment By: Boris Okun (okun) Date: 2010-11-08 15:14 Message: I am attaching: original: tetra.tiff compressed: jbig2 -s tetra.tiff > tetra.jbig2 tex: tetra.tex Thanks for looking into this, Boris ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-11-08 13:26 Message: can you please attach the image? Regards, Thanh ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4319&group_id=106

1 0

[pdftex-Support Requests][4319] jbig2 resolution
by pdftex-supportrequests＠sarovar.org 08 Nov '10

08 Nov '10

Support Requests item #4319, was opened at 2010-11-06 13:18 Status: Open Priority: 3 Submitted By: Boris Okun (okun) Assigned to: Nobody (None) Summary: jbig2 resolution Category: None Group: None Resolution: None Initial Comment: When including a jbig2enc generated file, the x,y-resolutions seem to be completely off. I think the problem is with the lines 701-702 in writejbig2.c img_xres(img) = (int) (pip->xres * 0.0254 + 0.5); img_yres(img) = (int) (pip->yres * 0.0254 + 0.5); The file has resolution set to 600dpi, according to my hex browser, if I manually change it to 600/0.0254=2362, I get the expected output. Or, perhaps, I and/or jbig2enc misunderstand the format of jbig2 files. Thanks, Boris ---------------------------------------------------------------------- Comment By: Boris Okun (okun) Date: 2010-11-08 08:14 Message: I am attaching: original: tetra.tiff compressed: jbig2 -s tetra.tiff > tetra.jbig2 tex: tetra.tex Thanks for looking into this, Boris ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-11-08 06:26 Message: can you please attach the image? Regards, Thanh ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4319&group_id=106

1 0

[pdftex-Bugs][4320] DVI mode ignores draftmode
by pdftex-bugs＠sarovar.org 08 Nov '10

08 Nov '10

Bugs item #4320, was opened at 2010-11-08 12:31 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: DVI mode ignores draftmode Category: None Group: None Resolution: None Initial Comment: http://www.ntg.nl/pipermail/ntg-pdftex/2010-November/003930.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4320&group_id=106

1 0

[pdftex-Support Requests][4319] jbig2 resolution
by pdftex-supportrequests＠sarovar.org 08 Nov '10

08 Nov '10

Support Requests item #4319, was opened at 2010-11-06 18:18 Status: Open Priority: 3 Submitted By: Boris Okun (okun) Assigned to: Nobody (None) Summary: jbig2 resolution Category: None Group: None Resolution: None Initial Comment: When including a jbig2enc generated file, the x,y-resolutions seem to be completely off. I think the problem is with the lines 701-702 in writejbig2.c img_xres(img) = (int) (pip->xres * 0.0254 + 0.5); img_yres(img) = (int) (pip->yres * 0.0254 + 0.5); The file has resolution set to 600dpi, according to my hex browser, if I manually change it to 600/0.0254=2362, I get the expected output. Or, perhaps, I and/or jbig2enc misunderstand the format of jbig2 files. Thanks, Boris ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-11-08 12:26 Message: can you please attach the image? Regards, Thanh ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4319&group_id=106

1 0