- ntg-pdftex - NTG Mailing Lists

[pdftex-Feature Requests][825] Switch to disable pk-fonts
by pdftex-featurerequests＠sarovar.org 19 Feb '09

19 Feb '09

Feature Requests item #825, was opened at 2007-06-27 12:53 Status: Open Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: Switch to disable pk-fonts Category: Fonts Group: v1.50 Resolution: None Initial Comment: This has just been raised on the MikTeX users lists: It would be nice if one could disable all pk-Fonts at once either with a cmdline switch or a command. Shouldn't be too hard to implement. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-02-19 11:13 Message: here is a patch, tested with 1.40.9 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=825&group_id=106

1 0

[pdftex-Patches][738] new primitive \pdfreplacefont
by pdftex-patches＠sarovar.org 19 Feb '09

19 Feb '09

Patches item #738, was opened at 2007-02-27 22:31 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: new primitive \pdfreplacefont Category: Fonts Group: v1.50.0 >Resolution: Accepted Initial Comment: This primitive controls whether font replacement should be done when embedding pdf's. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-02-19 08:34 Message: accepted and renamed to \pdfinclusioncopyfonts since 1.40.4 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-18 14:30 Message: Logged In: YES user_id=421 What's the status of this? The patch doesn't apply to trunk anymore... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=738&group_id=106

1 0

[pdftex-Support Requests][934] "Too many open files" pdflatex error message
by pdftex-supportrequests＠sarovar.org 19 Feb '09

19 Feb '09

Support Requests item #934, was opened at 2008-03-19 10:51 >Status: Closed Priority: 3 Submitted By: Tim Seher (tim) Assigned to: Nobody (None) Summary: "Too many open files" pdflatex error message Category: None Group: None >Resolution: Duplicate Initial Comment: Hi! I am experiencing problems with pdftex on Mac OSX 10.4. Running my file on osx in draft mode using \documentclass[draft]{book} produces the following error message pdflatex: appendixb/checkint/i103_recanomaly_99_01_l2.pdf: Too many open files Running the program without the draft option works normally. So I tried \documentclass[draft]{book} \usepackage[draft]{pdfdraftcopy} but the error persists. The same file can be compiled in draft mode without problems on my linux 64-bit box using an older version of pdftex. Is there a platform dependent maximum file number that can be included? The versions of pdflatex I am using OSX: 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 Linux: pdflatex -v pdfeTeX 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4 Copyright (C) 1997-2004 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea is copyright (C) 1997-2004 Free Software Foundation, Inc. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfeTeX copyright and the GNU General Public License. For more information about these matters, see the files named COPYING and the pdfeTeX source. Primary author of pdfeTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea written by Karl Berry and others. I downloaded the latest pdftex version, compiled but the make compile does not create a pdflatex only a pdftex, which I was not able to use. Am I making an error or do I have to update my latex distribution? Any suggestions or work-arounds highly appreciated. Thank you in advance, Tim! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-02-19 08:26 Message: it looks similar to this problem: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106 Can you please provide some test file to reproduce the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=934&group_id=106

1 0

[pdftex-Support Requests][934] "Too many open files" pdflatex error message
by pdftex-supportrequests＠sarovar.org 19 Feb '09

19 Feb '09

Support Requests item #934, was opened at 2008-03-19 10:51 Status: Open Priority: 3 Submitted By: Tim Seher (tim) Assigned to: Nobody (None) >Summary: "Too many open files" pdflatex error message Category: None Group: None Resolution: None Initial Comment: Hi! I am experiencing problems with pdftex on Mac OSX 10.4. Running my file on osx in draft mode using \documentclass[draft]{book} produces the following error message pdflatex: appendixb/checkint/i103_recanomaly_99_01_l2.pdf: Too many open files Running the program without the draft option works normally. So I tried \documentclass[draft]{book} \usepackage[draft]{pdfdraftcopy} but the error persists. The same file can be compiled in draft mode without problems on my linux 64-bit box using an older version of pdftex. Is there a platform dependent maximum file number that can be included? The versions of pdflatex I am using OSX: 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 Linux: pdflatex -v pdfeTeX 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4 Copyright (C) 1997-2004 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea is copyright (C) 1997-2004 Free Software Foundation, Inc. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfeTeX copyright and the GNU General Public License. For more information about these matters, see the files named COPYING and the pdfeTeX source. Primary author of pdfeTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea written by Karl Berry and others. I downloaded the latest pdftex version, compiled but the make compile does not create a pdflatex only a pdftex, which I was not able to use. Am I making an error or do I have to update my latex distribution? Any suggestions or work-arounds highly appreciated. Thank you in advance, Tim! ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-02-19 08:26 Message: it looks similar to this problem: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106 Can you please provide some test file to reproduce the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=934&group_id=106

