- ntg-pdftex - NTG Mailing Lists

OMG WTF PDF
by Martin Schröder 31 Dec '10

31 Dec '10

https://events.ccc.de/congress/2010/Fahrplan/attachments/1649_Sec-T_2010_Ju… https://events.ccc.de/congress/2010/Fahrplan/events/4221.en.html Executive summary: JavaScript in PDF is a security nightmare; most PDF parsers are thoroughly broken. Best Martin

2 5

[pdftex-Bugs][4324] pdflatex incorrectly removes an embedded font
by pdftex-bugs＠sarovar.org 20 Dec '10

20 Dec '10

Bugs item #4324, was opened at 2010-12-19 22:58 Status: Closed Priority: 3 Submitted By: Alan Munn (alan) Assigned to: Nobody (None) Summary: pdflatex incorrectly removes an embedded font Category: PDF inclusion Group: None Resolution: Duplicate Initial Comment: The following arose from a discussion the the TeX on MacOS X mailing list. The attached tex file, (cyr-test.tex) which includes a single page pdf document (cyryllic-page.pdf) using pdfpages, removes one of the embedded fonts (which so happens to include the cyrillic text in the original) The resulting pdf therefore is not identical to the included pdf, although it should be. The same document, compiled with xelatex does not have this problem. The original included file contains two embedded versions of CenturySchl-Bold, one with a Roman encoding and the other with a Custom encoding. Only the custom encoded font remains in the pdflatexed version of the same file. I am not the original creator of the source file, and it's unclear how it was originally created (although I don't think this should matter.) ---------------------------------------------------------------------- Comment By: Alan Munn (alan) Date: 2010-12-20 11:45 Message: Ok. Thanks for the workarounds. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-12-20 06:18 Message: this is a duplicate of http://sarovar.org/tracker/?func=detail&group_id=106&aid=4014&atid=493 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4324&group_id=106

1 0

[pdftex-Bugs][4324] pdflatex incorrectly removes an embedded font
by pdftex-bugs＠sarovar.org 20 Dec '10

20 Dec '10

Bugs item #4324, was opened at 2010-12-19 22:58 >Status: Closed Priority: 3 Submitted By: Alan Munn (alan) Assigned to: Nobody (None) Summary: pdflatex incorrectly removes an embedded font Category: PDF inclusion Group: None >Resolution: Duplicate Initial Comment: The following arose from a discussion the the TeX on MacOS X mailing list. The attached tex file, (cyr-test.tex) which includes a single page pdf document (cyryllic-page.pdf) using pdfpages, removes one of the embedded fonts (which so happens to include the cyrillic text in the original) The resulting pdf therefore is not identical to the included pdf, although it should be. The same document, compiled with xelatex does not have this problem. The original included file contains two embedded versions of CenturySchl-Bold, one with a Roman encoding and the other with a Custom encoding. Only the custom encoded font remains in the pdflatexed version of the same file. I am not the original creator of the source file, and it's unclear how it was originally created (although I don't think this should matter.) ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-20 06:18 Message: this is a duplicate of http://sarovar.org/tracker/?func=detail&group_id=106&aid=4014&atid=493 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4324&group_id=106

1 0

[pdftex-Bugs][4324] pdflatex incorrectly removes an embedded font
by pdftex-bugs＠sarovar.org 19 Dec '10

19 Dec '10

Bugs item #4324, was opened at 2010-12-19 22:58 Status: Open Priority: 3 Submitted By: Alan Munn (alan) Assigned to: Nobody (None) Summary: pdflatex incorrectly removes an embedded font Category: PDF inclusion Group: None Resolution: None Initial Comment: The following arose from a discussion the the TeX on MacOS X mailing list. The attached tex file, (cyr-test.tex) which includes a single page pdf document (cyryllic-page.pdf) using pdfpages, removes one of the embedded fonts (which so happens to include the cyrillic text in the original) The resulting pdf therefore is not identical to the included pdf, although it should be. The same document, compiled with xelatex does not have this problem. The original included file contains two embedded versions of CenturySchl-Bold, one with a Roman encoding and the other with a Custom encoding. Only the custom encoded font remains in the pdflatexed version of the same file. I am not the original creator of the source file, and it's unclear how it was originally created (although I don't think this should matter.) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4324&group_id=106

