- ntg-pdftex - NTG Mailing Lists

[pdftex-Bugs][2100] colors on page influenced by included pdf image
by pdftex-bugs＠sarovar.org 10 Oct '08

10 Oct '08

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

1 0

[pdftex-Bugs][2100] colors on page influenced by included pdf image
by pdftex-bugs＠sarovar.org 10 Oct '08

10 Oct '08

Bugs item #2100, was opened at 2008-10-09 00:18 Status: Open Priority: 3 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Nobody (None) Summary: colors on page influenced by included pdf image Category: PDF inclusion Group: None Resolution: None Initial Comment: I've got a problem with defined colors on a page when I include a pdf image. The original file (regression-org.pdf) is included on the second page: blue and red on that page are different from the blue and red on the other pages. However, if I convert the included pdf image to ps via pdftops and back to pdf via pstopdf (regression.pdf), there's no problem as shown on the last page. Is this a bug in pdftex, or am I using an "incorrectly" generated pdf image file, since a double conversion seems to produce the correct output? (I'm using texlive's 2008 pdftex 1.40.9) Best regards Stefan ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-10-10 10:13 Message: It's a known problem of later AR versions if transparency is involved. Then AR seems to be using a different method for displaying the page and colors may change. PostScript doesn't support transparency, thus converting to PS and back to PDF gets rid of the transparency. Tested with: * AR7/Linux, AR8/Linux: wrong displayed colors * AR5/Linux: correct colors * xpdf3.00: correct colors * gs8.54: correct colors, but warnings for second page: CS/cs (setcolorspace) operand not a name: [/ICCBased -dict-] * gs8.62: fails on page two with /unknownerror. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2100&group_id=106

1 0

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

09 Oct '08

Bugs item #2100, was opened at 2008-10-09 00:18 Status: Open Priority: 3 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Nobody (None) Summary: colors on page influenced by included pdf image Category: PDF inclusion Group: None Resolution: None Initial Comment: I've got a problem with defined colors on a page when I include a pdf image. The original file (regression-org.pdf) is included on the second page: blue and red on that page are different from the blue and red on the other pages. However, if I convert the included pdf image to ps via pdftops and back to pdf via pstopdf (regression.pdf), there's no problem as shown on the last page. Is this a bug in pdftex, or am I using an "incorrectly" generated pdf image file, since a double conversion seems to produce the correct output? (I'm using texlive's 2008 pdftex 1.40.9) Best regards Stefan ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2100&group_id=106

1 0

[pdftex-Patches][2098] Fix for xref_offset_width
by pdftex-patches＠sarovar.org 30 Sep '08

30 Sep '08

Patches item #2098, was opened at 2008-09-30 11:58 Status: Open Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) Summary: Fix for xref_offset_width Resolution: None Group: v1.50.0 Category: Large File Support Initial Comment: We have observed corrupted PDFs with PDF 1.5, object compression and moderately large files (200MB). Apparently the code to set xref_offset_width is not really portable; I've instead of Pascal implemented it in C and made it more robust. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=2098&group_id=106

1 0

SyncTeX, file names with spaces and other funny characters
by LAURENS Jérôme 19 Sep '08

19 Sep '08

Hi, there is actually a bug when SyncTeX has to manage spaces in file names. This bug only appears in pdfTeX, but not in XeTeX. Here it is: xetex --synctex=1 "my file" creates a file named <my file.synctex.gz>, whereas pdftex --synctex=1 "my file" creates a file named <"my file".synctex.gz>. Note that the 2 quote chars are considered by pdftex part of the name. This difference is due to some "normalize_quotes" function being used differently in XeTeX and pdfTeX. As usual, it is really difficult to understand how TeX handles things internally. This is why I submit you my simple fix before texlive is updated, you may have a better approach. The fix is simply to rely on the output_file_name (instead of the jobname), remove the terminating path extension and append to one required by SyncTeX. It works for the very simple tests I could think of. Do you agree? BTW, it is natural to ask whether different but similar problems may occur. Assuming the funny file named <tes"t.tex> exists xetex tes\"t.tex works properly whereas pdftex tes\"t.tex breaks in the normalize_quotes function with the message: ! Unbalanced quotes in argument tes"t.tex Are there reasons for such a discrimination?

2 1

[pdftex-Bugs][2092] Ligatures and special characters in included pdf disappear in typesetted document
by pdftex-bugs＠sarovar.org 18 Sep '08

18 Sep '08

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 >Resolution: Accepted Group: None Category: PDF inclusion 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: 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

Re: [NTG-pdftex] Possible Bug: Ligatures and special Character in included pdf disappear in typetted document
by Thanh Han The 18 Sep '08

18 Sep '08

Hello Michael, thanks for the bug report. Can you please also submit it to the pdftex bug tracker http://sarovar.org/tracker/?atid=493&group_id=106&func=browse thanks, Thanh On Thu, Sep 18, 2008 at 12:51:18PM +0200, Jan Michael wrote: > 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 > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex

1 0

Possible Bug: Ligatures and special Character in included pdf disappear in typetted document
by Jan Michael 18 Sep '08

18 Sep '08

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

1 0

[pdftex-Bugs][2092] Ligatures and special characters in included pdf disappear in typesetted document
by pdftex-bugs＠sarovar.org 18 Sep '08

18 Sep '08

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 Resolution: None Group: None Category: PDF inclusion 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 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=2092&group_id=106

1 0

