April 2009 - ntg-pdftex - NTG Mailing Lists

[pdftex-Bugs][4014] Drops characters from included pdf figure
by pdftex-bugs＠sarovar.org 08 Apr '09

08 Apr '09

Bugs item #4014, was opened at 2009-04-08 21:24 Status: Open Priority: 3 Submitted By: Andrey Paramonov (pent) Assigned to: Nobody (None) Summary: Drops characters from included pdf figure Category: PDF inclusion Group: None Resolution: None Initial Comment: To reproduce: 1) Download attached file. It is a pdf figure containing some non-latin characters. Note that the used font subset is embedded. 2) Create the following minimal LaTeX document: \documentclass{article} \usepackage[T2A]{fontenc} \usepackage[utf8]{inputenc} \usepackage[russian]{babel} \usepackage{graphicx} \begin{document} \includegraphics{fig} \end{document} 3) pdflatex it. Open the resulting pdf file and note that all non-latin characters have disappeared. My pdflatex says: --------- Running `LaTeX' on `test' with ``pdflatex "\nonstopmode\input {test.tex}"'' This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) %&-line parsing enabled. entering extended mode LaTeX2e <2005/12/01> Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh yphenation, ukrainian, russian, bulgarian, loaded. (./test.tex (/usr/share/texmf-texlive/tex/latex/base/article.cls Document Class: article 2005/09/16 v1.4f Standard LaTeX document class (/usr/share/texmf-texlive/tex/latex/base/size10.clo)) (/usr/share/texmf-texlive/tex/latex/base/fontenc.sty (/usr/share/texmf-texlive/tex/latex/cyrillic/t2aenc.def) (/usr/share/texmf-texlive/tex/latex/cyrillic/t2acmr.fd)) (/usr/share/texmf-texlive/tex/latex/base/inputenc.sty (/usr/share/texmf-texlive/tex/latex/base/utf8.def (/usr/share/texmf-texlive/tex/latex/base/t1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/ot1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/omsenc.dfu) (/usr/share/texmf-texlive/tex/latex/base/t2aenc.dfu))) (/usr/share/texmf-texlive/tex/generic/babel/babel.sty (/usr/share/texmf-texlive/tex/generic/babel/russianb.ldf (/usr/share/texmf-texlive/tex/generic/babel/babel.def))) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty (/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty) (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty) (/etc/texmf/tex/latex/config/graphics.cfg) (/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def))) (./ test.aux) <fig.pdf, id=1, 578.16pt x 289.08pt> <use fig.pdf> Overfull \hbox (248.15858pt too wide) in paragraph at lines 10--11 [][] [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./fig.pdf>] (./ test.aux) ) (see the transcript file for additional information){/usr/share/texmf/ fonts/enc /dvips/cm-super/cm-super-t2a.enc}</usr/share/texmf/fonts/type1/public/ cm-super/ sfrm1000.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/ utmr8a.pfb pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10019' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10021' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10026' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10028' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10030' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10031' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10032' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10033' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10035' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10049' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10065' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10067' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10070' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10075' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10077' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10079' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10080' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10082' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10084' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10096' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10097' undefined Output written on test.pdf (1 page, 19327 bytes). Transcript written on test.log. LaTeX finished at Wed Apr 8 00:01:45 --------- My pdftex --version says: --------- pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6) kpathsea version 3.5.6 Copyright 2007 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea is copyright 2007 Karl Berry and Olaf Weber. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX using libpoppler copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX using libpoppler source. Primary author of pdfTeX using libpoppler: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea written by Karl Berry, Olaf Weber, and others. Compiled with libpng 1.2.35; using libpng 1.2.35 Compiled with zlib 1.2.3.3; using zlib 1.2.3.3 Compiled with libpoppler version 0.10.4 --------- I'm ready to provide any additional info, Andrey Paramonov ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4014&group_id=106

1 0

[pdftex-Patches][2087] Support for CMap namespaces
by pdftex-patches＠sarovar.org 07 Apr '09

07 Apr '09

Patches item #2087, was opened at 2008-08-28 08:17 Status: Open Priority: 3 Submitted By: Vasile Gaburici (vga) Assigned to: Nobody (None) Summary: Support for CMap namespaces Category: Fonts Group: v1.40.0 Resolution: None 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: 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-Bugs][606] Forbidden ... while scanning ???
by pdftex-bugs＠sarovar.org 07 Apr '09

07 Apr '09