1 0

[pdftex-Patches][2087] Support for CMap namespaces
by pdftex-patches＠sarovar.org 19 Dec '10

19 Dec '10

Patches item #2087, was opened at 2008-08-28 08:17 Status: Open Priority: 3 Submitted By: Vasile Gaburici (vga) Assigned to: The Thanh Han (hanthethanh) Summary: Support for CMap namespaces Category: Fonts Group: v1.40.0 Resolution: Accepted Initial Comment: There are a couple of LaTeX packages out there (cmap and mmap) that provide CMaps. They don't work as well as \pdfglyphtounicode, i.e. virtual fonts don't get CMaps at all (the CMap is included in the PDF but not referenced), and otftotfm-installed fonts lack the CMap entries for the ligatures that otftotfm sneaks in empty slots. As you know, \pdfglyphtounicode fixes these problems. On the other hand, these two packages let the user specify a CMap for each LaTeX encoding, so the user ca give different Unicode values to the same PS glyph name in different LaTeX encodings. Of course that works properly only if the fonts invoked by the different LaTeX encodings are different; otherwise only one can win the \pdffontattr. A compelling application of this feature are CMaps that set math code points (usually above BMP) for TeX math fonts; those glyphs have exactly the same names as in text fonts /A etc. Adding namespaces to \pdfglyphtounicode makes those two packages obsolete in their current implementation. Another advantage of namespaces is the ability to (reliably) fix TrueType font CMaps. The troublesome glyphs are usually ligatures that don't have a Unicode entry (Th, ti, tf, ffb, etc.), which otftotfm writes as /indexZZZ in the enc file. Putting those in a per-font namespace avoids any potential clashes. So, I've patched pdftex to provide namespaces using the following syntax extension: the first argument of \pdfglyphtounicode can now take additional forms: \pdfglyphtounicode{fnt:tex-font-name/ps-glyph-name}{...} \pdfglyphtounicode{enc:ps-enc-name/ps-glyph-name}{...} Since fonts for which the built-in encoding is used happen to be exactly those that have multiple design sizes (cmr, stmary etc.), using a separate ps-enc-name for each is not helpful. Instead, the 'enc' namespace for those is obtained by dropping any final digits from the font name, e.g. cmr10 has PS encoding cmr (for CMap purposes only). The search policy is to first search the font namespce, then the encoding, and finally the global namespace, for which the syntax remains unchanged. All these namespace are implemented in the same avl tree; just using the above strings as key names. In theory this makes the search 3 times slower, but that particular phase of pdftex hardly takes any time, so it seemed premature to implement any optimization. Some usage examples: % make the ti ligature searchable in Calibri regular \pdfglyphtounicode{fnt:calibly1--base/index415}{0074 0069} % go crazy with Unicode math; TeX math italic gives above-BMP math A \pdfglyphtounicode{enc:cmmi/A}{D835 DC34} % UTF16BE required Note that search behavior for math letters varies with pdf viewers. Acrobat implements only canonical equivalence, so you need to enter the exact code point, and copy/paste preserves the code points, so you can paste into a LaTeX document if it's using utf8x input encoding. Evince implements compatibility equivalence, so it's easier to find those math As by searching for plain A, but they also copy/paste as plain A. You can use pdftotext however, which uses the same poppler backend, to have the code points are preserved. I'm not really advocating Unicode math letters, but now they're easily supported in pdftex -- no need for manual CMaps anymore. BTW, \pdfglyphtounicode now really needs to be documented in the manual, so people would stop writing (buggy) CMaps by hand. I volunteer to do it if you accept the patch :) ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-19 06:45 Message: patch updated to allow fontfile namespace, as suggested by Eddie Kohler. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-09-08 08:36 Message: re-open this case, since the "enc" namespace seems useful and would make glyphtounicode.tex simpler. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 22:02 Message: included in 1.40.10 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-07 14:59 Message: this patch is indeed very useful, however adding tfm namespace support is enough since it can cover the other case. I have changed the patch slightly to: - drop the enc: case - use "tfm:" instead of "fnt:" as the tfm namespace prefix And added a small test file. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=2087&group_id=106

1 0

[pdftex-Feature Requests][317] Add spaces to PDF file so reflow works..
by pdftex-featurerequests＠sarovar.org 19 Dec '10

