June 2007 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Patches-811 ] Patch to change warning mesage for conflicting font attributes (given by \pdffontattr)
by noreply＠sarovar.org 23 Jun '07

23 Jun '07

Patches item #811, was opened at 2007-06-23 17:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to change warning mesage for conflicting font attributes (given by \pdffontattr) Initial Comment: This is a tiny patch to change the warning message for conflicting font attributes (as given by \pdffontattr), to make it clearer what is going on. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106

1 0

[ pdftex-Bugs-762 ] symbolic font gets /Flags as nonsymbolic
by noreply＠sarovar.org 23 Jun '07

23 Jun '07

Bugs item #762, was opened at 2007-04-04 19:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106 Category: Fonts Group: v1.40.0 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: symbolic font gets /Flags as nonsymbolic Initial Comment: The input file \pdfcompresslevel=0 \pdfmapline{psyr Symbol} \nopagenumbers \font\sy=psyr \sy a \end results in a pdf with a Font Descriptor with /Flags 34 for the Symbol font, which is wrong; it should be 4. The flags are initialized as 4 in mapfile.c and writefont.c sees this as the default value and writes 34 to the pdf. Reported by TeX Guy <pdftexlist(a)gmail.com> and analyzed by George N. White III <gnwiii(a)gmail.com>; see the thread starting at http://tug.org/pipermail/pdftex/2007-April/007133.html ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-06-23 02:11 Message: Logged In: YES user_id=421 Patch is attached. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-22 22:41 Message: Logged In: YES user_id=710 Martin, can you please upload the fix here so other can test it too? thanks. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-25 19:47 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-04-04 19:42 Message: Logged In: YES user_id=421 The default might be reasonable, but even setting the fontflags as 4 (symbol) doesn't work, as this is interpreted as being the default and changed to 34. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106

1 0

[ pdftex-Bugs-762 ] symbolic font gets /Flags as nonsymbolic
by noreply＠sarovar.org 22 Jun '07

22 Jun '07

Bugs item #762, was opened at 2007-04-04 17:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106 Category: Fonts Group: v1.40.0 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: symbolic font gets /Flags as nonsymbolic Initial Comment: The input file \pdfcompresslevel=0 \pdfmapline{psyr Symbol} \nopagenumbers \font\sy=psyr \sy a \end results in a pdf with a Font Descriptor with /Flags 34 for the Symbol font, which is wrong; it should be 4. The flags are initialized as 4 in mapfile.c and writefont.c sees this as the default value and writes 34 to the pdf. Reported by TeX Guy <pdftexlist(a)gmail.com> and analyzed by George N. White III <gnwiii(a)gmail.com>; see the thread starting at http://tug.org/pipermail/pdftex/2007-April/007133.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-22 20:41 Message: Logged In: YES user_id=710 Martin, can you please upload the fix here so other can test it too? thanks. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-25 17:47 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-04-04 17:42 Message: Logged In: YES user_id=421 The default might be reasonable, but even setting the fontflags as 4 (symbol) doesn't work, as this is interpreted as being the default and changed to 34. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106

1 0

[ pdftex-Bugs-774 ] UniqueID in subsetted Type1 fonts
by noreply＠sarovar.org 22 Jun '07

22 Jun '07

Bugs item #774, was opened at 2007-04-15 21:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=774&group_id=106 Category: Fonts Group: v1.40.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Hartmut Henkel (hhenkel) Summary: UniqueID in subsetted Type1 fonts Initial Comment: The currant version of pdftex removes the UniqueID from the font dictionary when a subset of a Type1 font is included. However, there is still a UniqueID in the Private dictionary which should be removed too. >From the PostScript Language Reference Manual (p. 336): > When you copy a font dictionary for the purpose of > creating a modified font, you should not copy the > UniqueID or XUID entry. As an exception to this > general rule, it is acceptable (and preferable) to > retain the original UniqueID or XUID entry if > the only modified entries are FontName, FontInfo, > FontMatrix, or Encoding, because those changes do not > affect the glyphs’ appearance or metrics. Regards, Reinhard ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-22 19:53 Message: Logged In: YES user_id=710 sorry, my fault, I didn't see that Hartmut has already uploaded a fix for this bug. Both patches are identical, though. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-22 16:55 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-22 15:21 Message: Logged In: YES user_id=710 here is a patch for this bug ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=774&group_id=106

