November 2006 - ntg-pdftex - NTG Mailing Lists

Re: [NTG-pdftex] [pdftex] SGML output fails with pdflatex
by Hartmut Henkel 15 Nov '06

15 Nov '06

On Mon, 13 Nov 2006, Werner LEMBERG wrote: > > Problem now is that latex and dvipdfmx work, but pdflatex doesn't. > > And the PDF documents in all other languages are made with pdflatex. > > Strange thing as well is that it worked before with CJK v4.5.2. > > Apparently, you've found a fatal bug in pdftex. I was able to reduce > it to the attached document. Using the TeXLive SVN from today (which > contains pdfeTeX 3.141592-1.30.4-2.2), the first run of > > pdflatex zzzz.tex > > works fine, but a second run crashes with > > ! pdfTeX error (arithmetic): divided by zero. > > This is on a GNU/Linux box, BTW. problem appears when font bsmiu59 is called, which happens to be font no. 256 in the 2nd run. Font size for this font is set to 717619. But then in pdf_begin_string() the value pdf_font_size[f] is zero, so the s := divide_scaled(cur_delta_h - pdf_delta_h, pdf_font_size[f], 3); crashes. It has nothing to do with this particular font, but it seems that pdftex can't handle more than 255 fonts, so that some wraparound seems to happen and there is no catch for this condition. Obvious questions are: Does pdftex have this 255 limitation? Can this be extended? Or should pdftex quit with the remark that it can't handle this? Is this really the first time that somebody requests more than 255 fonts? Regards, Hartmut

4 3

[ pdftex-Bugs-696 ] pdftex always autoexpands -- even if it shouldn't
by noreply＠sarovar.org 15 Nov '06

15 Nov '06

Bugs item #696, was opened at 2006-11-15 02:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106 >Category: hz >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) >Assigned to: The Thanh Han (hanthethanh) Summary: pdftex always autoexpands -- even if it shouldn't Initial Comment: pdftex is now a bit too keen on autoexpanding -- it does so, even if `autoexpand' is not specified. Although the pre-created metrics are read, the physical font (pfb resp. pk) is ignored. As has been discussed re: bugs/304, *not* using autoexpansion gives better results for MM (and MF) fonts, since the fonts are not stretched blindly but stroke widths are adjusted etc. I've moved the test file from bugs/304 here. Another example is (with an existing file cmr10+100.mf): \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr =cmr10 \cmr \pdffontexpand\cmr 100 0 100 %autoexpand Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106

1 0

[ pdftex-Bugs-695 ] Confusion when changing kerning settings within a paragraph
by noreply＠sarovar.org 15 Nov '06

15 Nov '06

Bugs item #695, was opened at 2006-11-15 02:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=695&group_id=106 >Category: hz >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) >Assigned to: The Thanh Han (hanthethanh) Summary: Confusion when changing kerning settings within a paragraph Initial Comment: Extra kerning now has this nasty, unreliable kind of paragraph scope, so that whether or not extra kerning will be applied depends on whether tex needs to hyphenate the paragraph, and whether a word contains a discretionary. (Same as for \pdfnoligatures [see discussion in feature req 385], for which this may be an acceptable limitation, since it has global scope, anyway. However, I don't consider it acceptable for the kerning feature. Think of language-dependant settings, for example.) \hsize 7cm \pdfadjustspacing0 \knaccode\font`s=500 \knbccode\font`s=500 \pdfappendkern1 \pdfprependkern1 nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing \pdfappendkern0 \pdfprependkern0 nasty testing nasty testing nasty testing nasty testing nasty testing \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=695&group_id=106

1 0

[ pdftex-Bugs-694 ] Extra kerning doesn't work in lines composed with expanded fonts
by noreply＠sarovar.org 15 Nov '06

15 Nov '06

Bugs item #694, was opened at 2006-11-15 02:14 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=694&group_id=106 >Category: hz >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) >Assigned to: The Thanh Han (hanthethanh) Summary: Extra kerning doesn't work in lines composed with expanded fonts Initial Comment: \pdftracingfonts2 \tracingoutput1 \showboxdepth\maxdimen \showboxbreadth\maxdimen \hsize 4cm \pdfprependkern1 \knbccode\font`:=500 \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand yyy: yyy: yyy: yyy: yyy: yyy: \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=694&group_id=106

1 0

[ pdftex-Bugs-693 ] No extra kerning before a character if it starts a word
by noreply＠sarovar.org 15 Nov '06

15 Nov '06

Bugs item #693, was opened at 2006-11-15 02:14 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=693&group_id=106 >Category: hz >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) >Assigned to: The Thanh Han (hanthethanh) Summary: No extra kerning before a character if it starts a word Initial Comment: \tracingoutput1 \showboxdepth\maxdimen \showboxbreadth\maxdimen \pdfprependkern1 \knbccode\font`x=1000 xyx xyx \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=693&group_id=106