19 Dec '10

Feature Requests item #317, was opened at 2005-03-23 12:43 Status: Open Priority: 3 Submitted By: David Hedley (davidhedley) Assigned to: Nobody (None) Summary: Add spaces to PDF file so reflow works.. Category: None Group: None Resolution: None Initial Comment: Current PDFs generated by pdfTex do not 'reflow' properly with Acrobat Reader - selecting 'reflow' causes all the words to run together. This appears to be because pdfTex uses explicit kerns for spaces instead of including the space character in the text string. Is it possible to change this? (perhaps by including a space in the text string and adjusting the explicit kern by the width of the space) ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-19 04:14 Message: this has been done in svn branch tagged-pdf ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-06-28 14:22 Message: patch 945 does this. Needs more testing. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=317&group_id=106

1 0

[pdftex-Feature Requests][429] Generate Tagged PDF
by pdftex-featurerequests＠sarovar.org 19 Dec '10

19 Dec '10

Feature Requests item #429, was opened at 2005-09-11 22:37 >Status: Closed Priority: 2 Submitted By: Timothy O'Brien (oberon101) Assigned to: Martin Schröder (oneiros) Summary: Generate Tagged PDF Category: None Group: None Resolution: None Initial Comment: Adobe Reader has a'reflow' feature that allows visually impaired users to zoom into properly formatted documents and read them without having to move the viewable area back and forth across the page. PDFs made in MikteX eith pdfte are not properly formatted and reflow without interword spacing, redering them unreadable. I contacted the MikteX people and they referred me here. I beleive Scientific Word also uses pdftex with the same result. Any chance this could be fixed? ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-19 04:12 Message: see svn branch tagged-pdf at supelec ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-04-27 10:22 Message: here is an attempt: http://sarovar.org/tracker/index.php?func=detail&aid=945&group_id=106&atid=… ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-05-16 11:49 Message: Logged In: NO " The main problem with reflowing is not the missing tags but that pdftex writes interword spaces as a kern (since there is no "space" in TeX, of course). " No, the main problem is that Adobe Reader dropped recognition of "words" based on *spacing* and resorted to the the simplistic approach to use *spaces* instead. This is simply ignorance of Adobe about TeX. Instead of whining about this one can do something for a practical cure: add dummy spaces at the end of every word of zero width which consist of a *space* and a kern -\wd(space). space could come from any font producing explicit spaces in the output (e.g. cmtt). It is most easily done with VF's. As far as I remember a real implementation is already there in Vtex (with some option). " non-trivial: - first pdfTeX would have to be extended with primites for a structure tree (and classes and packages would have to use these primitives) - then primitives for tagging the content are needed and must be used " i) when generating PS-code and distilling via Adobe Distiller there should be no problem to take care of pdfmarks created by classes & packages... ii) I consider the major problem is page building and page dependency of marked contents. It is just like the difficulty to get consistent color in TeX: one can consider color as sort of a "tag". E.g. a marked TeX paragraph is broken accross pages with (tagged) headers and the structure should in general kept linked also under the condition of reordered pages. I suggest first to define what functionality is required at the side of the PDF-Reader (text extraction, save as XML or audio output via screen reader). The packages should then be able to save Latex macro structure as pdfmarks for pdf tags as a prerequisite. Support of pagebreaking of tagged objects will require some assistance from pdftex like linebreaking of weblinks. HS ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-05-06 15:20 Message: Logged In: YES user_id=2217 The main problem with reflowing is not the missing tags but that pdftex writes interword spaces as a kern (since there is no "space" in TeX, of course). A rather simple but effective way would be to write the interword spaces in a different font (e.g. non-embedded Times-Roman), and then compensate for the difference between Times's width of space and the width of the glue calculated by TeX. (At least, this is what Distiller does, if you select "Advanced -> Accessibility -> Add Tags to Document".) So that (This)-419(is)-420(an)-419(example) will be turned into: /T1_0 1 Tf (This)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 2.369 0 Td (is)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 1.092 0 Td (an)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 1.475 0 Td (example)Tj where T1_0 is cmr10 and T1_1 is Times-Roman. This would be already a major enhancement with respect to accessibility without any packages being required. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-04-14 11:33 Message: Logged In: NO Maybe a first version can use a very low-level solution, just with a single tagging primitive; there is such a command already (I think it is called pdfliteral) . And the tree can come later. So one could start with little work, assuming one knows tagging. CS ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-04-14 11:12 Message: Logged In: YES user_id=421 I'm changing the summary. Yes, we are aware that tagged pdf is an often requested feature, but implementing it would be non-trivial: - first pdfTeX would have to be extended with primites for a structure tree (and classes and packages would have to use these primitives) - then primitives for tagging the content are needed and must be used ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-11-04 19:58 Message: Logged In: NO I would volonteer to test the feature. I am writing a rather long pdf produced with pdftex that is downloadable for free ( http://www.motionmountain.net ) and readers regularly ask why it cannot be read aloud. Pdftex probably would only need to be extended with a single command - something like \writetaghere{tagtype} - and all the rest could be done by extensions to the latex cls and sty files. CS ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=429&group_id=106