1 0

[ pdftex-Bugs-799 ] \pdfstartlink duplicate objects when copying boxes
by noreply＠sarovar.org 22 Jun '07

22 Jun '07

Bugs item #799, was opened at 2007-05-27 12:07 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=799&group_id=106 Category: Annotations Group: v1.40.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: \pdfstartlink duplicate objects when copying boxes Initial Comment: When \pdfstartlink is used inside a \hbox, repeated \copy of that box produces the same /Link annotation object multiply, with same object number and identical coordinates on the page. That's wrong, and it gives also problems with object streams, as reported by Luigi Scarso. The tiny patch tries to solve this. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-22 18:56 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-05-30 16:45 Message: Logged In: NO test files work too. Luigi Scarso ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-05-30 16:27 Message: Logged In: NO It works ; Acrobat Reader 7.0.8 now read my test without errors ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-29 23:26 Message: Logged In: YES user_id=929 Now for each \pdfstartlink and \pdfannot node in the case of multiple \copy a new object is generated. This gives each of multiple annotation copies a new correctly placed rectangle on the page. New is that now in the case of duplicate \pdfrefobj only the 1st one will be written, copies are silently ignored. New patch for testing/discussion. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-28 22:56 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-27 23:06 Message: Logged In: YES user_id=929 same simple patch on pdftex.web. The suspicion of an "obscure possible bug" was wrong. Sorry for the noise. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-27 22:49 Message: Logged In: YES user_id=929 sorry, that was wrong. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-27 22:31 Message: Logged In: YES user_id=929 much simpler patch, only on pdftex.web, no need for yet another AVL tree. And maybe some obscure possible bug with object streams caught. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-27 14:56 Message: Logged In: YES user_id=929 patch extended to general \pdfannot. Without the patch acroread 7.0.9 (linux) refuses to display test4.pdf. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=799&group_id=106

1 0

[ pdftex-Bugs-774 ] UniqueID in subsetted Type1 fonts
by noreply＠sarovar.org 22 Jun '07

22 Jun '07

Bugs item #774, was opened at 2007-04-15 23:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=774&group_id=106 Category: Fonts Group: v1.40.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Hartmut Henkel (hhenkel) Summary: UniqueID in subsetted Type1 fonts Initial Comment: The currant version of pdftex removes the UniqueID from the font dictionary when a subset of a Type1 font is included. However, there is still a UniqueID in the Private dictionary which should be removed too. >From the PostScript Language Reference Manual (p. 336): > When you copy a font dictionary for the purpose of > creating a modified font, you should not copy the > UniqueID or XUID entry. As an exception to this > general rule, it is acceptable (and preferable) to > retain the original UniqueID or XUID entry if > the only modified entries are FontName, FontInfo, > FontMatrix, or Encoding, because those changes do not > affect the glyphs’ appearance or metrics. Regards, Reinhard ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-22 18:55 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-22 17:21 Message: Logged In: YES user_id=710 here is a patch for this bug ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=774&group_id=106

1 0

[ pdftex-Bugs-774 ] UniqueID in subsetted Type1 fonts
by noreply＠sarovar.org 22 Jun '07

22 Jun '07

Bugs item #774, was opened at 2007-04-15 21:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=774&group_id=106 Category: Fonts Group: v1.40.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Hartmut Henkel (hhenkel) Summary: UniqueID in subsetted Type1 fonts Initial Comment: The currant version of pdftex removes the UniqueID from the font dictionary when a subset of a Type1 font is included. However, there is still a UniqueID in the Private dictionary which should be removed too. >From the PostScript Language Reference Manual (p. 336): > When you copy a font dictionary for the purpose of > creating a modified font, you should not copy the > UniqueID or XUID entry. As an exception to this > general rule, it is acceptable (and preferable) to > retain the original UniqueID or XUID entry if > the only modified entries are FontName, FontInfo, > FontMatrix, or Encoding, because those changes do not > affect the glyphs’ appearance or metrics. Regards, Reinhard ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-22 15:21 Message: Logged In: YES user_id=710 here is a patch for this bug ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=774&group_id=106

1 0

[ pdftex-Bugs-810 ] Mixed up font descriptor from pdf inclusion
by noreply＠sarovar.org 22 Jun '07

