- ntg-pdftex - NTG Mailing Lists

1.40-rc3
by Martin Schröder 21 Dec '06

21 Dec '06

http://sarovar.org/download.php/1129/pdftex-1.40.0-rc3.tar.bz2 http://sarovar.org/download.php/1130/pdftex-1.40.0-rc2-rc3.diff.gz We are getting nearer... ----------------------------------------------------- pdfTeX 3.141592-1.40.0-rc3 was released on 2006-12-20 ----------------------------------------------------- - changes from rc2: - map file handling: - in usual cases the behaviour is the same like in previous version. So if a font file is given with '<' or '<<', things should work without problems. - changes in odd cases: - no font file --> no font descriptor - font file given but not included --> will be treated like font file missing + a warning - minimize the distinction between standard fonts and other type1 fonts: the *only* place this makes a difference is that if a font file is missing (and the font is used), a warning will be generated for normal fonts but not for standard fonts

6 5

[ pdftex-Bugs-480 ] pdftex offset incorrect with \magnification. Patch included.
by noreply＠sarovar.org 21 Dec '06

21 Dec '06

Bugs item #480, was opened at 2006-02-12 18:12 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106 Category: None >Group: v1.30.0 Status: Open >Resolution: Wont Fix >Priority: 3 Submitted By: Ian Hutchinson (ihutch) Assigned to: Nobody (None) Summary: pdftex offset incorrect with \magnification. Patch included. Initial Comment: Any plain tex file that uses \magnification gives incorrect text placement in pdf. This bug is present in the latest pdftex version 1.21a. It apparently was caused by the introduction of the new variables \pdfvoffset and \pdfhoffset. This bug was not present in older pdftex, e.g. version 3.14159-1.10b, which was part of tetex-2... A simple illustration of the problem is with the trivial file: \magnification \magstep3 %The following parindent and offset changes are not the cause of errors. %They are merely to illustrate them clearly by writing at top left. %Anything other than \magstep0 gives a placement error with pdftex 1.21a. \parindent 0pt \hoffset -1 truein \voffset -1 truein The top. \end With tex and xdvi, the words "The top." are placed at the immediate top left. With pdftex 1.21a and xpdf (or acroread) they are not. With earlier pdftex 1.10b (e.g.) they are. I had an extensive discussion on comp.text.tex with Heiko Oberdiek, most of which is at http://www.codecomments.com/Tex/message784423.html The gist of it is that backward compatibility with plain tex files is very important. As far as possible, it should be preserved transparently. Authors should not be required to hack their files in order for them to render the same in pdf as in dvi. Moreover there is a simple way to provide this compatibility. A reasonable way to fix the bug is to change pdftex.ini and hence pdftex.fmt. (The corresponding pdfetex files ought also to be fixed.) A proposed patched pdftex.ini file is attached. It consists simply of % Thomas Esser, 1998, 2004. public domain. \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \input pdftexconfig \pdfoutput=1 \fi \fi \input plain \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \catcode`@=11 \def\m@g{% \mag\count@ \hsize6.5truein\vsize8.9truein\dimen\footins8truein %These commands fix the pdf sizes to be in true units. \mag@fix\pdfhorigin \mag@fix\pdfvorigin \mag@fix\pdfpagewidth \mag@fix\pdfpageheight } \def\mag@fix#1{% #1=\expandafter\convert@truept\the#1\relax } \begingroup \catcode`P=12 \catcode`T=12 \lowercase{% \endgroup \def\convert@truept#1PT{% #1truept% }% }% \catcode`@=12 \fi \fi \dump \endinput I don't know who takes responsibility for pdftex.ini. But clearly this ought to be fixed for all distributions. I care most about tetex, because it is what I use. Thanks, Ian Hutchinson ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 20:49 Message: Logged In: YES user_id=710 oh yes, thanks Phil for the correction. In response to Ian Hutchinson: I am the maintainer of neither pdftex.ini nor pdftex, so I feel that someone else must make the decision. ---------------------------------------------------------------------- Comment By: Philip TAYLOR (chaa006) Date: 2006-10-23 20:21 Message: Logged In: YES user_id=3040 Thanh wrote : I propose that if someone changes magnification then he/she is suppposed to say \pdfhorigin=1in \pdfvorigin=1in Surely they should write \pdfhorigin = 1 true in \pdfvorigin = 1 true in should they not ? I always do, and it certainly has the intended effect. ** Phil. ---------------------------------------------------------------------- Comment By: Ian Hutchinson (ihutch) Date: 2006-10-23 19:49 Message: Logged In: YES user_id=3410 In response to hanthethanh, let me explain once again that the point is that TeX ought always to work the same with both dvi output and pdf output. The latest pdftex breaks that for all documents, old or new, that use \magnification. Of course there are many ways the authors can fix those documents by adding new commands. BUT THEY SHOULD NOT HAVE TO. TeX's archival integrity is far too valuable for us to accept it being broken by this incompatibility. I've shown how it can be transparently fixed. The correction just needs to be incorporated into the distributions ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 12:37 Message: Logged In: YES user_id=710 I propose that if someone changes magnification then he/she is suppposed to say \pdfhorigin=1in \pdfvorigin=1in or something similar. An undocumented trick is that if \pdfhorigin or \pdfvorigin is not set (or set to 0) when the first page is shipped out, then they will get 1in as the default value. To get zero origin(s), use 1sp instead of 0. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106

1 0