1 0

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

19 Dec '10

Support Requests item #4319, was opened at 2010-11-06 18:18 >Status: Closed Priority: 3 Submitted By: Boris Okun (okun) Assigned to: Nobody (None) Summary: jbig2 resolution Category: None Group: None >Resolution: Invalid 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-10 01: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 20: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 14: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 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

[pdftex-Patches][474] Use dynamically linked poppler library instead of xpdf code
by pdftex-patches＠sarovar.org 19 Dec '10

19 Dec '10

Patches item #474, was opened at 2006-01-30 16:53 >Status: Closed Priority: 3 Submitted By: Frank Küster (frank) Assigned to: Martin Schröder (oneiros) Summary: Use dynamically linked poppler library instead of xpdf code Category: PDF inclusion Group: v1.30.0 Resolution: Accepted Initial Comment: This has already been applied and tested in Debian and Ubuntu, but we suggest to apply it upstream. There are a few things to do, however, as Martin already pointed out to me in a private mail. I paraphrase the main points: - the pdftex distribution should not ship libpoppler. Instead it should be possible to switch from xpdf to libpoppler using autoconf magic, if libpoppler headers are installed. This needs some coding work - We need a common API for xpdf and poppler. This is the tricky part, because the very reason for poppler's existence is that the xpdf developer, Derek Noonburg, refuses any patches that would lead to a shared library. As Martin said, "for the beginning, a header file with a couple of #ifdef'ed definitions should be enough". I'm going to subscribe to the pdftex devel list soon, but am not yet subscribed currently. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-08-10 13:40 Message: Logged In: YES user_id=421 HEAD (r228) has now a layer between pdftex and xpdf. Please comment. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-08 16:54 Message: Logged In: YES user_id=421 Just an update: SUSE has also started switching to poppler. My idea is to first add an abstraction layer for xpdf/poppler/... and then add the autofoo stuff. ---------------------------------------------------------------------- Comment By: Frank Küster (frank) Date: 2006-08-14 19:20 Message: Logged In: YES user_id=3360 Hi Martin, this is clearly post-1.40, I agree. I have not worked on any autofoo stuff, and I won't be able to do that soon (instead, I try to integrate pdftex-1.40 into teTeX 3.0 which proved to be non-trivial). Regards, Frank ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-13 20:02 Message: Logged In: YES user_id=421 Frank, have you done any further work on this? I just had a first look at integrating poppler and see a very different use of configure... :-{ Also your diff only patches the sources, but not the autofoo-stuff. What I want is: - a distribution of poppler in src/libs, which can be used instead of xpdf - a way to switch bewteen xpdf and poppler via configure - for poppler to be able to switch between static and dynamic via configure - and finally, a header file abstracting poppler/xpdf would be nice, but is not really needed, as poppler/xpdf are only used by two source files. Best Martin ---------------------------------------------------------------------- Comment By: Frank Küster (frank) Date: 2006-02-13 07:58 Message: Logged In: YES user_id=3360 I agree that this is something to think over and check very well, so better not push it into 1.40. But I'd appreciate if someone could answer my mail to ntg-pdftex regarding the autoconf setup in pdftex, or if you could tell me whom to ask specifically if nobody among the active developers knows about it. See you in Berlin, Frank ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 00:50 Message: Logged In: YES user_id=421 I've attached the patch by Frank from http://www.ntg.nl/pipermail/ntg-pdftex/2006-February/001993.html ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 00:46 Message: Logged In: YES user_id=421 This is too late for 1.40, so I'll postpone it. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106