22 Jun '07

Bugs item #810, was opened at 2007-06-22 13:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=810&group_id=106 Category: Fonts Group: v1.40.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: Mixed up font descriptor from pdf inclusion Initial Comment: Ulrich Dirr reported a bug with pdf inclusion where font information is not copied correctly (see http://tug.org/pipermail/pdftex/2007-June/007197.html) Thanh analysed thus: the issue with "Strange problems with graphics inclusion" has the following reason : - CMSS10 is used in a pdf figure (let's call it f1.pdf) - that f1.pdf is included in another pdf (eg f2.pdf) - when f2.pdf includes f1.pdf and a map entry for CMSS10 is avail., a font descriptor for CMSS10 is created by epdf_create_fontdescriptor() - the preset_fontmetrics() function is not called for CMSS10 (it's there in epdf_create_fontdescriptor(), but commented out -- no f to use with preset_fontmetrics() there) - when pdftex writes out the font descriptor for CMSS10, some font metrics are not set, since CMSS10.pfb doesn't have them - so f2.pdf ends up with a font descriptor for CMSS10 where some font metrics are missing (Ascent, CapHeight, XHeight etc.) - f2.pdf seems to be ok with most pdf browser, but not with Preflight in Acrobat7 (and perhaps with PitStop -- I don't have PitStop to test) A patch by Thanh is attached. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=810&group_id=106

1 0

[ pdftex-Bugs-809 ] Incorrect FontFlags for Symbol font (34 instead of 4)
by noreply＠sarovar.org 20 Jun '07

20 Jun '07

Bugs item #809, was opened at 2007-06-20 11:51 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=809&group_id=106 >Category: Fonts >Group: v1.40.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Till Tantau (tantau) >Assigned to: Martin Schröder (oneiros) Summary: Incorrect FontFlags for Symbol font (34 instead of 4) Initial Comment: Hi! with version 1.40.3 of pdftex I have the following problem: When the standard PDF-Font "Symbol" is used in the pdf-file, then the /Flags entry of the FontDescriptor is set to 34 rather than to 4. This is incorrect and causes the resulting files to be displayed incorrectly by the Acrobat Reader. To reproduce the problem, I use the following LaTeX-code: \documentclass{article} \pdfcompresslevel0 \font\myfont=psyr\relax \begin{document} \pagestyle{empty} \myfont SG \end{document} My pdftex.map is standard and contains the following line: psyr Symbol According to the pdftex manual, this should cause the /Flags entry of the font in the PDF-file to be set to 4 (which would be correct and which would be the Flags value of a Symbol font). However, on my system the resulting pdf file (which I attach) contains a /Flags entry of 34 (which is incorrect here and which is the Flags value of a serif standard font). I hope this report is reasonably clear... Any help on this would be greatly appreciated, Till Tantau ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-06-20 15:14 Message: Logged In: YES user_id=421 Till, your bug report is a duplicate of #762 (see also #794); both will be fixed in the next interim release. ---------------------------------------------------------------------- Comment By: Till Tantau (tantau) Date: 2007-06-20 14:24 Message: Logged In: YES user_id=4566 Hi yet again, I now had a look at the code, namely at teh function write_fontdescriptor in writefont.c. Now, in that file it says if (!fd->ff_found && fd->fm->fd_flags == 4) pdf_puts("/Flags 34\n"); /* assumes a roman sans serif font */ else pdf_printf("/Flags %i\n", (int) fd->fm->fd_flags); which obviously causes the problems. Now, it is not quite clear to me how to solve this. In older versions of pdftex (1.30) the built-in fonts did not their own FontDescription object, so this problem did not arise. However, in pdftex 1.40 they do for some reason (it says in create_fontdictionary: /* builtin fonts still need the /Widths array and /FontDescriptor * (to avoid error 'font FOO contains bad /BBox') */ I could not track this "contains bad /BBox" problem. According to the PDF- Specification, a builtin font does not need a FontDescriptor. Be that as it may, I think the the Flags entries of the buildin fonts should be correct (actually, they have to be correct, Acrobat does not render them otherwise). This means, at the very least, that write_fontdescriptor should treat Symbol and ZapfDingbats specially (namely setting the Flags to 4). However, the Flags should also be set correctly for, say, Helvetica, which is not a serif font and for Courier, which is monospaced and so on. Best regards, Till ---------------------------------------------------------------------- Comment By: Till Tantau (tantau) Date: 2007-06-20 12:00 Message: Logged In: YES user_id=4566 Hello again, I toyed around with this some more. It turns out that if I change the line in the pdftex.map file to psyr Symbol 6 then the /Flags field in the resulting .pdf file is set to 6 (which is "not quite correct", but then the text is rendered correctly, at least). Now, trying other values than 6, it seems that pdftex specifically replaces exactly the number 4 by 34, all other values are left as they are. I presume this was done at some time for some other font that is not a symbol font and whose font flags were missing/incorrect. However, this behaviour is a bit problematic for the Symbol font. Best regards, Till ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=809&group_id=106