Bugs item #606, was opened at 2006-09-16 22:28 Status: Open Priority: 2 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: Forbidden ... while scanning ??? Category: Primitives Group: v1.40.0 Resolution: Postponed Initial Comment: \pdftrailer {abc \bye gives ! Forbidden control sequence found while scanning text of \pdftrailer. but \pdfximage {abc \bye or \pdfliteral {abc \bye give ! Forbidden control sequence found while scanning text of ???. Instead of these three question marks there should be the name of the primitive. ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2009-04-07 08:28 Message: Attached is what I would do: patch scan_keyword() to restore cur_cs in the 'false' case. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-27 17:40 Message: Logged In: YES user_id=421 Hartmut, can you please check this again for 1.50? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-21 14:22 Message: Logged In: YES user_id=421 I've backed out the change; this is low priority and probably needs more changes. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-17 21:10 Message: Logged In: YES user_id=929 yes, the patch works, thanks a lot! But there are in fact many more \pdf... primitives that suffer from this problem, actually any with a scan_keyword call before the scan_pdf_ext_toks. After the way how it's done in @<Implement \.{\\write}@>=, it seems that a new variable save_cur_cs is not needed if one uses k for this purpose. Needs change of a few k uses to j. But problematic is \pdfoutline as it has another scan_pdf_ext_toks for the attr keyword. Wouldn't these many changes be too risky for 1.40.0? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 18:34 Message: Logged In: YES user_id=421 The patch was missing. Fixed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 16:30 Message: Logged In: YES user_id=421 The cause seems to be that some scan_functions loose the meaning of cur_cs, which leads to the ??? when reaching <Tell the user what has run away...@>. The attached (IMHO crude) patch fixes this for the cases you mentioned, but there are probably other cases not found... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=606&group_id=106

1 0