[pdftex-Patches][2091] bugfix for #2090
by pdftex-patches＠sarovar.org 17 Sep '08

17 Sep '08

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

1 0

[pdftex-Patches][2091] bugfix for #2090
by pdftex-patches＠sarovar.org 17 Sep '08

17 Sep '08

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

1 0

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

17 Sep '08

Bugs item #2090, was opened at 2008-09-17 06:33 Status: Open Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: enabling LFS breaks PDF inclusion on some systems Resolution: Accepted Group: v1.40.8 Category: PDF inclusion 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

Re: [NTG-pdftex] [tex-live] TeX Live 2008: nasty pdf(la)tex bug on Solaris SPARC with ZFS
by Thanh Han The 13 Sep '08

13 Sep '08

done. many thanks to Vladimir. Thanh On Sat, Sep 13, 2008 at 07:03:11PM +0400, Vladimir Volovich wrote: > i've debugged it. it appears to be caused by a misfeature (or bug) of > the C pre-processor: > > [...] > > i'd like to ask pdftex maintainers to apply this patch to their master > sources and to texlive tree: > > --- texk/web2c/pdftexdir/writet1.c > +++ texk/web2c/pdftexdir/writet1.c > @@ -26,7 +26,7 @@ > static const char _svn_version[] = > "$Id$ $URL: http://scm.foundry.supelec.fr/svn/pdftex/branches/stable/source/src/texk/we… $"; > > -#define t1_log(s) tex_printf("%s",s) > +#define t1_log(str) tex_printf("%s",str) > #define get_length1() t1_length1 = t1_offset() - t1_save_offset > #define get_length2() t1_length2 = t1_offset() - t1_save_offset > #define get_length3() t1_length3 = fixedcontent? t1_offset() - t1_save_offset : 0 > > i've commited a fixed aix binary which now correctly shows the fonts. > > Best, > v.

1 0

Re: [NTG-pdftex] [tex-live] TeX Live 2008: nasty pdf(la)tex bug on Solaris SPARC with ZFS
by Vladimir Volovich 13 Sep '08

13 Sep '08

"KB" == Karl Berry writes: VV> odd things noticed on AIX: 1) pdftex prints some garbage to VV> terminal and to the log instead VV> 1) pdftex prints some garbage to terminal and to the log instead VV> of the list of preloaded fonts. here is the diff between terminal output VV> on aix and solaris: VV> (/mnt/Master/texmf-dist/tex/context/base/supp-pdf.tex VV> [Loading MPS to PDF converter (version 2006.09.02).] VV> ) <cgolfer.pdf, id=1, 597.50829pt x 845.0471pt> <use cgolfer.pdf> [1{/mnt/Maste VV> -r/texmf/fonts/map/pdftex/updmap/pdftex.map} <./cgolfer.pdf>] (./test.aux) )2004 VV> -612640pen_name_prefix(ur_file_name?lose_name_suffix2004612640pen_name_prefix?ur VV> -_file_name?lose_name_suffix2004612640pen_name_prefixxur_file_name?lose_name_suf VV> -fix2004612640pen_name_prefix?ur_file_name?lose_name_suffix VV> +r/texmf/fonts/map/pdftex/updmap/pdftex.map} <./cgolfer.pdf>] (./test.aux) )</mn VV> +t/Master/texmf-dist/fonts/type1/bluesky/cm/cmr10.pfb></mnt/Master/texmf-dist/fo VV> +nts/type1/bluesky/cm/cmr12.pfb></mnt/Master/texmf-dist/fonts/type1/bluesky/cm/c VV> +mti12.pfb></mnt/Master/texmf-dist/fonts/type1/bluesky/cm/cmtt12.pfb> VV> Output written on test.pdf (1 page, 40672 bytes). VV> Transcript written on test.log. KB> Possibly a compiler bug? Anyway, if it only happens on AIX, I KB> fear you're the only one who can debug it ... i've debugged it. it appears to be caused by a misfeature (or bug) of the C pre-processor: writet1.c contains #define t1_log(s) tex_printf("%s",s) and then constructs such as t1_log(open_name_prefix); t1_log(cur_file_name); get pre-processed to tex_printf("%open_name_prefix",open_name_prefix); tex_printf("%cur_file_name",cur_file_name); instead of tex_printf("%s",open_name_prefix); tex_printf("%s",cur_file_name); i fixed this by changing the define to #define t1_log(str) tex_printf("%s",str) grepping texlive sources shows that this is probably the only place which could cause such problem. i'd like to ask pdftex maintainers to apply this patch to their master sources and to texlive tree: --- texk/web2c/pdftexdir/writet1.c +++ texk/web2c/pdftexdir/writet1.c @@ -26,7 +26,7 @@ static const char _svn_version[] = "$Id$ $URL: http://scm.foundry.supelec.fr/svn/pdftex/branches/stable/source/src/texk/we… $"; -#define t1_log(s) tex_printf("%s",s) +#define t1_log(str) tex_printf("%s",str) #define get_length1() t1_length1 = t1_offset() - t1_save_offset #define get_length2() t1_length2 = t1_offset() - t1_save_offset #define get_length3() t1_length3 = fixedcontent? t1_offset() - t1_save_offset : 0 i've commited a fixed aix binary which now correctly shows the fonts. Best, v.

1 0

Re: [NTG-pdftex] [tex-live] pdftex LFS bug: on mac too?
by Thanh Han The 12 Sep '08

12 Sep '08