1 0

[pdftex-Patches][945] experimental support for tagged PDF
by pdftex-patches＠sarovar.org 19 Dec '10

19 Dec '10

Patches item #945, was opened at 2008-04-27 10:19 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: experimental support for tagged PDF Category: Primitives Group: v1.40.0 Resolution: None Initial Comment: This is a patch to experiment with tagged PDF. The example passes PDF/A-1a check in Acrobat Pro 8. Most of the work is done manually at macro level; we want to provide only unavoidable low-level support and new primitives. This is in very alpha stage and is intended for those who are willing to experiment with tagged PDF: you need to know about tagged PDF at low level (chapter 10 from PDF specification), about the \pdfobj primitive of pdftex and some macro programing experience. Please don't try it yet if you want an out-of-the-box solution, since it's not clear yet if it is possible at all. - apply the patch: - unpack pdftex-1.40.4.tar.bz2 - cd /path/to/pdftex.1.40.4 - patch -p1 </path/to/tagged-pdf-1.diff - build pdftex & generate new format - run "pdflatex -shell-escape f.tex" to compile the test file ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-19 04:08 Message: a branch was opened instead. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-11-23 16:07 Message: patch updated to apply cleanly with 1.40.9 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-05 20:24 Message: patch updated -- some minor fixes ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-04 21:18 Message: added primitives \pdfstartstructelem + \pdfendstructelem, and an example. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-02 07:05 Message: forgot to include a file in the last zip -- fixed now. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-01 19:58 Message: added another example, based on sample2e.tex. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-01 15:31 Message: added another example, based on small2e.tex ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-04-30 10:18 Message: added a little less trivial example f2.tex which closely mimics example 10.15 from pdf1.7 spec. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=945&group_id=106

1 0

[pdftex-Patches][4299] pdf font inclusion error (with partial patch)
by pdftex-patches＠sarovar.org 19 Dec '10

19 Dec '10

Patches item #4299, was opened at 2009-11-27 10:03 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: pdf font inclusion error (with partial patch) Category: PDF inclusion Group: None Resolution: Accepted Initial Comment: http://www.ntg.nl/pipermail/ntg-pdftex/2009-November/003859.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-19 04:05 Message: patch applied since 1.40.11 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-04-10 21:23 Message: could you please attach such a pdf for testing? The latest version of easypdf (6.0) no longer produces such odd pdfs, and I could not find 4.2 anywhere. thanks. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-12-24 10:38 Message: in earlier versions of pdf spec, values in named resources must be indirect object, hence the test isRef(). I looked into the current pdf spec and it seems the above requirement is gone, not sure from which version of pdf. So we can leave out that test now. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=4299&group_id=106

1 0

[pdftex-Patches][4301] Patch to detect/prevent wrong arguments of \pdfsetmatrix
by pdftex-patches＠sarovar.org 19 Dec '10

19 Dec '10

Patches item #4301, was opened at 2009-12-23 15:33 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to detect/prevent wrong arguments of \pdfsetmatrix Category: Primitives Group: None Resolution: Accepted Initial Comment: from Hartmut: ,--------, please have a look what this file produces: \nopagenumbers \pdfcompresslevel=0 \pdfsetmatrix{1 2 3 4 5 6} \bye ...it's an invalid "cm". I accidentally typed 6 components instead of 4, but i guess that this user error should be caught. `--------` and Heiko's reply: ,--------, I have attached a patch that should fix it: * In case of unrecognized formats the literal isn't output. * The warning is fixed and moved to pdftex.web. `--------` Patch by Heiko is attached. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-19 04:04 Message: patch applied since 1.40.11 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=4301&group_id=106

1 0

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

19 Dec '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-12-19 03:44 Message: fixed in svn stable ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2010-11-26 07: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 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][4316] glyphtounicode.tex contains wrong entries
by pdftex-bugs＠sarovar.org 19 Dec '10

19 Dec '10