[pdftex-Patches][3886] Fix for str_less_str (bug #993)
by pdftex-patches＠sarovar.org 06 Apr '09

06 Apr '09

Patches item #3886, was opened at 2009-04-06 05:38 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Fix for str_less_str (bug #993) Category: None Group: None Resolution: None Initial Comment: The patch is based on pdftex-1.40.9. It fixes the bug #993 `/Names array not sorted correctly' by correcting function `str_less_str'. In theory pdfTeX can still be fooled by * invalid pdf strings and * equal destination names that only differs in the way of escaping. But both problems can be solved at macro level by passing the name argument of \pdfdest through \pdfescapestring. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 15:14 Message: Thanh, I forgot. Thanks, also for removing the redundancy -- I am not too familiar with the "web" language. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-06 15:01 Message: Heiko, it seems the test (c2 < 32) is missing for the second string. I changed slightly your patch. It looks a bit ugly now but less redundant. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 06:08 Message: pdftex2.web.diff replaces pdftex.web.diff. It handles the case correctly if the octal sequence starts with a digit greater than three. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=3886&group_id=106

1 0

[pdftex-Patches][3886] Fix for str_less_str (bug #993)
by pdftex-patches＠sarovar.org 06 Apr '09

06 Apr '09

Patches item #3886, was opened at 2009-04-06 03:38 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Fix for str_less_str (bug #993) Category: None Group: None Resolution: None Initial Comment: The patch is based on pdftex-1.40.9. It fixes the bug #993 `/Names array not sorted correctly' by correcting function `str_less_str'. In theory pdfTeX can still be fooled by * invalid pdf strings and * equal destination names that only differs in the way of escaping. But both problems can be solved at macro level by passing the name argument of \pdfdest through \pdfescapestring. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-06 13:01 Message: Heiko, it seems the test (c2 < 32) is missing for the second string. I changed slightly your patch. It looks a bit ugly now but less redundant. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 04:08 Message: pdftex2.web.diff replaces pdftex.web.diff. It handles the case correctly if the octal sequence starts with a digit greater than three. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=3886&group_id=106

1 0

[pdftex-Bugs][993] /Names array not sorted correctly
by pdftex-bugs＠sarovar.org 06 Apr '09

06 Apr '09

Bugs item #993, was opened at 2008-05-24 13:24 >Status: Open Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: /Names array not sorted correctly Category: None Group: v1.40.6 >Resolution: Accepted Initial Comment: Axel Berger and Heiko Oberdiek report an error with the sorting of the /Names array: /Names [(cite.Kr07) 44 0 R (cite.Li08) 45 0 R (cite.M\37403) 23 0 R (cite.Mi00) 47 0 R (cite.Mi84) 48 0 R (cite.Mo04) 50 0 R] "cite.Mü03" (= "cite.M\37403") should come after "cite.Mo04". A test file with output is attached. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-06 08:22 Message: thanks Heiko for the patch, hence I reopened this bug report. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 03:49 Message: Sorry, I cannot accept the rejection, because the problem cannot be fixed at macro level unless * some characters (backslash, parentheses, ...) must be forbidden, * octal escape sequences are used for *every* character of the destination name (otherwise a large amount of programming work is needed to prevent that the bug is triggered.) Therefore I have written patch #3886 that fixes the comparison function `str_less_str' that is used for the sorting of destination names. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-05 22:55 Message: since the beginning we chose not to parse pdf string of \pdf* commands. Fixing this now would mean a too big change in pdftex code. Sorry. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 16:48 Message: ok then this should be fixed as the spec says. BTW, it doesn't really solve the reported problem (ü will come after eg z). ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2008-05-27 16:03 Message: the spec says: The Names entries in the leaf (or root) nodes contain the tree’s keys and their associated values, arranged in key-value pairs and sorted lexically in ascending order by key. Shorter keys appear before longer ones beginning with the same byte sequence. The encoding of the keys is immaterial as long as it is self-consistent; keys are compared for equality on a simple byte-by-byte basis. so, it's just bytes ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 15:43 Message: this is a problem, but it's not clear to me how it should be fixed. Assume that we translate "\374" to the corresponding charcode (0374 = 252) before sorting, then how we decide the lexicographic order of that char? it can be intepreted as ü but also can be eg ytilde or something different, depending on the encoding we use. Comments? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=993&group_id=106

1 0

[pdftex-Patches][3886] Fix for str_less_str (bug #993)
by pdftex-patches＠sarovar.org 06 Apr '09

06 Apr '09

Patches item #3886, was opened at 2009-04-06 05:38 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Fix for str_less_str (bug #993) Category: None Group: None Resolution: None Initial Comment: The patch is based on pdftex-1.40.9. It fixes the bug #993 `/Names array not sorted correctly' by correcting function `str_less_str'. In theory pdfTeX can still be fooled by * invalid pdf strings and * equal destination names that only differs in the way of escaping. But both problems can be solved at macro level by passing the name argument of \pdfdest through \pdfescapestring. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 06:08 Message: pdftex2.web.diff replaces pdftex.web.diff. It handles the case correctly if the octal sequence starts with a digit greater than three. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=3886&group_id=106

1 0

[pdftex-Bugs][993] /Names array not sorted correctly
by pdftex-bugs＠sarovar.org 06 Apr '09

06 Apr '09

Bugs item #993, was opened at 2008-05-24 15:24 Status: Closed Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: /Names array not sorted correctly Category: None Group: v1.40.6 Resolution: Wont Fix Initial Comment: Axel Berger and Heiko Oberdiek report an error with the sorting of the /Names array: /Names [(cite.Kr07) 44 0 R (cite.Li08) 45 0 R (cite.M\37403) 23 0 R (cite.Mi00) 47 0 R (cite.Mi84) 48 0 R (cite.Mo04) 50 0 R] "cite.Mü03" (= "cite.M\37403") should come after "cite.Mo04". A test file with output is attached. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 05:49 Message: Sorry, I cannot accept the rejection, because the problem cannot be fixed at macro level unless * some characters (backslash, parentheses, ...) must be forbidden, * octal escape sequences are used for *every* character of the destination name (otherwise a large amount of programming work is needed to prevent that the bug is triggered.) Therefore I have written patch #3886 that fixes the comparison function `str_less_str' that is used for the sorting of destination names. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-06 00:55 Message: since the beginning we chose not to parse pdf string of \pdf* commands. Fixing this now would mean a too big change in pdftex code. Sorry. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 18:48 Message: ok then this should be fixed as the spec says. BTW, it doesn't really solve the reported problem (ü will come after eg z). ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2008-05-27 18:03 Message: the spec says: The Names entries in the leaf (or root) nodes contain the tree’s keys and their associated values, arranged in key-value pairs and sorted lexically in ascending order by key. Shorter keys appear before longer ones beginning with the same byte sequence. The encoding of the keys is immaterial as long as it is self-consistent; keys are compared for equality on a simple byte-by-byte basis. so, it's just bytes ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 17:43 Message: this is a problem, but it's not clear to me how it should be fixed. Assume that we translate "\374" to the corresponding charcode (0374 = 252) before sorting, then how we decide the lexicographic order of that char? it can be intepreted as ü but also can be eg ytilde or something different, depending on the encoding we use. Comments? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=993&group_id=106

1 0

[pdftex-Patches][3886] Fix for str_less_str (bug #993)
by pdftex-patches＠sarovar.org 06 Apr '09

06 Apr '09

Patches item #3886, was opened at 2009-04-06 05:38 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Fix for str_less_str (bug #993) Category: None Group: None Resolution: None Initial Comment: The patch is based on pdftex-1.40.9. It fixes the bug #993 `/Names array not sorted correctly' by correcting function `str_less_str'. In theory pdfTeX can still be fooled by * invalid pdf strings and * equal destination names that only differs in the way of escaping. But both problems can be solved at macro level by passing the name argument of \pdfdest through \pdfescapestring. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=3886&group_id=106

1 0

[pdftex-Bugs][3253] Bug in Type1 font subsetting
by pdftex-bugs＠sarovar.org 06 Apr '09

06 Apr '09

Bugs item #3253, was opened at 2009-03-23 22:39 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: Bug in Type1 font subsetting Category: Fonts Group: None Resolution: Accepted Initial Comment: see http://tug.org/mailman/htdig/pdftex/2009-March/007975.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-05 23:24 Message: this has been fixed in TL and pdftex (1.40.10) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=3253&group_id=106

1 0