1 0

[ pdftex-Bugs-692 ] Amount of extra kerning is wrong/has changed
by noreply＠sarovar.org 15 Nov '06

15 Nov '06

Bugs item #692, was opened at 2006-11-15 02:14 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=692&group_id=106 >Category: hz >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) >Assigned to: The Thanh Han (hanthethanh) Summary: Amount of extra kerning is wrong/has changed Initial Comment: With \kn[ab]ccode=1000 a kern of 1em should be inserted. (Here, it's 2.32pt:) \tracingoutput1 \showboxdepth\maxdimen \showboxbreadth\maxdimen \pdfappendkern1 \pdfprependkern1 \knaccode\font`y=1000 \knbccode\font`y=1000 xyx \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=692&group_id=106

1 0

Re: [NTG-pdftex] [pdftex] SGML output fails with pdflatex
by Taco Hoekwater 15 Nov '06

15 Nov '06

Frank Küster wrote: > But that looks as if it already patches this? But then why do we > encounter the bug in Debian? "Yes" and "I do not know" Taco

1 0

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 14 Nov '06

14 Nov '06

Bugs item #304, was opened at 2005-03-02 17:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: Accepted Priority: 3 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- >Comment By: Robert (schlcht) Date: 2006-11-15 01:23 Message: Logged In: YES user_id=2217 problem with autoexpanding now at bugs/696 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 10:23 Message: Logged In: YES user_id=710 Here is an attempt to fix this problem (reversed patch attached). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-09-03 17:30 Message: Logged In: YES user_id=2217 I've attached an example using Kepler MM (tfm+pfb included, please delete after testing). MM fonts are probably the only case where one would not want to use the autoexpand feature. At first sight, saying "autoexpand" or not doesn't seem to make a difference, since pdftex will always prefer existing expanded fonts (pfb) over autoexpanding them, anyway. However, there are some slight differences in the pdf. This is probably because the provided tfm file is different from the metrics that pdf calculates itself in the case of autoexpand. That is, autoexpand may result in a mismatch between the provided pfb and the calculated tfm, is that correct? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-01 19:02 Message: Logged In: YES user_id=929 currently i even can't get a test file do expansion at all without "autoexpand". E. g. Robert's example above, without "autoexpand", doesn't use expanded fonts. Maybe that's the reason for the missing expand parameter in the log? Can anybody provide a test file for this case? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 10:47 Message: Logged In: YES user_id=421 Is this really a problem, i.e. is there a reason _not_ to use the autoexpand feature in new documents? Hartmut, did you look into this bug? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2005-10-15 22:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 15:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 20:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\tenrm t ...\tenrm (+20) e Without font expansion, this default should be compatible with TeX's original log output. If \pdftracingfonts is set to 1 (or greater), we get a more verbose log (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

[ pdftex-Bugs-696 ] pdftex always autoexpands -- even if it shouldn't
by noreply＠sarovar.org 14 Nov '06

14 Nov '06

Bugs item #696, was opened at 2006-11-15 01:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: pdftex always autoexpands -- even if it shouldn't Initial Comment: pdftex is now a bit too keen on autoexpanding -- it does so, even if `autoexpand' is not specified. Although the pre-created metrics are read, the physical font (pfb resp. pk) is ignored. As has been discussed re: bugs/304, *not* using autoexpansion gives better results for MM (and MF) fonts, since the fonts are not stretched blindly but stroke widths are adjusted etc. I've moved the test file from bugs/304 here. Another example is (with an existing file cmr10+100.mf): \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr =cmr10 \cmr \pdffontexpand\cmr 100 0 100 %autoexpand Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106

1 0

[ pdftex-Bugs-695 ] Confusion when changing kerning settings within a paragraph
by noreply＠sarovar.org 14 Nov '06

14 Nov '06

Bugs item #695, was opened at 2006-11-15 01:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=695&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: Confusion when changing kerning settings within a paragraph Initial Comment: Extra kerning now has this nasty, unreliable kind of paragraph scope, so that whether or not extra kerning will be applied depends on whether tex needs to hyphenate the paragraph, and whether a word contains a discretionary. (Same as for \pdfnoligatures [see discussion in feature req 385], for which this may be an acceptable limitation, since it has global scope, anyway. However, I don't consider it acceptable for the kerning feature. Think of language-dependant settings, for example.) \hsize 7cm \pdfadjustspacing0 \knaccode\font`s=500 \knbccode\font`s=500 \pdfappendkern1 \pdfprependkern1 nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing nasty testing \pdfappendkern0 \pdfprependkern0 nasty testing nasty testing nasty testing nasty testing nasty testing \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=695&group_id=106

1 0