1 0

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

06 Feb '09

Bugs item #2092, was opened at 2008-09-18 10:36 Status: Open 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][2092] Ligatures and special characters in included pdf disappear in typesetted document
by pdftex-bugs＠sarovar.org 06 Feb '09

06 Feb '09

Bugs item #2092, was opened at 2008-09-18 10:36 Status: Open 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: Accepted 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: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][2092] Ligatures and special characters in included pdf disappear in typesetted document
by pdftex-bugs＠sarovar.org 05 Feb '09

05 Feb '09

Bugs item #2092, was opened at 2008-09-18 12:36 Status: Open 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: Accepted 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: Bruno Voisin (bvoisin) Date: 2009-02-05 15: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 14: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

[***SPAM***] [pdftex] New document - rXpbhNkHdjx
by noreply＠sarovar.org 04 Feb '09

04 Feb '09

Project: pdftex Group: Document title: rXpbhNkHdjx Document description: NxqodFktZnJEQK Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

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

23 Jan '09

Feature Requests item #2383, was opened at 2009-01-15 12:08 Status: Open Priority: 3 Submitted By: Martin Kossick (hacktick) Assigned to: Nobody (None) Summary: Support svg graphics Category: None Group: None Resolution: None 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: 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

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

16 Jan '09

Feature Requests item #2383, was opened at 2009-01-15 13:08 Status: Open Priority: 3 Submitted By: Martin Kossick (hacktick) Assigned to: Nobody (None) Summary: Support svg graphics Category: None Group: None Resolution: None 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: Reinhard Kotucha (reinhardk) Date: 2009-01-16 00: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

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

15 Jan '09

Feature Requests item #2383, was opened at 2009-01-15 12:08 Status: Open Priority: 3 Submitted By: Martin Kossick (hacktick) Assigned to: Nobody (None) Summary: Support svg graphics Category: None Group: None Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=2383&group_id=106

1 0

buglet in pdftex/luatex
by Martin Schröder 15 Jan '09

15 Jan '09

Hi, we just noticed two buglets with \pdfstartlink/\pdfendlink: - \pdfstartlink nodes are printed as pdflink - The saved nested level of \pdf*link is only a small_number (0..63), while cur_s is an integer. This doesn't work. :-) This also means that \pdf*link only work at the first 63 levels (or since we are in web2c, they work till level 127 (signed char)). And yes, we need this. :-) Here are patches for both: @@ -34835,7 +34835,7 @@ print_mark(pdf_annot_data(p)); end; pdf_start_link_node: begin - print_esc("pdflink"); + print_esc("pdfstartlink"); @<Display <rule spec> for whatsit node created by \pdfTeX@>; if pdf_link_attr(p) <> null then begin print(" attr"); @@ -35583,7 +35583,7 @@ @ @<Types...@>= @!pdf_link_stack_record = record - nesting_level: small_number; + nesting_level: integer; link_node: pointer; {holds a copy of the corresponding |pdf_start_link_node|} ref_link_node: pointer; {points to original |pdf_start_link_node|, or a copy of |link_node| created by |append_link| in

1 0

Check your posts
by Taco Hoekwater 13 Jan '09

13 Jan '09

Hi all, Since yesterday evening localtime the ntg mail server switched to an external service for spam filtering. It is already clear that the mail server indeed handles much less spam now, so it looks like a great success. Still, it is a rigorous change, and for the new few days I want to ask everybody to keep an eye out for disappearing posts. This message is crossposted. If you want to reply, please do so to me personally, not to the lists. Best wishes, Taco

