- ntg-pdftex - NTG Mailing Lists

[ 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

[ 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 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

[ 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 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=809&group_id=106

1 0

possible bug in eTeX related to \savinghyphcodes
by Vladimir Volovich 11 Jun '07

11 Jun '07

Hi! it seems there might me a bug in eTeX related to \savinghyphcodes. consider the following file, init.tex: ======================= \input plain \begingroup \language=1 \patterns{a1} \endgroup \begingroup \language=2 \savinghyphcodes=1 \lccode`\a=`\A \lccode`\A=`\A \patterns{a1} \endgroup \dump ======================= generate a format file with it: pdftex -ini -etex init.tex now, run the following: pdftex \&init test.tex where test.tex is: ======================= %\tracingall \hsize=1sp \language1 \noindent a bbbabbbabbbabbb bbbabbbabbbabbb {\language=2 bbbabbb}. bbbabbbabbbabbb bbbabbbabbbabbb \noindent a bbbabbbabbbabbb bbbabbbabbbabbb {\language=2 bbbabbb} bbbabbbabbbabbb bbbabbbabbbabbb \bye ======================= there are two paragraphs in the text, the only difference is that the first one has a period after a group. in the first paragraph, however, eTeX does not find any hyphenation points after the group, but it does find them in the second paragraph where there is no dot. this behavior looks like a bug. in particular, when i try to use the \savinghyphcodes feature, i get no hyphenation in the rest of a paragraph after temporarily switching to some language for which there was a \savinghyphcodes. i don't know why it is triggered by the presence of a period, - i just noticed that in the absense of a period (or maybe any other non-space character) the bug disappears; but if the group is followed by a non-space character such as a period, the bug is present. Best, v.

1 0

[ pdftex-Bugs-806 ] no file extentions
by noreply＠sarovar.org 09 Jun '07

09 Jun '07

Bugs item #806, was opened at 2007-06-09 16:03 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=806&group_id=106 Category: None >Group: v1.40.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tristan Blach-Laflèche (the_fleche) Assigned to: Nobody (None) Summary: no file extentions Initial Comment: After downloading "pdftex-1.40.3.zip", most of the folder's files did not have any extentions. How is that possible? the_fleche--> ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-06-09 17:30 Message: Logged In: YES user_id=421 Please read the files README and INSTALL. You got the sources of pdftex, no executables. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=806&group_id=106

1 0