Bugs item #4316, was opened at 2010-08-02 07:23 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: glyphtounicode.tex contains wrong entries Category: Fonts Group: None Resolution: Accepted Initial Comment: Date: Sun, 1 Aug 2010 00:39:36 +0100 (BST) From: "Dr. Clea F. Rees" <cfrees(a)imapmail.org> ... should glyphtounicode.tex be using: {precedesequal}{2AAF} {followsequal}{2AB0} rather than mapping these to 227C and 227D? glyphtounicode.tex seems to disagree with both STIX and fontforge, as well as Hirwen. I think 227C and 227D correspond to characters in AMS MS A: {precedesorcurly}{227C} {followsorcurly}{227D} rather than the characters in OMS. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-19 02:16 Message: glyphtounicode.tex has been much improved and is being maintained by Eddie Kohler now. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4316&group_id=106

1 0

[pdftex-Bugs][4314] \ifincsname nesting bug
by pdftex-bugs＠sarovar.org 19 Dec '10

19 Dec '10

Bugs item #4314, was opened at 2010-07-27 05:47 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: \ifincsname nesting bug Category: Primitives Group: None Resolution: Accepted Initial Comment: from http://tug.org/pipermail/pdftex/2010-July/008439.html ,--------, | Hi, | | This was reported on the XeTeX mailing list but I'm reposting here since I think it's more appropriate for this list. (Fixes to pdfTeX can then propagate to the other engine(s).) | | Here's a minimal example: | | \def\a{\ifincsname T \else F \fi} | \expandafter\string\csname | 1\a | \expandafter\string\csname2\a\endcsname | 3\a | \endcsname | | #1 and #2 are "true" but #3 is "false". It seems like the first \endcsname has reset the "am i in a csname" switch rather than popped it back to its previous value. | | Cheers, | -- Will `--------` ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-19 02:14 Message: fixed in pdftex svn stable ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4314&group_id=106

1 0

[pdftex-Bugs][4322] "\vadjust pre" inside \halign
by pdftex-bugs＠sarovar.org 19 Dec '10

19 Dec '10

Bugs item #4322, was opened at 2010-12-11 20:10 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: "\vadjust pre" inside \halign Category: None Group: None Resolution: Accepted Initial Comment: Hello, there is a segmentation fault if "\vadjust pre" is used inside \halign % pdftex -ini \catcode`\{=1 \catcode`\}=2 \catcode`\#=6 \halign{#\cr\vadjust pre{}\cr} \end % pdflatex \documentclass{article} \begin{document} \begin{tabular}{l} \hline \vadjust pre{\kern10mm} \end{tabular} \end{document} Yours sincerely ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-19 00:19 Message: yes it can be changed to confusion("pre vadjust"). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2010-12-18 08:18 Message: Looks ok to me (the pdf_error could be an assertion?) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-12-17 13:39 Message: here is a patch against pdftex svn stable branch. Testing/comments welcome. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4322&group_id=106

1 0

[pdftex-Bugs][4322] "\vadjust pre" inside \halign
by pdftex-bugs＠sarovar.org 18 Dec '10

18 Dec '10

Bugs item #4322, was opened at 2010-12-11 21:10 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) >Summary: "\vadjust pre" inside \halign Category: None Group: None Resolution: Accepted Initial Comment: Hello, there is a segmentation fault if "\vadjust pre" is used inside \halign % pdftex -ini \catcode`\{=1 \catcode`\}=2 \catcode`\#=6 \halign{#\cr\vadjust pre{}\cr} \end % pdflatex \documentclass{article} \begin{document} \begin{tabular}{l} \hline \vadjust pre{\kern10mm} \end{tabular} \end{document} Yours sincerely ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2010-12-18 09:18 Message: Looks ok to me (the pdf_error could be an assertion?) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-12-17 14:39 Message: here is a patch against pdftex svn stable branch. Testing/comments welcome. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4322&group_id=106

1 0

[pdftex-Bugs][4322] "\vadjust pre" inside \halign
by pdftex-bugs＠sarovar.org 17 Dec '10

17 Dec '10

Bugs item #4322, was opened at 2010-12-11 20:10 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) >Summary: "\vadjust pre" inside \halign Category: None Group: None Resolution: Accepted Initial Comment: Hello, there is a segmentation fault if "\vadjust pre" is used inside \halign % pdftex -ini \catcode`\{=1 \catcode`\}=2 \catcode`\#=6 \halign{#\cr\vadjust pre{}\cr} \end % pdflatex \documentclass{article} \begin{document} \begin{tabular}{l} \hline \vadjust pre{\kern10mm} \end{tabular} \end{document} Yours sincerely ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-17 13:39 Message: here is a patch against pdftex svn stable branch. Testing/comments welcome. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4322&group_id=106