1 0

Re: [NTG-pdftex] Extensions to \font syntax ?
by Thanh Han The 20 Dec '08

20 Dec '08

On Sun, Dec 07, 2008 at 10:39:09AM +0000, Philip TAYLOR wrote: > Taco Hoekwater wrote: > > > As for the original problem, I expect Thanh would use a Vietnamese > > font to typeset Vietnamese names. > > Yes, I accept that that is the proper way; but as > this letter was not only in Vietnamese but also in > Polish (possibly in some other languages as well, > quite apart from English) I thought it simpler to > stick to basic CM and to kludge my way around the > diacritics ... in this case, maybe it's better to stick with lm fonts which cover more languages? Regards, Thanh

7 8

[pdftex-Bugs][2242] typo in ttf2afm warning
by pdftex-bugs＠sarovar.org 16 Dec '08

16 Dec '08

Bugs item #2242, was opened at 2008-12-16 08:35 Status: Open 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: Accepted 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

Re: [NTG-pdftex] Extensions to \font syntax ?
by Thanh Han The 07 Dec '08

07 Dec '08

Hi Phil & Reinhard, Reinhard sumarized it well enough: it's not trivial to do. Also, adding new features to pdftex is not desired now. If you want to alter the font matrix, maybe it's worthwhile to take a look at the examples in samplepdf.tex. It requires some macro programming, but I am sure it's trivial for you. Regards, Thanh On Sun, Dec 07, 2008 at 06:57:16AM +0100, Reinhard Kotucha wrote: > Philip TAYLOR (Ret'd) writes: > > Dear Thanh / PdfTeX team -- > > > > Has any consideration ever been given to the idea > > of extending the syntax of TeX's \font command > > within the context (small "c") of PdfTeX ? > > > > What I have in mind are the following : > > > > \font \cmex = cmex10 rotated <angle> > > \font \cmex = cmex10 translated <matrix> > > Hi Phil, > I like such a feature too. But there are some technical problems. > Type 1 fonts have a font matrix which can be altered when a font is > loaded. It's quite easy to change the matrix in order to slant, > rotate, ... a font. But pdftex also supports TrueType fonts which are > lacking a font matrix. > > It doesn't mean that pdftex isn't able to do what you propose, but > it's nontrivial. It has to alter the so-called PDF text matrix. > But this sounds easier than it is. > > I made a similar suggestion a few years ago. I modified the text > matrix of a PDF file in order to slant an upright font and posted the > resulting PDF file to the mailing list. I asked whether pdftex can't > do something similar. I got a response from Mark Wicks, the author of > dvipdfm. He said: "Your example is too simple." He had been right, > things turned out to be much more difficult than I expected. > > And changing the matrix isn't sufficient. You'll certainly have to > adapt the .tfm files. All this doesn't look like a weekend project. > > Regards, > Reinhard > > -- > ---------------------------------------------------------------------------- > Reinhard Kotucha Phone: +49-511-3373112 > Marschnerstr. 25 > D-30167 Hannover mailto:reinhard.kotucha@web.de > ---------------------------------------------------------------------------- > Microsoft isn't the answer. Microsoft is the question, and the answer is NO. > ----------------------------------------------------------------------------

3 5