I reported what I found after some investigation and testing. If most of this is already known to you, then I applogize for posting them. Martin has already provided a good fix for TL: added --disable-largefile to the Build script. A slightly better fix is to disable LFS support by default, and change --disable-largefile to --enable-largefile Someone may want to fix the config stuff to get LFS working on all systems. It seems hard to me so I will not try that. I vote for disabling LFS by default, and document that enabling LFS might break things on some systems. Regards test case: I will submit I I have to TL, if Karl agrees. However, it's not anything close to systematic. Regards, Thanh On Fri, Sep 12, 2008 at 06:28:21PM +0200, Norbert Preining wrote: > On Fr, 12 Sep 2008, Thanh Han The wrote: > > Some more relevant info about the problem: > > Most of that was known already, we would be in need of good test cases > and a good fix. > > Maybe you could check up with Martin to get a quick *and* working fix. > > Thanks. > > Norbert > > ------------------------------------------------------------------------------- > Dr. Norbert Preining <preining(a)logic.at> Vienna University of Technology > Debian Developer <preining(a)debian.org> Debian TeX Group > gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 > ------------------------------------------------------------------------------- > YARMOUTH (vb.) > To shout at foreigners in the belief that the louder you speak, the > better they'll understand you. > --- Douglas Adams, The Meaning of Liff

1 0

Re: [NTG-pdftex] [tex-live] pdftex LFS bug: on mac too?
by Thanh Han The 12 Sep '08

12 Sep '08

Some more relevant info about the problem: - LFS was added to pdftex since version 1.40.6. It was enabled by default. To disable it, one must run "configure" with the option "--disable-largefile". - also starting from version 1.40.6, the "build.sh" script coming with pdftex sources tarball has the option "--disable-largefile" when calling "configure". This means that pdftex compiled from sources will have LFS disabled by default, unless one changes the "build.sh" script to remove that option to enable LFS, or skips "build.sh" and calls "configure" by himself. - the "Build" script used to build texlive does NOT have the option "--disable-largefile" by default, which means that TL is built with LFS enabled by default. - LFS has been broken on some systems since 1.40.6: - on Solaris SPARC: 1.40.6--1.40.9 have the same problem as current TL - on MacOSX PowerPC: - 1.40.6: pdftex failed with a message "Invalid argument". A google search shows that a similar problem was discussed on the context list: http://www.ntg.nl/pipermail/ntg-context/2008/031066.html - 1.40.7--1.40.9: same problem as current TL Thanh

1 0

Altona Test Suite
by Martin Schröder 10 Sep '08

10 Sep '08

Have a look at http://www.eci.org/doku.php?id=en:projects:ats and the files on http://www.eci.org/doku.php?id=en:downloads Best Martin

1 0

update on "nasty pdf(la)tex bug on Solaris SPARC with ZFS"
by Thanh Han The 10 Sep '08

10 Sep '08

I don't have a fix yet, just some more info: it's very likely that the problem is caused by inconsistent declaration of type longinteger. Tracing it down is not easy due to nested inclusion of header files, however a quick check can be done in gdb as follows: ,-------- | info type longinteger | | All types matching regular expression "longinteger": | | File pdftexini.c: | typedef long long int longinteger; | | File pdftex0.c: | typedef long long int longinteger; | | [...many files with the same declaration of longinteger...] | | File ../../../../src/texk/web2c/pdftexdir/writejbig2.c: | typedef long int longinteger; | | File ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc: | typedef long int longinteger; `-------- Note that the last 2 declarations are "long int" and not "long long int" longinteger is defined in web2c/config.h as off_t, which also has inconsistent declaration over different files: like longinteger, it's "long long int" for most files, except the following: ,-------- | File ../../../../src/libs/xpdf/goo/gfile.cc: | typedef long int off_t; | | File ../../../../src/texk/web2c/pdftexdir/pdftoepdf.cc: | typedef long int off_t; `-------- Thanh On Tue, Sep 09, 2008 at 04:20:58PM +0200, The Thanh Han wrote: > after some hours debugging, here is what I can confirm: > > - the problem is with LFS enabled only; re-compiled pdftex > with LFS disabled doesn't have this problem. > > - the problem seems to be related to the value of variable > pdfptr gone wild at certain moment, not to the *seek() > functions. > > - it seems a bug of pdftex, not compiler. > > > Regards, > Thanh > > On Tue, Sep 09, 2008 at 02:49:41PM +0400, Vladimir Volovich wrote: > > "THT" == Thanh Han The writes: > > > > THT> I also confirm this bug. This is caused by LFS. I did a lot of > > THT> testing with pdf inclusion on utah machines before TL release, > > THT> unfortunately with LFS always disabled so this bug was not > > THT> detected. > > > > i tested the same on AIX, and got even weirder messages: > > > > [skipped] > > (/mnt/Master/texmf-dist/tex/context/base/supp-pdf.tex > > [Loading MPS to PDF converter (version 2006.09.02).] > > ) <cgolfer.pdf, id=1, 597.50829pt x 845.0471pt> <use cgolfer.pdf> [1{/mnt/Maste > > r/texmf/fonts/map/pdftex/updmap/pdftex.map} <./cgolfer.pdf>] (./test.aux) )2004 > > 640010pen_name_prefixHur_file_name > > lose_name_suffixpdflatex: test: Invalid argument > > > > i'll recompile sparc-solaris and powerpc-aix using --disable-largefile > > and will look if it helps. > > > > i didn't have an idea that LFS should be disabled because of such > > buggy behavior. the above messages on AIX look strange too. at least > > on solaris i get a meaningful error message. > > > > Best, > > v.