1 0

[pdftex-Bugs][4323] problem with \letterspacefont
by pdftex-bugs＠sarovar.org 16 Dec '10

16 Dec '10

Bugs item #4323, was opened at 2010-12-16 06:08 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: problem with \letterspacefont Category: Fonts Group: None Resolution: Accepted Initial Comment: from: http://tug.org/pipermail/pdftex/2010-December/008575.html Hi, I just encountered something unexpected with \letterspacefont in pdfTeX 3.1415926-1.40.11-2.2 (TeX Live 2010) if the amount of spacing is zero. Try the example below: \parskip=0pt Paragraph begins here\par {\letterspacefont\x=\font 0 \x THE QUICK BROWN FOX...}\par {\letterspacefont\x=\font 1 \x THE QUICK BROWN FOX...}\par {\letterspacefont\x=\font 10 \x THE QUICK BROWN FOX...}\par {\letterspacefont\x=\font 20 \x THE QUICK BROWN FOX...}\par {\letterspacefont\x=\font 30 \x THE QUICK BROWN FOX...}\par {\letterspacefont\x=\font 0 \x THE QUICK BROWN FOX...}\par \bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-12-16 07:34 Message: a fix has been committed to pdftex repo at supelec ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4323&group_id=106

1 0

[pdftex-Bugs][4323] problem with \letterspacefont
by pdftex-bugs＠sarovar.org 16 Dec '10

16 Dec '10

Bugs item #4323, was opened at 2010-12-16 06:08 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: problem with \letterspacefont Category: Fonts Group: None Resolution: Accepted Initial Comment: from: http://tug.org/pipermail/pdftex/2010-December/008575.html Hi, I just encountered something unexpected with \letterspacefont in pdfTeX 3.1415926-1.40.11-2.2 (TeX Live 2010) if the amount of spacing is zero. Try the example below: \parskip=0pt Paragraph begins here\par {\letterspacefont\x=\font 0 \x THE QUICK BROWN FOX...}\par {\letterspacefont\x=\font 1 \x THE QUICK BROWN FOX...}\par {\letterspacefont\x=\font 10 \x THE QUICK BROWN FOX...}\par {\letterspacefont\x=\font 20 \x THE QUICK BROWN FOX...}\par {\letterspacefont\x=\font 30 \x THE QUICK BROWN FOX...}\par {\letterspacefont\x=\font 0 \x THE QUICK BROWN FOX...}\par \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4323&group_id=106

1 0

[pdftex-Bugs][4322] "\vadjust pre" inside \halign
by pdftex-bugs＠sarovar.org 15 Dec '10

15 Dec '10

Bugs item #4322, was opened at 2010-12-11 20:10 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) >Summary: "\vadjust pre" inside \halign Category: None Group: None >Resolution: Accepted Initial Comment: Hello, there is a segmentation fault if "\vadjust pre" is used inside \halign % pdftex -ini \catcode`\{=1 \catcode`\}=2 \catcode`\#=6 \halign{#\cr\vadjust pre{}\cr} \end % pdflatex \documentclass{article} \begin{document} \begin{tabular}{l} \hline \vadjust pre{\kern10mm} \end{tabular} \end{document} Yours sincerely ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4322&group_id=106

1 0

[pdftex-Bugs][4322] "\vadjust pre" inside \halign
by pdftex-bugs＠sarovar.org 11 Dec '10

11 Dec '10

Bugs item #4322, was opened at 2010-12-11 21:10 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: "\vadjust pre" inside \halign Category: None Group: None Resolution: None Initial Comment: Hello, there is a segmentation fault if "\vadjust pre" is used inside \halign % pdftex -ini \catcode`\{=1 \catcode`\}=2 \catcode`\#=6 \halign{#\cr\vadjust pre{}\cr} \end % pdflatex \documentclass{article} \begin{document} \begin{tabular}{l} \hline \vadjust pre{\kern10mm} \end{tabular} \end{document} Yours sincerely ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4322&group_id=106

1 0

[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 26 Nov '10

26 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