- 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 17: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: Wont Fix 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 ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 19:05 Message: update: the link was wrong again; somehow a ';' was automatically inserted to the link. Please see bug #2092 for a similar problem and workaround. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 19:02 Message: update: the previous link was broken, correction: http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 18:59 Message: I guess the figure was created with a modified version of utmr8a.pfb (NimbusRomNo9L-Regu), since the original utmr8a.pfb doesn't have non-latin glyphs. This is not a bug of pdftex. For a workaround, please see http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4014&group_id=106

1 0

[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 17: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: Wont Fix 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 ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 19:02 Message: update: the previous link was broken, correction: http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 18:59 Message: I guess the figure was created with a modified version of utmr8a.pfb (NimbusRomNo9L-Regu), since the original utmr8a.pfb doesn't have non-latin glyphs. This is not a bug of pdftex. For a workaround, please see http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4014&group_id=106

1 0

[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 17: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: Wont Fix 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 ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 18:59 Message: I guess the figure was created with a modified version of utmr8a.pfb (NimbusRomNo9L-Regu), since the original utmr8a.pfb doesn't have non-latin glyphs. This is not a bug of pdftex. For a workaround, please see http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4014&group_id=106

1 0

[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

[pdftex-Bugs][884] Letterspacing and non-autoexpanded fonts
by pdftex-bugs＠sarovar.org 06 Apr '09

06 Apr '09

Bugs item #884, was opened at 2007-11-27 09:53 >Status: Closed Priority: 2 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Letterspacing and non-autoexpanded fonts Category: hz Group: v1.40.5 >Resolution: Wont Fix Initial Comment: While auto-expanding letterspaced fonts works fine now, there still is a problem with non-automatic expansion. The following will complain about a missing tfm file. It doesn't make a difference whether the expanded font instance is created from an mf file (like below), via `ExtendFont' in the map file, or even whether it was created from a MM font (ie., the expanded instance actually exists as a pfb file). The latter case is what bothers me the most. \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr=cmr10 \cmr \letterspacefont\cmrls=\cmr 100 \pdffontexpand\cmrls 100 0 100 %autoexpand \cmrls Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye PS: what about the `invalid entry' complaint for the map lines? Are they not legal? ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-05 23:23 Message: Re: the invalid entry: it should be something like this: \pdfmapline{+cmr10+100 <cmr10+100.pfa} (the fontfile must be present, otherwise pdftex will complain) Re: the problem with \pdffontexpand: what happens here is as follows: \letterspacefont\cmrls=\cmr 100 => pdftex creates a font named cmr10+100ls in memory \pdffontexpand\cmrls 100 0 100 autoexpand => pdftex creates another font from cmr10+100ls, and name it cmr10+100ls+100 without "autoexpand", pdftex would look for a tfm file named cmr10+100ls+100.tfm, and henc cmr10+100 would not be loaded. yes this is a problem, however not a bug. And there is no easy way to get this work, I am sorry but have to close this as "won't fix". ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-12-19 16:42 Message: Logged In: YES user_id=2217 > A map line needs either a psname (for not-embedded fonts) > or the file name (for embedded fonts) The manual seems to suggest otherwise (re scalable Type 3 fonts). Also, older pdftex versions wouldn't throw a warning, but use the Type 3 font instead. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-11-27 10:05 Message: Logged In: YES user_id=421 A map line needs either a psname (for not-embedded fonts) or the file name (for embedded fonts) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=884&group_id=106

1 0

[pdftex-Bugs][2100] colors on page influenced by included pdf image
by pdftex-bugs＠sarovar.org 06 Apr '09

06 Apr '09

Bugs item #2100, was opened at 2008-10-08 22:18 >Status: Closed Priority: 3 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Nobody (None) Summary: colors on page influenced by included pdf image Category: PDF inclusion Group: v1.40.8 >Resolution: Rejected Initial Comment: I've got a problem with defined colors on a page when I include a pdf image. The original file (regression-org.pdf) is included on the second page: blue and red on that page are different from the blue and red on the other pages. However, if I convert the included pdf image to ps via pdftops and back to pdf via pstopdf (regression.pdf), there's no problem as shown on the last page. Is this a bug in pdftex, or am I using an "incorrectly" generated pdf image file, since a double conversion seems to produce the correct output? (I'm using texlive's 2008 pdftex 1.40.9) Best regards Stefan ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-05 23:10 Message: I confirm the problem, but this doesn't seem a bug of pdftex. We will reopen this if more evidence is provided. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-10-10 08:56 Message: I don't think the problem here is transparency (I don't find a /Group), but ICC, as regression-org.pdf uses an /ICCbased colorspace. Oh, and I get the same colours here with 1.40.9 and AR8 on Linux. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-10-10 08:13 Message: It's a known problem of later AR versions if transparency is involved. Then AR seems to be using a different method for displaying the page and colors may change. PostScript doesn't support transparency, thus converting to PS and back to PDF gets rid of the transparency. Tested with: * AR7/Linux, AR8/Linux: wrong displayed colors * AR5/Linux: correct colors * xpdf3.00: correct colors * gs8.54: correct colors, but warnings for second page: CS/cs (setcolorspace) operand not a name: [/ICCBased -dict-] * gs8.62: fails on page two with /unknownerror. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2100&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: 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: 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][469] \currentexpansionmode + \ifalignscanning - \ifinedef
by pdftex-patches＠sarovar.org 06 Apr '09

06 Apr '09

Patches item #469, was opened at 2006-01-12 01:39 >Status: Closed Priority: 3 Submitted By: Morten Høgholm (morten) Assigned to: The Thanh Han (hanthethanh) Summary: \currentexpansionmode + \ifalignscanning - \ifinedef Category: Primitives Group: v1.40.0 >Resolution: Rejected Initial Comment: Here's a patch made against pdftex-1.40.0-alpha-20060111. It removes the \ifinedef primitive for a different primitive, namely \currentexpansionmode. This read-only register is 0 when doing regular typesetting, 1 when inside \edef or \xdef and 2 in other cases of full expansion with scan_toks. It could possibly be extended to distinguish between \marks and \write etc. Comments more than welcome on this one! I have also added an \ifalignscanning test. It is true whenever TeX is looking for \noalign etc. so is most useful for a \stopalignscanning function defined as \def\stopalignscanning{\ifalignscanning\relax\fi} ---------------------------------------------------------------------- Comment By: Frank Mittelbach (mittelbach) Date: 2006-02-15 17:38 Message: Logged In: YES user_id=3421 concerning register versus individual \if... primitves: I agree that numeric values are less easy to read but if the numeric codes are well chosen then they have the advantage of not cluttering the code, eg if you have to test for a number of different cases then a set of nested \if's is also not really helpful. Suppose for example you have to do different actions depending on the type of expansion. Then the register allows you to do this in a since \ifcase or in some \ifnum ...> . But of course this only works is the order is adjusted to typical usages. And non-numerical ones could still be implemented efficently at the macro level, eg \def\ifinedef{\ifnum 1=\currentexpansionmode} as to \stopalignscanning: this is not identical to \protected as protection prevents expansion in all cases which is not necessarily what you need my 2 cents frank ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-17 22:22 Message: Logged In: YES user_id=927 concerning alignments: - how about adding \everyaligncell (in addition to \everycr) - how about the other iftests? - (and \nospan -) ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-16 20:23 Message: Logged In: YES user_id=3333 @None: An \ifalignscanning primitive can also help macros like LaTeX's \multicolumn and other code that relies on seeing \noalign or \omit to recover gracefully with a comprehensible error message. ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-13 04:50 Message: Logged In: YES user_id=3333 Yes, just ideas here, which is why I asked for comments. We can discuss this on the list (once my subscription is accepted). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-01-12 10:22 Message: Logged In: YES user_id=1608 Like Hans, I also prefer separate if primitives, mainly because I do not want to have to remember the meanings of the possible integer values (for that reason, I'm not too happy about \currentgrouptype either). Taco ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-01-12 09:14 Message: Logged In: NO i wonder why we need \ifalignscanning or \stopalignscanner at all when eTeX already has this feature - any \protected macro stops the scanning. ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-12 08:08 Message: Logged In: YES user_id=927 somehow i think that if's are a better idea than a register because in your case the register only registers one case at the same time (when i saw this patch the first time, i wondered why not a complete set was implemented) - ifincsname - ifinedef - ifinwrite - ifinspecial - ifinpdfliteral - ifinannotbody - ifinmessage (special case of write) - ifinalign - ifinmark probably some more (ok, normally all those conditions can comfortably be catched in a macro package but if we add them, we should be complete in addition to this there can be a register which keeps track of the innermost one (we can have ifcsname inside an edef inside an align concerning the \stopalignscanner i think it's better to have something primitive like \crcr, say \endalign because using if's can have its own problem (we should not worry to much about a name clash, since one can always let it to another one); so, we should wait with adding this patches till (1) we agree and (2) it is complete remark: also, it's dangerous to add patched before a decent decission/interface is dediced upon; once it's in, we cannot change it any more Hans ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=469&group_id=106

1 0

[pdftex-Patches][2091] bugfix for #2090
by pdftex-patches＠sarovar.org 05 Apr '09

05 Apr '09

Patches item #2091, was opened at 2008-09-17 06:59 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: bugfix for #2090 Category: None Group: None >Resolution: Accepted Initial Comment: this patch is for 1.40.9 and the stable branch only. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-09-17 07:03 Message: update: don't forget to rerun autoconf after applying the patch. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=2091&group_id=106

1 0

[pdftex-Bugs][829] TEX_HUSH not handled correctly
by pdftex-bugs＠sarovar.org 24 Mar '09

24 Mar '09

Bugs item #829, was opened at 2007-07-04 10:49 >Status: Closed Priority: 1 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: TEX_HUSH not handled correctly Category: web2c Group: v1.40.3 >Resolution: Wont Fix Initial Comment: This is from kpathsea.info: --------------------------- 4.4 Suppressing warnings ======================== Kpathsea provides a way to suppress selected usually-harmless warnings; this is useful at large sites where most users are not administrators, and thus the warnings are merely a source of confusion, not a help. To do this, you set the environment variable or configuration file value `TEX_HUSH' to a colon-separated list of values. Here are the possibilities: `all' Suppress everything possible. `checksum' Suppress mismatched font checksum warnings. `lostchar' Suppress warnings when a character is missing from a font that a DVI or VF file tries to typeset. `none' Don't suppress any warnings. `readable' Suppress warnings about attempts to access a file whose permissions render it unreadable. `special' Suppresses warnings about an unimplemented or unparsable `\special' command. `tex-hush.c' defines the function that checks the variable value. Each driver implements its own checks where appropriate. --------------------------- This is currently not handled by pdftex. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-04 11:01 Message: Logged In: YES user_id=421 Not Knuth's warnings. But pdfTeX in PDF mode is also a driver... The only one that IMHO matters is "special". OTOH nobody has complained about this yet... ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-04 10:56 Message: Logged In: YES user_id=1608 This only affects the backend driver, right? But not Knuth's warnings in the web source. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=829&group_id=106

1 0

[pdftex-Bugs][2242] typo in ttf2afm warning
by pdftex-bugs＠sarovar.org 24 Mar '09

24 Mar '09

Bugs item #2242, was opened at 2008-12-16 08:35 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: typo in ttf2afm warning Category: ttf2afm Group: v1.40.8 >Resolution: Fixed Initial Comment: ttf2afm has a typo in warning for glyphs with multiple encodings. Example: Warning: ttf2afm (file pala.ttf): glyph 108 have multiple encodings (the first one being used): uni0162 uni021A ("have" should be replaced by "has") ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2242&group_id=106

1 0

[pdftex-Bugs][465] font expansion & \lastlinefit
by pdftex-bugs＠sarovar.org 24 Mar '09

24 Mar '09

Bugs item #465, was opened at 2006-01-03 19:05 >Status: Closed Priority: 3 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: font expansion & \lastlinefit Category: hz Group: v1.40.0 >Resolution: Wont Fix Initial Comment: With \lastlinefit > 0, the last line will always be expanded to the maximum (except if it doesn't contain a glue). Furthermore, I wonder whether \lastlinefit should ideally also effect the expansion amount (ie., the last line of the first paragraph should be set in cmr10-25, since the preceding one is set in cmr10-50)? \tracingoutput1 \showboxbreadth\maxdimen \pdftracingfonts1 \pdfadjustspacing2 \pdffontexpand\font 50 50 10 autoexpand \lastlinefit500 \hsize=16cm \input tufte\par \bye, Robert ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-24 10:20 Message: Logged In: YES user_id=710 I spent quite some time on this, but it's unlikely that I am able to fix this bug. Probably we have to wait until some expert finds time to fix this. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-09-01 11:55 Message: Logged In: YES user_id=710 I should work on it and other bugs related to hz stuff, but I haven't found the time to reread relevant codes yet. Please be patient with me. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 10:48 Message: Logged In: YES user_id=421 Hartmut? Thanh? Anybody working on this? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=465&group_id=106

1 0

[pdftex-Bugs][2092] Ligatures and special characters in included pdf disappear in typesetted document
by pdftex-bugs＠sarovar.org 23 Mar '09

23 Mar '09

Bugs item #2092, was opened at 2008-09-18 10:36 >Status: Closed Priority: 3 Submitted By: Jan Michael (jan) Assigned to: Nobody (None) Summary: Ligatures and special characters in included pdf disappear in typesetted document Category: PDF inclusion Group: None Resolution: Wont Fix Initial Comment: Dear Readers, as the subject already states, my documents created with pdflatex are loosing their ligatures and other special characters from included pdf documents which were typesetted by other applications (Word, Excel, Omnigraffle ...). (a) Situation ------------- This is how the behaviour can be reproduced and how it happens in my case: (1) Import Latin Modern fonts as otf into system wide font location (2) Create a document with Latin Modern Roman font and use ff, fi, fl ligatures (3) Save Document as PDF (in OS X it's just "Save as PDF ...") - the pdf still shows the ligatures (4) Include the created pdf into a *.tex document with \includegraphics (5) Typeset the document with pdflatex (6) Ligatures from included pdf document disappear while inline ligature are typeset as usual. (b) Minimal Example ------------------- \documentclass[ngerman]{scrreprt} \usepackage{graphicx} \begin{document} \begin{figure}[htbp!] \centering\includegraphics[width=1.1\textwidth]{ligaturen.pdf} \end{figure} \end{document} ligaturen.pdf can be downloaded from <https://dl.getdropbox.com/u/73200/ligaturen.pdf> (c) Problem Analysis -------------------- This is what the the German tex usenet group de.comp.text.tex has already figured out: - problem can be reproduced with MiKTeX 2.6 and TexLive 2008 (Windows) - names of ligature glyphs in included pdf (f_i, f_l, f_f) differ from names used by pdftex (fi, fl, ff) - font from included pdf is replaced by pdftex -> glyphs f_i, ... won't be found anymore - behaviour can be suppressed by using \pdfmapfile{} - behaviour can be suppressed by removing or renaming related fonts in pdftex.map - behaviour can be suppressed by typesetting the pdf with xe(la)tex before including it in pdf(la)tex document. XeTeX redeclares the font in ligaturen.pdf from JTSEMF+LMRoman10-Regular to ASKXQL+LMRoman10-Regular-Identity-H. The related thread, in German language, can be found here: <http://groups.google.de/group/de.comp.text.tex/browse_frm/thread/4c0245d37c…> Right now I use the workaround with XeTeX to get my documents right. What do you think? Cheers, Jan ------------------------------------------------------------ p.s. Please see pdf(la)tex version information below: (from TexLive 2007 shipped with MacTeX 2007 package on MacBook C2D running OS X 10.5.5) $ pdflatex -v pdfTeX 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 copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea written by Karl Berry, Olaf Weber, and others. Compiled with libpng 1.2.15; using libpng 1.2.15 Compiled with zlib 1.2.3; using zlib 1.2.3 Compiled with xpdf version 3.01 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-02-06 06:46 Message: (1) Re: the problem with ligature pdftex is doing what it is supposed to do: when it sees a font (LMRoman10-Regular) in an included pdf and the same font is available on local disk, it tries to replace the font in the included pdf by the local font. The reason is to make the pdf output smaller (avoid font duplicate). In this case however this is not desired, since the font in included is not the same as the font on local disk (though they have the same name). Workarounds: (a) tell pdftex to keep all fonts in included pdfs by saying: \pdfinclusioncopyfonts=1 (b) or tell pdftex not to replace a particular font for pdf inclusion: - open the log file - search for the map file(s) being loaded (usually pdftex.map) - search for the line containing LMRoman10-Regular, in my setup (Texlive 2008) it would be ,-------- | cs-lmr10 LMRoman10-Regular "enclmcs ReEncodeFont" <lm-cs.enc <lmr10.pfb | ec-lmr10 LMRoman10-Regular "enclmec ReEncodeFont" <lm-ec.enc <lmr10.pfb | l7x-lmr10 LMRoman10-Regular "enclml7x ReEncodeFont" <lm-l7x.enc <lmr10.pfb | qx-lmr10 LMRoman10-Regular "enclmqx ReEncodeFont" <lm-qx.enc <lmr10.pfb | rm-lmr10 LMRoman10-Regular "enclmrm ReEncodeFont" <lm-rm.enc <lmr10.pfb | t5-lmr10 LMRoman10-Regular "enclmt5 ReEncodeFont" <lm-t5.enc <lmr10.pfb | texnansi-lmr10 LMRoman10-Regular "enclmtexnansi ReEncodeFont" <lm-texnansi.enc <lmr10.pfb | ts1-lmr10 LMRoman10-Regular "enclmts1 ReEncodeFont" <lm-ts1.enc <lmr10.pfb `-------- - override those lines by removing the PostScript name as follows (put into tex file): ,-------- | \pdfmapline{=cs-lmr10 "enclmcs ReEncodeFont" <lm-cs.enc <lmr10.pfb} | \pdfmapline{=ec-lmr10 "enclmec ReEncodeFont" <lm-ec.enc <lmr10.pfb} | \pdfmapline{=l7x-lmr10 "enclml7x ReEncodeFont" <lm-l7x.enc <lmr10.pfb} | \pdfmapline{=qx-lmr10 "enclmqx ReEncodeFont" <lm-qx.enc <lmr10.pfb} | \pdfmapline{=rm-lmr10 "enclmrm ReEncodeFont" <lm-rm.enc <lmr10.pfb} | \pdfmapline{=t5-lmr10 "enclmt5 ReEncodeFont" <lm-t5.enc <lmr10.pfb} | \pdfmapline{=texnansi-lmr10 "enclmtexnansi ReEncodeFont" <lm-texnansi.enc <lmr10.pfb} | \pdfmapline{=ts1-lmr10 "enclmts1 ReEncodeFont" <lm-ts1.enc <lmr10.pfb} `-------- this is of course more work than (a), the advantage is that font replacement is disabled only for LMRoman10-Regular instead of every font as in (a). (2) Re: the problem with pdf figure containing Mathematica 1 font: this was tricky: perhaps Illustrator tried to optimize the pdf size, so it used a predefined encoding (MacRomanEncoding) to avoid having an explicit encoding, then changed the font to rename all glyphs to conform that encoding. So, for example /alpha in the original font was renamed to /a, /beta to /b and so on. pdftex is not aware of this, and when replacing the font it ended up with the original names. In principle the problem is the same as in (1): pdftex replaces a font in included pdf by a local font, but it is not we want because the font in included differs from the local font. Workarounds for (1) apply here too. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-02-06 06:14 Message: test files from Bruno attached. ---------------------------------------------------------------------- Comment By: Bruno Voisin (bvoisin) Date: 2009-02-05 14:05 Message: I've just met some bug which seems a follow-up. Imagine you've got two versions of the Mathematica 1 font, both included in and used by the Mathematica application: one in PFA format installed for TeX within texmf, and the other in TrueType format installed at the OS level. If you use Adobe Illustrator to prepare an illustration with this font, on the Mac, Illustrator will embed and subset the TrueType font in Macintosh Roman encoding. Imagine you save the Illustrator output to EPS format, and convert it to PDF format (the same happens probably when creating directly the PDF file from within Illustrator, I've just not tried). Now use \includegraphics to include the illustration in a LaTeX document: - If the Mathematica 1 font is installed in texmf, dvips will use the embedded version of the font while pdfTeX will use the version from texmf. Since the version in texmf does not have the encoding assumed by Illustrator, glyphs are missing from the pdfTeX output. - If the Mathematica 1 font is not installed in texmf, both dvips and pdfTeX use the embedded version of the font and everything's fine. Attached are small test files. Files with names ending with "with-math1" were produced with the Mathematica 1 font in texmf, and files with names ending with "without-math1" were produced without the Mathematica font in texmf. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-09-18 12:06 Message: yes this is an unfortunate situation: both the font from included pdf and the font on disk use the same name (LMRoman10-Regular), but they differ. Workarounds have been also mentioned; in short they fall into 2 methods: - disable font subsetting globally, or - change the font name in included pdf to something else, hence pdftex will not think this is the same font as the one on disk none is perfect, and also it's not clear how pdftex should handle such cases. Needs more thinking... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2092&group_id=106

1 0

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

23 Mar '09

Bugs item #3253, was opened at 2009-03-23 22:39 Status: Open 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 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=3253&group_id=106

1 0

Patch for longstanding pdftex font subsetting bug
by Melissa O'Neill 22 Mar '09

22 Mar '09

The enclosed patch fixes a longstanding bug in font subsetting for pdflatex that has existed since 1.20a-rc1 (March 2004). This bug has been causing problems for Mac users for some time because OS X does not like the subtly invalid fonts that pdflatex can output (but it may have affected others as well). The technical details and patch are below... The issue relates to CharString encryption for Type 1 fonts. In particular, the lenIV parameter of a font controls how much (encrypted) padding to put in front of the (encrypted) data. The default is four, so four bytes of encrypted padding are produced. In one part of the pdftex font-subsetting code (the part that writes out empty subroutines that have been dropped in the process of subsetting), pdftex incorrectly treats a padding of zero as meaning that it should abandon charstring encryption altogether. Not so. (FWIW, by undocumented convention, a padding of -1 does, in fact, mean no encryption.) By not encrypting data that is supposed to be encrypted, the subroutine ends up containing operator 0x1b, the hhcurveto operator, rather than 0x0b, return. This is an error in two ways, first, subroutines should return, and, second, the hhcurveto operator expects some arguments. Note that the subroutines that are affected by this bug are exactly those that are *never called*, so we might expect the bug to be harmless. It would appear, however, that Apple's font technology does process these "uncalled" subroutines and does not react well to their invalid content. Thus, to have been affected by this bug, you need to a) Use a font where lenIV = 0, and b) Use a Mac (or anything else that needs uncalled subroutines to nevertheless be valid), which explains why so many people have said, "I see no problem; it works for me" in response to the anguished cries of Mac users with PDFTeX-generated documents everywhere. FWIW, the buggy code was checked into the repository for version 1.20a- rc1. Prior to that point, this aspect of font subsetting worked correctly. The patch is, thankfully, trivial, changing (t1_lenIV > 0) to (t1_lenIV >= 0). Fonts known to be affected by this bug include cm-super, sanskrit, and fonts processed with cfftot1 (i.e., OpenType fonts used with LaTeX), as well as many Adobe Type 1 fonts. To assist Mac users, I have put a precompiled version of pdftex-1.40.9 on my website at http://www.cs.hmc.edu/~oneill/dist/pdftex-1.40.9-patched.zip If you have enjoyed this patch, share it with your friends. I'm told it goes well with a glass of fine Merlot. Melissa. P.S. Sadly, I don't know if this is the *only* bug in fonts and subsetting that causes fonts to be subtly invalid, but it is at least *a* bug that's been squished. Enc.

2 1

[pdftex-Feature Requests][2383] Support svg graphics
by pdftex-featurerequests＠sarovar.org 19 Feb '09

19 Feb '09

Feature Requests item #2383, was opened at 2009-01-15 12:08 >Status: Closed Priority: 3 Submitted By: Martin Kossick (hacktick) Assigned to: Nobody (None) Summary: Support svg graphics Category: None Group: None >Resolution: Rejected Initial Comment: At the moment I export pngs from inkscape and embed them using includegraphics. It would be great if pdflatex could handle svg-files, This would improve the quality of the generated files and help save time. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-02-19 11:19 Message: this is not easy to implement. If I were in your place, I would try to somehow automate or semi-automate the svg->pdf route as a workaround. ---------------------------------------------------------------------- Comment By: Martin Kossick (hacktick) Date: 2009-01-23 15:50 Message: Hi, At the moment I generate png-files manually and include them. This brings mainly three disadvantages: - I have to handle more files. For each picture two files. - I have more work. Each time I change the svg-file, I need to generate a new png. - I get lower quality or need more disk space. The png needs to have a very high resolution, if not the result can be ugly since pdflatex scales it again. In my opinion, Scalable Vector Graphics are very useful and state-of-the-art. So it would be worth while to add svg-support to pdflatex. Since SVGs cannot be included in PDF files, pdflatex could render them to eps or something else before including them. Thanks for your attention, Martin ---------------------------------------------------------------------- Comment By: Reinhard Kotucha (reinhardk) Date: 2009-01-15 23:00 Message: Unfortunately, in contrast to PNG and JPEG, SVG cannot be included in PDF files directly as far as I know. Hence an external converter is needed. But why do you export your graphics as PNG instead of EPS? You can convert them to PDF easily using epstopdf. There is one drawback: PostScript doesn't support transparency. I never used inkscape myself, I just looked at the project web page (the German one) and I'm quite baffled that the list of supported output formats contains PostScript and EPS but not PDF. PostScript and PDF are based on the same imaging model, hence, for someone who is able to craete PostScript, it shouldn't be too difficult to create PDF as well. On the other hand, I just installed inkscape and I see that it is linked against libcairo, which means that PDF output is supported (by cairo) unless it is disabled deliberately by the build process. It would be very strange if inkscape is using Cairo but can't create PDF. See http://cairographics.org/ for more details about Cairo. It's a wonderful thing. Regards, Reinhard ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=2383&group_id=106

1 0