2 1

Re: [NTG-pdftex] [tex-live] TeX Live 2008: nasty pdf(la)tex bug on Solaris SPARC with ZFS
by Thanh Han The 09 Sep '08

09 Sep '08

after some hours debugging, here is what I can confirm: - the problem is with LFS enabled only; re-compiled pdftex with LFS disabled doesn't have this problem. - the problem seems to be related to the value of variable pdfptr gone wild at certain moment, not to the *seek() functions. - it seems a bug of pdftex, not compiler. Regards, Thanh On Tue, Sep 09, 2008 at 02:49:41PM +0400, Vladimir Volovich wrote: > "THT" == Thanh Han The writes: > > THT> I also confirm this bug. This is caused by LFS. I did a lot of > THT> testing with pdf inclusion on utah machines before TL release, > THT> unfortunately with LFS always disabled so this bug was not > THT> detected. > > i tested the same on AIX, and got even weirder messages: > > [skipped] > (/mnt/Master/texmf-dist/tex/context/base/supp-pdf.tex > [Loading MPS to PDF converter (version 2006.09.02).] > ) <cgolfer.pdf, id=1, 597.50829pt x 845.0471pt> <use cgolfer.pdf> [1{/mnt/Maste > r/texmf/fonts/map/pdftex/updmap/pdftex.map} <./cgolfer.pdf>] (./test.aux) )2004 > 640010pen_name_prefixHur_file_name > lose_name_suffixpdflatex: test: Invalid argument > > i'll recompile sparc-solaris and powerpc-aix using --disable-largefile > and will look if it helps. > > i didn't have an idea that LFS should be disabled because of such > buggy behavior. the above messages on AIX look strange too. at least > on solaris i get a meaningful error message. > > Best, > v.

2 1

Re: [NTG-pdftex] [tex-live] TeX Live 2008: nasty pdf(la)tex bug on Solaris SPARC with ZFS
by Thanh Han The 09 Sep '08

09 Sep '08

I also confirm this bug. This is caused by LFS. I did a lot of testing with pdf inclusion on utah machines before TL release, unfortunately with LFS always disabled so this bug was not detected. Thanh PS: Perhaps TL should have been built with LFS disabled, since this feature is still highly experimental and has been not tested well enough. On Tue, Sep 09, 2008 at 06:03:19AM +0400, Vladimir Volovich wrote: > "NHFB" == Nelson H F Beebe writes: > > NHFB> I now have a simple test case that exhibits the problem, and > NHFB> experiments show that it manifests itself only on Sun Solaris > NHFB> SPARC. > > NHFB> On a ZFS system, I see something like this: > [...] > NHFB> 107T Sep 8 16:38 bug.pdf > > NHFB> On a UFS Solaris SPARC system (/var/tmp), I see this: > > NHFB> % pdflatex bug.tex ... pdflatex: bug: File too large > > i built solaris sparc binaries for texlive, and i can reproduce this > behavior too. there is nothing related to ZFS. it only doesn't complain > about a big file size, while UFS returns EFBIG (shown by truss): > > write(6, " F 1 5 F 1 6 F 1 7 F 1 8".., 8192) = 8192 > write(6, "C4CD97 kB29E9C0FF8DFCC B".., 330) = 330 > llseek(6, 0x0000330C00000EDC, SEEK_SET) = 0x330C00000EDC > write(6, " 4 9 1 6", 4) Err#27 EFBIG > > because of a big lseek before the write. maybe it is because of a > compiler bug, or maybe it is a pdftex bug. therefore i'm also forwarding > to the ntg-pdftex list. does anybody have an idea if it's likely a > compiler bug or a pdftex bug? > > Best, > v. > > P.S. for those on nts-pdftex who are not subscribed to texlive list, > here is the snippet with a test case: > ================================================================= > Here is the test file: > > % cat bug.tex > > \documentclass[]{article} > > \usepackage{graphicx} > > \begin{document} > > This is a picture of a golfer: > > \centerline{\includegraphics[width = 0.5\textwidth]{cgolfer}} > > \end{document} > > The cgolfer.pdf file can be found here: > > http://www.math.utah.edu/~beebe/cgolfer.pdf > > The bug is unrelated to the particular PDF file that is included as a > graphics image.

2 1

Re: [NTG-pdftex] [tex-live] TeX Live 2008: nasty pdf(la)tex bug on Solaris SPARC with ZFS
by Vladimir Volovich 09 Sep '08

09 Sep '08

"NHFB" == Nelson H F Beebe writes: NHFB> I now have a simple test case that exhibits the problem, and NHFB> experiments show that it manifests itself only on Sun Solaris NHFB> SPARC. NHFB> On a ZFS system, I see something like this: [...] NHFB> 107T Sep 8 16:38 bug.pdf NHFB> On a UFS Solaris SPARC system (/var/tmp), I see this: NHFB> % pdflatex bug.tex ... pdflatex: bug: File too large i built solaris sparc binaries for texlive, and i can reproduce this behavior too. there is nothing related to ZFS. it only doesn't complain about a big file size, while UFS returns EFBIG (shown by truss): write(6, " F 1 5 F 1 6 F 1 7 F 1 8".., 8192) = 8192 write(6, "C4CD97 kB29E9C0FF8DFCC B".., 330) = 330 llseek(6, 0x0000330C00000EDC, SEEK_SET) = 0x330C00000EDC write(6, " 4 9 1 6", 4) Err#27 EFBIG because of a big lseek before the write. maybe it is because of a compiler bug, or maybe it is a pdftex bug. therefore i'm also forwarding to the ntg-pdftex list. does anybody have an idea if it's likely a compiler bug or a pdftex bug? Best, v. P.S. for those on nts-pdftex who are not subscribed to texlive list, here is the snippet with a test case: ================================================================= Here is the test file: % cat bug.tex \documentclass[]{article} \usepackage{graphicx} \begin{document} This is a picture of a golfer: \centerline{\includegraphics[width = 0.5\textwidth]{cgolfer}} \end{document} The cgolfer.pdf file can be found here: http://www.math.utah.edu/~beebe/cgolfer.pdf The bug is unrelated to the particular PDF file that is included as a graphics image.