Extensions to \font syntax ?
by Philip TAYLOR (Ret'd) 07 Dec '08

07 Dec '08

Dear Thanh / PdfTeX team -- Has any consideration ever been given to the idea of extending the syntax of TeX's \font command within the context (small "c") of PdfTeX ? What I have in mind are the following : \font \cmex = cmex10 rotated <angle> \font \cmex = cmex10 translated <matrix> I ask because I am currently typesetting a letter requiring characters from a number of different languages, and I can successfully synthesise 99% of the characters I need from the basic CM family. However, I am stuck at o-horn and u-horn (Vietnamese). I can get reasonably close by scaling and positioning "3B or "7D from CMEX<whatever>, but I would like to get even closer, and being able to rotate the font (and perhaps transform it) would take me from "reasonably close" to "d@mn nigh perfect" :-) ** Phil.

2 1

[pdftex] New document - eUahbLqeIb
by noreply＠sarovar.org 29 Nov '08

29 Nov '08

Project: pdftex Group: Document title: eUahbLqeIb Document description: rwRYGiGYJPTV Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

[pdftex-Bugs][2083] problem with copyStream() (file pdftoepdf.cc)
by pdftex-bugs＠sarovar.org 26 Nov '08

26 Nov '08

Bugs item #2083, was opened at 2008-08-12 15:50 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: problem with copyStream() (file pdftoepdf.cc) Category: PDF inclusion Group: None >Resolution: Fixed Initial Comment: the assignment pdflastbyte = pdfbuf[pdfptr - 1]; in copyStream() (file pdftoepdf.cc) may cause segfault, since there is no checking if pdfptr is > 0. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2083&group_id=106

1 0

[pdftex-Bugs][2082] font_dim[FONTNAME_CODE] not initialized (writefont.c)
by pdftex-bugs＠sarovar.org 26 Nov '08

26 Nov '08

Bugs item #2082, was opened at 2008-08-12 15:45 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: font_dim[FONTNAME_CODE] not initialized (writefont.c) Category: Fonts Group: None Resolution: Accepted Initial Comment: I found an issue with writefont.c: when a new en_entry is created, the value of font_dim[FONTNAME_CODE] is not initialized. For T1 fonts this is not a problem since all T1 fonts have fontname, but for TT fonts some weird fonts might not have [I ran into this problem during a test on some large TT fonts with valgrind] Here is the suggested patch: Index: source/src/texk/web2c/pdftexdir/writefont.c =================================================================== --- source/src/texk/web2c/pdftexdir/writefont.c (revision 508) +++ source/src/texk/web2c/pdftexdir/writefont.c (revision 509) @@ -81,7 +81,7 @@ fd->fn_objnum = 0; fd->all_glyphs = false; fd->write_ttf_glyph_names = false; - for (i = 0; i < INT_KEYS_NUM; i++) { + for (i = 0; i < FONT_KEYS_NUM; i++) { fd->font_dim[i].val = 0; fd->font_dim[i].set = false; } ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2082&group_id=106

1 0

[pdftex-Bugs][2090] enabling LFS breaks PDF inclusion on some systems
by pdftex-bugs＠sarovar.org 26 Nov '08

26 Nov '08

Bugs item #2090, was opened at 2008-09-17 06:33 >Status: Closed Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: enabling LFS breaks PDF inclusion on some systems Category: PDF inclusion Group: v1.40.8 >Resolution: Fixed Initial Comment: see http://tug.org/pipermail/tex-live/2008-September/017691.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2090&group_id=106

1 0

[pdftex-Patches][945] experimental support for tagged PDF
by pdftex-patches＠sarovar.org 23 Nov '08

23 Nov '08

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

1 0

Using truetype fonts with pdftex
by Thanh Han The 20 Nov '08

20 Nov '08

Hi, the question how to use truetype fonts with pdftex keeps popping up from time to time, so I wrote some (draft) notes which would be added to the official pdftex manual. Comments/suggestions welcome. Regards, Thanh ====================================================== \subsection{A closer look at TrueType fonts and pdftex} The most common outline format for tex is t1. ttf fonts are slightly different from t1 and hence requires some extra work to get it right. An important issue when dealing with ttf is to understand the way how t1 and ttf handle encoding and glyph names (or more precisely, glyph ``identity''). t1 is familiar with tex users, so let's start with it first: t1 refers to glyphs by names, ie each glyph is identified by its name like `/A', `/comma', etc. Given a glyph name, it's easy to tell if a t1 font contains that glyph or not. Encoding with t1 is therefore simple: given a number (between 0..255), an encoding tells us the name to get the relevant glyph. With ttf the situation is not that simple, since ttf doesn't use name to refer to glyphs, but ``indices''. This means that each glyph is identified by its index, not its name. The indices are numbers that differ from font to font. ttf handle encodings by a mechanism called ``cmap'', which are roughly tables containing mapping from character code to glyph index. A ttf font can contain one or more such tables (each corresponds to an encoding). Since glyph names are not strictly necessary for ttf, they are not always available inside a ttf font. Given a ttf font, one of the following case may happen: \startitemize[a,packed] \item the font contains correct names for all its glyphs. This is the ideal situation and is often the case for high-quality latin fonts. \item the font contains wrong name for all or most of its glyphs. This is the worst situation that often happens with poor-quality fonts, or fonts converted from other formats. \item the font contains no glyph names at all. Newer version of Palatino fonts by Linotype (v1.40, coming with Windows XP) is one example. \item the font contains correct names for most glyphs, and no names or wrong names for a few glyphs. This happens from time to time. \stopitemize One may wonder how things can be so complex with glyph names in ttf. The reason is that t1 fonts rely on correct names to work properly. If a glyph has wrong name, it get noticed immediately. ttf as mentioned before don't use names for its encoding. So, if glyph names in a ttf font are wrong or missing, it's usually not a big deal and often goes unnoticed. The potential problem with using ttf in pdftex is that we are so used to the t1 encoding convention which relies on correct glyph names. Most font tools also rely on this convention; all encoding file (.enc files) use glyph names, too. But as discussed above, glyph names in ttf is not something very reliable. If we encounter a font that doesn't have correct names for all glyphs, we need to do some more work. If glyph names are not correct, we need a better way to refer to a glyph in ttf fonts than using its name. The most reliable way seems to be via Unicode: most ttf fonts provide correct mapping from unicode to glyph index. This is something we can count on, since it is required for a ttf to be usable. >From version 1.21a pdftex supports the naming convention `uniXXXX' in encoding files. This only makes sense with ttf fonts, of course. When pdftex sees for example `uni12AB', it will: \startitemize[a,packed] \item read the table <unicode> -> <glyph-index> from the font; \item loop up the value '12AB' in the table; if found then pick the relevant glyph index. \stopitemize ttf2afm also does the same lookup when it sees names like `uni12AB'. Now let's review the minimal steps to get a ttf font working with pdftex: \startitemize[a,packed] \item generate an afm from ttf using ttf2afm. Example: \starttyping ttf2afm -e 8r.enc -o times.afm times.ttf \stoptyping \item convert afm to tfm using whatever tool suitable: afm2tfm, fontinst, afm2pl, etc. Example: \starttyping afm2tfm times.afm -T 8r.enc \stoptyping \item create the needed map entry for the font. Example: \starttyping \pdfmapfile{+times TimesNewRomanPSMT <8r.enc <times.ttf} \stoptyping \stopitemize That was the easiest case when glyph names are correct. Now let's have a font where we cannot rely on glyph names, for example Palatino by Linotype, version 1.40. Let's assume we want to use T1 encoding with this font. So we put pala.ttf and ec.enc in the current directory before processing further. The first attempt would be: \starttyping ttf2afm -e ec.enc -o pala.afm pala.ttf \stoptyping However, since the names in ec.enc are not available in pala.ttf (in fact there are no names inside the font), we would get a bunch of warnings: \starttyping Warning: ttf2afm (file pala.ttf): no names available in `post' table, print glyph names as indices Warning: ttf2afm (file pala.ttf): glyph `grave' not found . . . \stoptyping and the output pala.afm will contain no names at all. Instead of glyph names in ec.enc, we get weird things like `index123'. And all glyphs are not encoded: \starttyping C -1 ; WX 832 ; N index10 ; B 24 -3 807 689 ; . . . \stoptyping We try again, this time without giving encoding: \starttyping ttf2afm -o pala.afm pala.ttf \stoptyping This time since we didn't ask ttf2afm to re-encode the output afm, we get less warning: \starttyping Warning: ttf2afm (file pala.ttf): no names available in `post' table, print glyph names as indices \stoptyping and the afm output is the same as in the previous attempt. Which is not very useful, since there is little we can do with those names like `index123'. So we try to go with Unicode: \starttyping ttf2afm -u -o pala.afm pala.ttf \stoptyping This time we get another bunch of warnings like: \starttyping Warning: ttf2afm (file pala.ttf): glyph 108 have multiple encodings (the first one being used): uni0162 uni021A . . \stoptyping It is hard to understand what tfm2afm tells us by this message at the first sight. So let's recap the connection between glyph name, glyph index and unicode: \startitemize[a,packed] \item glyphs are identified internally by index. \item <glyph-name> -> <glyph-index> is optional, and not always reliable. So is <glyph-index> -> <glyph-name>. \item <unicode> -> <glyph-index> is (almost) always present and reliable. \item <glyph-index> -> <unicode> is not always reliable, and it's not even a mapping, since there can be more unicodes that map to a glyph index. Therefore, given glyph index, it's not always possible to get an unicode corresponding to that index: there can be none, or more than one. If there is none, glyph index will be used (eg `index123'). If there are more, like in this case we have two unicodes 0162 021A that are mapped to glyph index 108. And we have asked ttf2afm to print glyph by unicode, so ttf2afm cannot know which value to print in this case. Hence it simply sticks with the first unicode and writes a warning. \stopitemize Now if all we want is to use pala.ttf with T1 encoding (and don't care about ligatures), probably the easiest way is to create a new enc file ec-uni.enc from ec.enc, where all glyph names are replaced by unicode. This can be done easily for example by a Perl script that read the AGL (Adobe Glyph List, available at http://www.adobe.com/devnet/opentype/archives/glyphlist.txt and then convert all glyph names to unicode). Assume that we already have ec-uni.enc, the needed steps to create the tfm can look as: \starttyping ttf2afm -u -e ec-uni.enc -o pala-t1.afm pala.ttf afm2pl pala-t1.afm pltotf pala-t1.pl \stoptyping and to use the font: \starttyping \pdfmapline{+pala-t1 <ec-uni.enc <pala.ttf} \font\f=pala-t1\f This is a test of font Palatino Regular in T1 encoding. \stoptyping If we want to do more than just using pala.ttf with T1 encoding, for example to process the afm output with fontinst for more a complex font setup, then we must process slightly different. Having an afm file where all glyph names are converted to `uniXXXX' form is not very useful for fontinst. Instead, we need an afm file with AGL names to use with fontinst. We do so by: \startitemize[a,packed] \item generate an afm with glyph names in form `uniXXXX' \starttyping ttf2afm -u -o pala.afm pala.ttf \stoptyping \item convert pala.afm to pala-agl.afm, so that pala-agl.afm contains AGL names only. Again, a simple Perl script can do that. \item process pala-agl.afm by fontinst as needed. \item in the final stage, when we already have the tfm's from fontinst and friends, plus the map entries (generated by fontinst, or created manually), we need to replace the encoding by their counterpart with `uniXXXX' names. For example, if fontinst tell us to add a line saying \starttyping pala-agl-8r <8r.enc <pala.ttf \stoptyping to our map file, then we need to change that line to \starttyping pala-agl-8r <8r-uni.enc <pala.ttf \stoptyping where 8r-uni.enc is derived from 8r.enc by converting all glyph names to the `uniXXXX' form. \stopitemize

1 0

[tex-live] TeX Live 2008: nasty pdf(la
by 8139003206＠mymetropcs.com 14 Nov '08

14 Nov '08

tex bug on Solaris SPARC with ZFS)

1 0

image inclusion on samba shares :-(
by Martin Schröder 04 Nov '08

04 Nov '08

Hi, we're having problems with image inclusion on samba shares: the case-(in)sensitivity of pdftex/LaTeX differs in places. The setup is a Linux vm mounting a samba share from a Linux server. We do an \includegraphics with a filename that differs in case from the file on the server (say "Foo.jpg" instead of "foo.jpg"). Since the samba mount is per default case-insensitive, we can see (e.g. with "ls") the file on the client. But pdftex exits with "pdflatex: Foo.jpg: No such file or directory", which is not written to the logfile, and we end up with an empty or corrupt pdf. The image inclusion in pdftex.def first checks if the file exists; apparently this works, although the later image inclusion fails. And the image inclusion fails so horribly that pdftex has no chance to clean up after itself (it simly exits in xfopen). Can we fix this in pdftex.def or must pdftex (and luatex) be changed? Best Martin

3 6