[ pdftex-Bugs-712 ] problems with \letterspacefont
by noreply＠sarovar.org 21 Dec '06

21 Dec '06

Bugs item #712, was opened at 2006-12-12 03:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=712&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: problems with \letterspacefont Initial Comment: % Testing the new \letterspacefont, I found: % % (1) it's certainly not correct to have the spacing % relative to character widths (look at `minimal'!) % (2) everything's shifted to the right % (3) when trying to expand the letter-spaced font, I % get the warning `font should be expanded before % its first use' (even before its first use), and % then pdftex segfaults. \pdfadjustspacing2 \hsize13cm This is normal text This is normal text This is normal text This is normal text This is normal text This is normal text {\letterspacefont\lspfont=\font 1000 %\pdffontexpand\lspfont 20 20 5 autoexpand % segfault \lspfont This isn't normal text This isn't normal text This isn't normal text This is minimal text} This is normal text This is normal text This is normal text \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:09 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-12 18:47 Message: Logged In: YES user_id=710 oops, I disabled ligature for letter-spaced font, but this should not affect the base font. Will have to rethink. Most likely the syntax will change like follows: \letterspacefont\f=cmr10 at 11pt 100 \f text ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-12-12 16:50 Message: Logged In: YES user_id=2217 % and here's % (4) ligatures will be broken up, not only in the % letter-spaced font (which is probably acceptable), % but in all subsequent uses of the base font, too fi\par {\letterspacefont\lspfont=\font 100 \lspfont fi}\par fi \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-12 14:31 Message: Logged In: YES user_id=710 I fixed (1) and (2); (3) is disabled now, ie you cannot expand a letter-spaced font. Please wait for another release from Martin. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=712&group_id=106

1 0

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

21 Dec '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: Closed >Resolution: Fixed 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 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:08 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- 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 21 Dec '06

21 Dec '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: Closed >Resolution: Fixed 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 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:08 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- 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 21 Dec '06

21 Dec '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: Closed >Resolution: Fixed 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 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:08 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- 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 21 Dec '06

21 Dec '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: Closed >Resolution: Fixed 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 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:06 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-11-19 11:10 Message: Logged In: YES user_id=710 This bug is caused by missing of declaration of k inside the function get_auto_kern, hence the global variable k is taken with wrong type (eight_bits). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-11-17 16:12 Message: Logged In: YES user_id=2217 In fact, the kerning amount wraps at a kerning code of 256: \tracingoutput1 \showboxbreadth\maxdimen \pdfappendkern1 \knaccode\font`y=255 y % 2.55pt \knaccode\font`y=257 y % 0.01pt \knaccode\font`y=513 y % 0.01pt \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=692&group_id=106

1 0

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

20 Dec '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: Closed Resolution: Fixed 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 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-20 16:26 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=696&group_id=106

1 0

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

20 Dec '06

Bugs item #304, was opened at 2005-03-02 18: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: Closed Resolution: Fixed 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: Martin Schröder (oneiros) Date: 2006-12-20 16:26 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-11-15 02: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 12: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 19: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 21: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 12: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-16 00: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 17: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 22: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-Patches-709 ] merging patch 597 by Hartmut
by noreply＠sarovar.org 20 Dec '06

20 Dec '06

Patches item #709, was opened at 2006-12-04 09:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106 Category: Fonts Group: v1.40.0 Status: Closed >Resolution: Accepted Priority: 6 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: merging patch 597 by Hartmut Initial Comment: This is a patch against pdftex-1.40.0-beta-20061018 that merges patch 597 by Hartmut and does some clean up in the font mechanism. Testing welcome very much. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-06 18:05 Message: Logged In: YES user_id=710 patch updated to fix a bug with pdf inclusion. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-05 23:52 Message: Logged In: YES user_id=710 patch updated; tested with pdftex manual, microtype manual and base latex doc. A fix for bug #693 is included. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 14:38 Message: Logged In: YES user_id=710 ah, sorry, my mistake. It's against pdftex-1.40.0-beta-20061108 (the latest beta), not pdftex-1.40.0-beta-20061018 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 14:25 Message: Logged In: YES user_id=710 are you saying that you have troubles applying the patch against pdftex-1.40.0-beta-20061017? Can you please try to apply against pdftex-1.40.0-beta-20061018? I have checked everything again from the beginning as follows: - download and unpack http://sarovar.org/download.php/1100/pdftex-1.40.0-beta-20061017.tar.bz2 - download, ungzip and apply http://sarovar.org/download.php/1108/pdftex-1.40.0-beta-20061017-20061108.d… - download http://sarovar.org/tracker/download.php/106/495/709/237/pdftex-20061204-2.p… - cd /path/to/pdftex-1.40.0-beta-20061017/src - patch -p1 --dry-run /path/to/pdftex-20061204-2.patch The patch applied ok, apart from change-files.txt (I removed it from pdftexdir, as it's no longer relevant to pdftex). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-04 13:33 Message: Logged In: YES user_id=421 I'm having troubles applying pdftex-20061204-2.patch against pdftex-1.40.0-beta-20061017, especially pdftex.web. Can you attach a diff against 1.40.0-beta-20061108 or your patched pdftex.web? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 12:02 Message: Logged In: YES user_id=710 I updated the patch to revert auto kerns to be explicit. This will disable hyphenation if auto kern is used. On the other hand this is much more robust. The pending problems are: bug #693: still trying bug #484: will not be fixed, better treat it as a limitation bug #465: unlikely to be fixed ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106

1 0