2 1

[pdftex-Patches][2088] Patch for layer inclusion
by pdftex-patches＠sarovar.org 01 Sep '08

01 Sep '08

Patches item #2088, was opened at 2008-09-01 13:44 Status: Open Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) Summary: Patch for layer inclusion Resolution: None Group: v1.50.0 Category: PDF inclusion Initial Comment: Attached is a patch for the inclusion of layers which supersedes the functionality already in 1.50 (but keeps that) and provides the ability to merge layers from different pdfs (or with layers from the main document). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=2088&group_id=106

1 0

Re: [NTG-pdftex] Patch to support CMap namespaces
by Thanh Han The 28 Aug '08

28 Aug '08

can you please submit your patch to http://sarovar.org/tracker/?atid=495&group_id=106&func=browse thanks, Thanh On Thu, Aug 28, 2008 at 12:59:51AM +0300, Vasile Gaburici wrote: > There are a couple of LaTeX packages out there that provide CMaps. > They don't work as well as \pdfglyphtounicode, i.e. virtual fonts > don't get CMaps at all (the CMap is included in the PDF but not > referenced), and otftotfm-installed fonts lack the CMap entries for > the ligatures that otftotfm sneaks in empty slots. As you know, > \pdfglyphtounicode fixes these problems. > > On the other hand, these two packages let the user specify a CMap for > each LaTeX encoding, so the user ca give different Unicode values to > the same PS glyph name in different LaTeX encodings. Of course that > works properly only if the fonts invoked by the different LaTeX > encodings are different; otherwise only one can win the \pdffontattr. > A compelling application of this feature are CMaps that set math code > points (usually above BMP) for TeX math fonts; those glyphs have > exactly the same names as in text fonts /A etc. Adding namespaces to > \pdfglyphtounicode makes those two packages obsolete in their current > implementation. > > Another advantage of namespaces is the ability to (reliably) fix > TrueType font CMaps. The troublesome glyphs are usually ligatures that > don't have a Unicode entry (Th, ti, tf, ffb, etc.), which otftotfm > writes as /indexZZZ in the enc file. Putting those in a per-font > namespace avoids any potential clashes. > > So, I've patched pdftex to provide namespaces using the following > syntax extension: the first argument of \pdfglyphtounicode can now > take additional forms: > \pdfglyphtounicode{fnt:tex-font-name/ps-glyph-name}{...} > \pdfglyphtounicode{enc:ps-enc-name/ps-glyph-name}{...} > > Since fonts for which the built-in encoding is used happen to be > exactly those that have multiple design sizes (cmr, stmary etc.), > using a separate ps-enc-name for each is not helpful. Instead, the > 'enc' namespace for those is obtained by dropping any final digits > from the font name, e.g. cmr10 has PS encoding cmr (for CMap purposes > only). > > The search policy is to first search the font namespce, then the > encoding, and finally the global namespace, for which the syntax > remains unchanged. All these namespace are implemented in the same avl > tree; just using the above strings as key names. In theory this makes > the search 3 times slower, but that particular phase of pdftex hardly > takes any time, so it seemed premature to implement any optimization. > > Some usage examples: > > % make the ti ligature searchable in Calibri regular > \pdfglyphtounicode{fnt:calibly1--base/index415}{0074 0069} > % go crazy with Unicode math; TeX math italic gives above-BMP math A > \pdfglyphtounicode{enc:cmmi/A}{D835 DC34} % UTF16BE required > > Note that search behavior for math letters varies with pdf viewers. > Acrobat implements only canonical equivalence, so you need to enter > the exact code point, and copy/paste preserves the code points, so you > can paste into a LaTeX document if it's using utf8x input encoding. > Evince implements compatibility equivalence, so it's easier to find > those math As by searching for plain A, but they also copy/paste as > plain A. You can use pdftotext however, which uses the same poppler > backend, to have the code points are preserved. I'm not really > advocating Unicode math letters, but now they're easily supported in > pdftex -- no need for manual CMaps anymore. > > BTW, \pdfglyphtounicode now really needs to be documented in the > manual, so people would stop writing (buggy) CMaps by hand. I > volunteer to do it if you accept the patch :) > > I also wrote some CMap handling tools, mostly for verification, I'll > send a separate announcement about that. > diff -up pdftex-1.40.9/src/texk/web2c/pdftexdir/ptexlib.h.nons pdftex-1.40.9/src/texk/web2c/pdftexdir/ptexlib.h > --- pdftex-1.40.9/src/texk/web2c/pdftexdir/ptexlib.h.nons 2008-08-26 17:44:23.000000000 +0300 > +++ pdftex-1.40.9/src/texk/web2c/pdftexdir/ptexlib.h 2008-08-26 17:45:35.000000000 +0300 > @@ -199,7 +199,7 @@ extern boolean handle_subfont_fm(fm_entr > /* tounicode.c */ > extern void glyph_unicode_free(void); > extern void deftounicode(strnumber, strnumber); > -extern integer write_tounicode(char **, char *); > +extern integer write_tounicode(char **, const char *, const char *); > > /* utils.c */ > extern boolean str_eq_cstr(strnumber, char *); > diff -up pdftex-1.40.9/src/texk/web2c/pdftexdir/tounicode.c.nons pdftex-1.40.9/src/texk/web2c/pdftexdir/tounicode.c > --- pdftex-1.40.9/src/texk/web2c/pdftexdir/tounicode.c.nons 2008-08-26 11:37:18.000000000 +0300 > +++ pdftex-1.40.9/src/texk/web2c/pdftexdir/tounicode.c 2008-08-27 21:41:54.000000000 +0300 > @@ -127,7 +127,7 @@ void deftounicode(strnumber glyph, strnu > } > > > -static long check_unicode_value(char *s, boolean multiple_value) > +static long check_unicode_value(const char *s, boolean multiple_value) > { > int l = strlen(s); > int i; > @@ -184,12 +184,15 @@ static char *utf16be_str(long code) > } > > > -/* this function set proper values to *gp based on s; in case it returns > +/* this function writes /ToUnicode data to *gp based on glyph name s and > + * taking into account fntname and encname; in case it returns > * gp->code == UNI_EXTRA_STRING then the caller is responsible for freeing > * gp->unicode_seq too */ > -static void set_glyph_unicode(char *s, glyph_unicode_entry * gp) > +static void set_glyph_unicode(const char *s, const char* fntname, > + const char* encname, glyph_unicode_entry *gp) > { > char buf[SMALL_BUF_SIZE], buf2[SMALL_BUF_SIZE], *p; > + const char *p2; /* p2 points in s; p above points in writable copies */ > long code; > boolean last_component; > glyph_unicode_entry tmp, *ptmp; > @@ -223,7 +226,7 @@ static void set_glyph_unicode(char *s, g > for (;;) { > *p = 0; > tmp.code = UNI_UNDEF; > - set_glyph_unicode(s, &tmp); > + set_glyph_unicode(s, fntname, encname, &tmp); > switch (tmp.code) { > case UNI_UNDEF: /* not found, do nothing */ > break; > @@ -256,8 +259,32 @@ static void set_glyph_unicode(char *s, g > return; > } > > - /* lookup for glyph name in the database */ > - tmp.name = s; > + /* Glyph name search strategy: first look up the glyph name in the > + font's namespace, failing that look it up in the PS encoding > + namespace, and finally look it up in the main database. */ > + /* Note: buf may alias s in the code below, but s and buf2 are > + guaranteed to be distinct because the code changing buf2 above > + always returns before reaching the code below. */ > + snprintf(buf2, SMALL_BUF_SIZE, "fnt:%s/%s", fntname, s); > + tmp.name = buf2; > + tmp.code = UNI_UNDEF; > + ptmp = (glyph_unicode_entry *) avl_find(glyph_unicode_tree, &tmp); > + if (ptmp != NULL) { > + gp->code = ptmp->code; > + gp->unicode_seq = ptmp->unicode_seq; > + return; > + } > + snprintf(buf2, SMALL_BUF_SIZE, "enc:%s/%s", encname, s); > + tmp.name = buf2; > + tmp.code = UNI_UNDEF; > + ptmp = (glyph_unicode_entry *) avl_find(glyph_unicode_tree, &tmp); > + if (ptmp != NULL) { > + gp->code = ptmp->code; > + gp->unicode_seq = ptmp->unicode_seq; > + return; > + } > + tmp.name = (char *)s; /* this is okay since we're not calling > + destroy_glyph_unicode_entry on this */ > tmp.code = UNI_UNDEF; > ptmp = (glyph_unicode_entry *) avl_find(glyph_unicode_tree, &tmp); > if (ptmp != NULL) { > @@ -268,14 +295,14 @@ static void set_glyph_unicode(char *s, g > > /* check for case of "uniXXXX" (multiple 4-hex-digit values allowed) */ > if (str_prefix(s, "uni")) { > - p = s + strlen("uni"); > - code = check_unicode_value(p, true); > + p2 = s + strlen("uni"); > + code = check_unicode_value(p2, true); > if (code != UNI_UNDEF) { > - if (strlen(p) == 4) /* single value */ > + if (strlen(p2) == 4) /* single value */ > gp->code = code; > else { /* multiple value */ > gp->code = UNI_EXTRA_STRING; > - gp->unicode_seq = xstrdup(p); > + gp->unicode_seq = xstrdup(p2); > } > } > return; /* since the last case cannot happen */ > @@ -283,8 +310,8 @@ static void set_glyph_unicode(char *s, g > > /* check for case of "uXXXX" (single value up to 6 hex digits) */ > if (str_prefix(s, "u")) { > - p = s + strlen("u"); > - code = check_unicode_value(p, false); > + p2 = s + strlen("u"); > + code = check_unicode_value(p2, false); > if (code != UNI_UNDEF) { > assert(code >= 0); > gp->code = code; > @@ -292,7 +319,9 @@ static void set_glyph_unicode(char *s, g > } > } > > -integer write_tounicode(char **glyph_names, char *name) > +/* tex font name is bare (no .tfm), but enc name is ending in .enc; */ > +integer write_tounicode(char **glyph_names, const char *texname, > + const char* encname) > { > char buf[SMALL_BUF_SIZE], *p; > static char builtin_suffix[] = "-builtin"; > @@ -301,18 +330,24 @@ integer write_tounicode(char **glyph_nam > integer objnum; > int i, j; > int bfchar_count, bfrange_count, subrange_count; > - assert(strlen(name) + strlen(builtin_suffix) < SMALL_BUF_SIZE); > + > if (glyph_unicode_tree == NULL) { > pdftex_warn("no GlyphToUnicode entry has been inserted yet!"); > fixedgentounicode = 0; > return 0; > } > - strcpy(buf, name); > - if ((p = strrchr(buf, '.')) != NULL && strcmp(p, ".enc") == 0) > - *p = 0; /* strip ".enc" from encoding name */ > - else > - strcat(buf, builtin_suffix); /* ".enc" not present, this is a builtin > - encoding so the name is eg "cmr10-builtin" */ > + if (encname) { > + assert(strlen(encname) < SMALL_BUF_SIZE); > + strcpy(buf, encname); > + if ((p = strrchr(buf, '.')) != NULL && strcmp(p, ".enc") == 0) > + *p = 0; /* strip ".enc" from encoding name */ > + else /* some silly encoding file name not ending in enc; use as-is */ > + pdftex_warn("Dubious encoding file name: `%s'", encname); > + } else { /* this is a builtin encoding, so name is e.g. "cmr10-builtin" */ > + assert(strlen(texname) + strlen(builtin_suffix) < SMALL_BUF_SIZE); > + strcpy(buf, texname); > + strcat(buf, builtin_suffix); > + } > objnum = pdfnewobjnum(); > pdfbegindict(objnum, 0); > pdfbeginstream(); > @@ -336,10 +371,23 @@ integer write_tounicode(char **glyph_nam > "1 begincodespacerange\n" > "<00> <FF>\n" "endcodespacerange\n", buf, buf, buf, buf, buf); > > + /* Fonts with built-in encoding have a unique encoding name so > + looking up that encoding does not buy us any grouping. Instead, > + we group them by dropping any terminal digits from their name. */ > + if (!encname) { > + strcpy(buf, texname); > + for (p = buf + strlen(buf) - 1; p > buf; --p) { > + if (*p >= '0' && *p <= '9') > + *p = 0; > + else > + break; > + } > + } > + > /* set gtab */ > for (i = 0; i < 256; ++i) { > gtab[i].code = UNI_UNDEF; > - set_glyph_unicode(glyph_names[i], &gtab[i]); > + set_glyph_unicode(glyph_names[i], texname, buf, &gtab[i]); > } > gtab[256].code = UNI_UNDEF; > > diff -up pdftex-1.40.9/src/texk/web2c/pdftexdir/writefont.c.nons pdftex-1.40.9/src/texk/web2c/pdftexdir/writefont.c > --- pdftex-1.40.9/src/texk/web2c/pdftexdir/writefont.c.nons 2008-08-26 17:22:10.000000000 +0300 > +++ pdftex-1.40.9/src/texk/web2c/pdftexdir/writefont.c 2008-08-26 17:42:56.000000000 +0300 > @@ -534,11 +534,11 @@ void write_fontdictionary(fo_entry * fo) > if (fixedgentounicode > 0 && fo->fd != NULL) { > if (fo->fe != NULL) { > fo->tounicode_objnum = > - write_tounicode(fo->fe->glyph_names, fo->fe->name); > + write_tounicode(fo->fe->glyph_names, fo->fm->tfm_name, fo->fe->name); > } else if (is_type1(fo->fm)) { > assert(fo->fd->builtin_glyph_names != NULL); > fo->tounicode_objnum = > - write_tounicode(fo->fd->builtin_glyph_names, fo->fm->tfm_name); > + write_tounicode(fo->fd->builtin_glyph_names, fo->fm->tfm_name, NULL); > } > } > > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex

