- ntg-pdftex - NTG Mailing Lists

[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 15 Jan '09

15 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 19 Dec '08

19 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