1 0

[ pdftex-Bugs-809 ] Incorrect FontFlags for Symbol font (34 instead of 4)
by noreply＠sarovar.org 20 Jun '07

20 Jun '07

Bugs item #809, was opened at 2007-06-20 09:51 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=809&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Till Tantau (tantau) Assigned to: Nobody (None) Summary: Incorrect FontFlags for Symbol font (34 instead of 4) Initial Comment: Hi! with version 1.40.3 of pdftex I have the following problem: When the standard PDF-Font "Symbol" is used in the pdf-file, then the /Flags entry of the FontDescriptor is set to 34 rather than to 4. This is incorrect and causes the resulting files to be displayed incorrectly by the Acrobat Reader. To reproduce the problem, I use the following LaTeX-code: \documentclass{article} \pdfcompresslevel0 \font\myfont=psyr\relax \begin{document} \pagestyle{empty} \myfont SG \end{document} My pdftex.map is standard and contains the following line: psyr Symbol According to the pdftex manual, this should cause the /Flags entry of the font in the PDF-file to be set to 4 (which would be correct and which would be the Flags value of a Symbol font). However, on my system the resulting pdf file (which I attach) contains a /Flags entry of 34 (which is incorrect here and which is the Flags value of a serif standard font). I hope this report is reasonably clear... Any help on this would be greatly appreciated, Till Tantau ---------------------------------------------------------------------- >Comment By: Till Tantau (tantau) Date: 2007-06-20 12:24 Message: Logged In: YES user_id=4566 Hi yet again, I now had a look at the code, namely at teh function write_fontdescriptor in writefont.c. Now, in that file it says if (!fd->ff_found && fd->fm->fd_flags == 4) pdf_puts("/Flags 34\n"); /* assumes a roman sans serif font */ else pdf_printf("/Flags %i\n", (int) fd->fm->fd_flags); which obviously causes the problems. Now, it is not quite clear to me how to solve this. In older versions of pdftex (1.30) the built-in fonts did not their own FontDescription object, so this problem did not arise. However, in pdftex 1.40 they do for some reason (it says in create_fontdictionary: /* builtin fonts still need the /Widths array and /FontDescriptor * (to avoid error 'font FOO contains bad /BBox') */ I could not track this "contains bad /BBox" problem. According to the PDF- Specification, a builtin font does not need a FontDescriptor. Be that as it may, I think the the Flags entries of the buildin fonts should be correct (actually, they have to be correct, Acrobat does not render them otherwise). This means, at the very least, that write_fontdescriptor should treat Symbol and ZapfDingbats specially (namely setting the Flags to 4). However, the Flags should also be set correctly for, say, Helvetica, which is not a serif font and for Courier, which is monospaced and so on. Best regards, Till ---------------------------------------------------------------------- Comment By: Till Tantau (tantau) Date: 2007-06-20 10:00 Message: Logged In: YES user_id=4566 Hello again, I toyed around with this some more. It turns out that if I change the line in the pdftex.map file to psyr Symbol 6 then the /Flags field in the resulting .pdf file is set to 6 (which is "not quite correct", but then the text is rendered correctly, at least). Now, trying other values than 6, it seems that pdftex specifically replaces exactly the number 4 by 34, all other values are left as they are. I presume this was done at some time for some other font that is not a symbol font and whose font flags were missing/incorrect. However, this behaviour is a bit problematic for the Symbol font. Best regards, Till ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=809&group_id=106

1 0