1 0

[pdftex-Patches][2087] Support for CMap namespaces
by pdftex-patches＠sarovar.org 28 Aug '08

28 Aug '08

Patches item #2087, was opened at 2008-08-28 08:17 Status: Open Priority: 3 Submitted By: Vasile Gaburici (vga) Assigned to: Nobody (None) Summary: Support for CMap namespaces Resolution: None Group: v1.40.0 Category: Fonts Initial Comment: There are a couple of LaTeX packages out there (cmap and mmap) that provide CMaps. They don't work as well as \pdfglyphtounicode, i.e. virtual fonts don't get CMaps at all (the CMap is included in the PDF but not referenced), and otftotfm-installed fonts lack the CMap entries for the ligatures that otftotfm sneaks in empty slots. As you know, \pdfglyphtounicode fixes these problems. On the other hand, these two packages let the user specify a CMap for each LaTeX encoding, so the user ca give different Unicode values to the same PS glyph name in different LaTeX encodings. Of course that works properly only if the fonts invoked by the different LaTeX encodings are different; otherwise only one can win the \pdffontattr. A compelling application of this feature are CMaps that set math code points (usually above BMP) for TeX math fonts; those glyphs have exactly the same names as in text fonts /A etc. Adding namespaces to \pdfglyphtounicode makes those two packages obsolete in their current implementation. Another advantage of namespaces is the ability to (reliably) fix TrueType font CMaps. The troublesome glyphs are usually ligatures that don't have a Unicode entry (Th, ti, tf, ffb, etc.), which otftotfm writes as /indexZZZ in the enc file. Putting those in a per-font namespace avoids any potential clashes. So, I've patched pdftex to provide namespaces using the following syntax extension: the first argument of \pdfglyphtounicode can now take additional forms: \pdfglyphtounicode{fnt:tex-font-name/ps-glyph-name}{...} \pdfglyphtounicode{enc:ps-enc-name/ps-glyph-name}{...} Since fonts for which the built-in encoding is used happen to be exactly those that have multiple design sizes (cmr, stmary etc.), using a separate ps-enc-name for each is not helpful. Instead, the 'enc' namespace for those is obtained by dropping any final digits from the font name, e.g. cmr10 has PS encoding cmr (for CMap purposes only). The search policy is to first search the font namespce, then the encoding, and finally the global namespace, for which the syntax remains unchanged. All these namespace are implemented in the same avl tree; just using the above strings as key names. In theory this makes the search 3 times slower, but that particular phase of pdftex hardly takes any time, so it seemed premature to implement any optimization. Some usage examples: % make the ti ligature searchable in Calibri regular \pdfglyphtounicode{fnt:calibly1--base/index415}{0074 0069} % go crazy with Unicode math; TeX math italic gives above-BMP math A \pdfglyphtounicode{enc:cmmi/A}{D835 DC34} % UTF16BE required Note that search behavior for math letters varies with pdf viewers. Acrobat implements only canonical equivalence, so you need to enter the exact code point, and copy/paste preserves the code points, so you can paste into a LaTeX document if it's using utf8x input encoding. Evince implements compatibility equivalence, so it's easier to find those math As by searching for plain A, but they also copy/paste as plain A. You can use pdftotext however, which uses the same poppler backend, to have the code points are preserved. I'm not really advocating Unicode math letters, but now they're easily supported in pdftex -- no need for manual CMaps anymore. BTW, \pdfglyphtounicode now really needs to be documented in the manual, so people would stop writing (buggy) CMaps by hand. I volunteer to do it if you accept the patch :) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=2087&group_id=106

