- ntg-pdftex - NTG Mailing Lists

[ pdftex-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 23 Jun '07

23 Jun '07

Patches item #812, was opened at 2007-06-23 19:23 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 >Category: Primitives >Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) >Assigned to: Hartmut Henkel (hhenkel) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-23 19:29 Message: Logged In: NO This is completely clunky and awkward. Instead of having some magic variable which changes the meaning of _all_ addresses here, how about just using \prevdepth's default for "no change", namely -1000pt? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ 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 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106 Category: Primitives >Group: v1.50.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) 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-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 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106 >Category: Primitives >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) >Assigned to: Martin Schröder (oneiros) 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-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 23 Jun '07

23 Jun '07

Patches item #812, was opened at 2007-06-23 22:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-23 22:59 Message: Logged In: NO This is completely clunky and awkward. Instead of having some magic variable which changes the meaning of _all_ addresses here, how about just using \prevdepth's default for "no change", namely -1000pt? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ pdftex-Patches-813 ] new primitive \pdfinclusioncopyfonts
by noreply＠sarovar.org 23 Jun '07

23 Jun '07

Patches item #813, was opened at 2007-06-23 17:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=813&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: new primitive \pdfinclusioncopyfonts Initial Comment: this is a replacement for \pdfreplacefont, with the opposite semantics. When this is set, fonts from included pdfs are always copied. This is useful to prevent pdftex from replacing fonts in included pdfs, without messing around with map files. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=813&group_id=106

1 0

[ pdftex-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 23 Jun '07

23 Jun '07

Patches item #812, was opened at 2007-06-23 17:23 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ 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

[ 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

[ 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 10:03 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=806&group_id=106 Category: None Group: None Status: Open Resolution: None 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--> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=806&group_id=106

1 0

different rendering of pdftex-generated document in AR4 and AR7
by Vladimir Volovich 01 Jun '07

01 Jun '07

Hi! i'm reporting a problem (found not by me). consider this document: ===================================== \documentclass{article} \usepackage{color} \begin{document} \makebox[2cm][r]{c}\hspace{-2cm}ab \makebox[2cm][r]{c}\hspace{-2cm}a\textcolor{red}{b} \end{document} ===================================== when processed with pdflatex, the generated PDF file is rendered differently by Acrobat Reader 4 and 7 - see the attached files acro4.png and acro7.png. Acrobat 4's rendering seems to be buggy, but i wonder whether it is a real bug in Acrobat 4 or it is caused by a buggy PDF generated by pdftex? Best, v.

2 1

Re: [NTG-pdftex] different rendering of pdftex-generated document in AR4 and AR7
by Thanh Han The 01 Jun '07

01 Jun '07

Hi Vladimir, this was discussed here: http://www.ntg.nl/pipermail/ntg-pdftex/2007-February/002756.html this is indeed a bug of Acrobat Reader from the very beginning and remained there at least until versionn 4.05. Older pdftex had a workaround for this bug, which was removed in later versions as well (since 1.40 IIRC). If you run your test file with an old pdftex, for example 0.14h, the pdf displays correctly with AR4 as well. HTH, Thanh On Thu, May 31, 2007 at 07:16:59PM -0700, Vladimir Volovich wrote: > Hi! > > i'm reporting a problem (found not by me). consider this document: > > ===================================== > \documentclass{article} > \usepackage{color} > \begin{document} > > \makebox[2cm][r]{c}\hspace{-2cm}ab > > \makebox[2cm][r]{c}\hspace{-2cm}a\textcolor{red}{b} > > \end{document} > ===================================== > > when processed with pdflatex, the generated PDF file is rendered > differently by Acrobat Reader 4 and 7 - see the attached files > acro4.png and acro7.png. > > Acrobat 4's rendering seems to be buggy, but i wonder whether it is a > real bug in Acrobat 4 or it is caused by a buggy PDF generated by pdftex? > > Best, > v. > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex

1 0

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

30 May '07

Bugs item #799, was opened at 2007-05-27 15:37 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: Open 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: Nobody (None) Date: 2007-05-30 20:15 Message: Logged In: NO test files work too. Luigi Scarso ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-05-30 19:57 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-30 02:56 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-29 02:26 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-28 02:36 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-28 02:19 Message: Logged In: YES user_id=929 sorry, that was wrong. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-28 02:01 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 18:26 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-799 ] \pdfstartlink duplicate objects when copying boxes
by noreply＠sarovar.org 30 May '07

30 May '07

Bugs item #799, was opened at 2007-05-27 15:37 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: Open 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: Nobody (None) Date: 2007-05-30 19:57 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-30 02:56 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-29 02:26 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-28 02:36 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-28 02:19 Message: Logged In: YES user_id=929 sorry, that was wrong. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-28 02:01 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 18:26 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