- ntg-pdftex - NTG Mailing Lists

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

23 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

[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