1 0

Patch to support CMap namespaces
by Vasile Gaburici 27 Aug '08

27 Aug '08

There are a couple of LaTeX packages out there that provide CMaps. They don't work as well as \pdfglyphtounicode, i.e. virtual fonts don't get CMaps at all (the CMap is included in the PDF but not referenced), and otftotfm-installed fonts lack the CMap entries for the ligatures that otftotfm sneaks in empty slots. As you know, \pdfglyphtounicode fixes these problems. On the other hand, these two packages let the user specify a CMap for each LaTeX encoding, so the user ca give different Unicode values to the same PS glyph name in different LaTeX encodings. Of course that works properly only if the fonts invoked by the different LaTeX encodings are different; otherwise only one can win the \pdffontattr. A compelling application of this feature are CMaps that set math code points (usually above BMP) for TeX math fonts; those glyphs have exactly the same names as in text fonts /A etc. Adding namespaces to \pdfglyphtounicode makes those two packages obsolete in their current implementation. Another advantage of namespaces is the ability to (reliably) fix TrueType font CMaps. The troublesome glyphs are usually ligatures that don't have a Unicode entry (Th, ti, tf, ffb, etc.), which otftotfm writes as /indexZZZ in the enc file. Putting those in a per-font namespace avoids any potential clashes. So, I've patched pdftex to provide namespaces using the following syntax extension: the first argument of \pdfglyphtounicode can now take additional forms: \pdfglyphtounicode{fnt:tex-font-name/ps-glyph-name}{...} \pdfglyphtounicode{enc:ps-enc-name/ps-glyph-name}{...} Since fonts for which the built-in encoding is used happen to be exactly those that have multiple design sizes (cmr, stmary etc.), using a separate ps-enc-name for each is not helpful. Instead, the 'enc' namespace for those is obtained by dropping any final digits from the font name, e.g. cmr10 has PS encoding cmr (for CMap purposes only). The search policy is to first search the font namespce, then the encoding, and finally the global namespace, for which the syntax remains unchanged. All these namespace are implemented in the same avl tree; just using the above strings as key names. In theory this makes the search 3 times slower, but that particular phase of pdftex hardly takes any time, so it seemed premature to implement any optimization. Some usage examples: % make the ti ligature searchable in Calibri regular \pdfglyphtounicode{fnt:calibly1--base/index415}{0074 0069} % go crazy with Unicode math; TeX math italic gives above-BMP math A \pdfglyphtounicode{enc:cmmi/A}{D835 DC34} % UTF16BE required Note that search behavior for math letters varies with pdf viewers. Acrobat implements only canonical equivalence, so you need to enter the exact code point, and copy/paste preserves the code points, so you can paste into a LaTeX document if it's using utf8x input encoding. Evince implements compatibility equivalence, so it's easier to find those math As by searching for plain A, but they also copy/paste as plain A. You can use pdftotext however, which uses the same poppler backend, to have the code points are preserved. I'm not really advocating Unicode math letters, but now they're easily supported in pdftex -- no need for manual CMaps anymore. BTW, \pdfglyphtounicode now really needs to be documented in the manual, so people would stop writing (buggy) CMaps by hand. I volunteer to do it if you accept the patch :) I also wrote some CMap handling tools, mostly for verification, I'll send a separate announcement about that.

1 0