October 2006 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-565 ] ttf2afm fails to include characters specified with uniXXXX
by noreply＠sarovar.org 23 Oct '06

23 Oct '06

Bugs item #565, was opened at 2006-05-29 16:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106 Category: ttf2afm Group: v1.30.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Mike Spivey (spivey) Assigned to: The Thanh Han (hanthethanh) Summary: ttf2afm fails to include characters specified with uniXXXX Initial Comment: If characters are specified in an encoding vector as uniXXXX (with XXXX a hexadecimal unicode value), then these characters are not included in the AFM output, unlike characters that are specified by name. The same goes for characters specifed by position. A suggested patch is attached. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-23 12:51 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-10-23 11:00 Message: Logged In: YES user_id=710 the patch looks good to me. Martin, call you include this in next release? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 19:46 Message: Logged In: YES user_id=421 Thanh, ttf2afm is your baby. :-) Pleae check. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106

1 0

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

23 Oct '06

Bugs item #480, was opened at 2006-02-12 17:12 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 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 10: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-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 23 Oct '06

23 Oct '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: 5 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: 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-565 ] ttf2afm fails to include characters specified with uniXXXX
by noreply＠sarovar.org 23 Oct '06

23 Oct '06

Bugs item #565, was opened at 2006-05-29 14:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106 Category: ttf2afm Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Mike Spivey (spivey) Assigned to: The Thanh Han (hanthethanh) Summary: ttf2afm fails to include characters specified with uniXXXX Initial Comment: If characters are specified in an encoding vector as uniXXXX (with XXXX a hexadecimal unicode value), then these characters are not included in the AFM output, unlike characters that are specified by name. The same goes for characters specifed by position. A suggested patch is attached. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 09:00 Message: Logged In: YES user_id=710 the patch looks good to me. Martin, call you include this in next release? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 17:46 Message: Logged In: YES user_id=421 Thanh, ttf2afm is your baby. :-) Pleae check. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106

1 0

[ pdftex-Patches-663 ] fix for bugs #481--483
by noreply＠sarovar.org 22 Oct '06

22 Oct '06

Patches item #663, was opened at 2006-10-21 12:29 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106 Category: hz Group: v1.40.0 Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: fix for bugs #481--483 Initial Comment: This is an attempt to fix bug #481--483 - This patch applies to the pristine pdftex-1.40.0-beta-20061017 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - How to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20061017/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-10-22 21:38 Message: Logged In: YES user_id=710 This is an update of the previous patch, which attemps to solve problem #484 as well (I would not call #484 a bug but a limitation -- a bug would mean that the behaviour is inconsistent with the specification). This patch is *very different* from the previous one, since now kerns inserted by the new primitives are treated as implicit kerns (they were treated as explicit kerns before this patch). This can lead to a very different behaviour, so be prepared :) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-21 13:54 Message: Logged In: YES user_id=421 Thanks! Any idea for 484? :-) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106

1 0

vim syntax for web files?
by Thanh Han The 22 Oct '06

22 Oct '06

Hi, does anyone here use vim for editing web (knuthian web) files? Sometimes I got wrong highlighting with tex.web or pdftex.web, but I am not good enough to correct the vim syntax file, so I turn off syntax highlighting for *.web files. The web syntax file coming with vim is made for CWEB files but it is used for web too. If here is some vim guru who can fix that, it would be great. Thanh

1 0

pdftex 1.40 and active characters in French
by Martin Schröder 21 Oct '06

21 Oct '06

---------- Forwarded message ---------- From: Daniel Flipo <daniel.flipo(a)univ-lille1.fr> Date: 21.10.2006 19:31 Subject: pdftex 1.40 and active characters in French To: Martin Schröder <martin(a)oneiros.de>, Hans Hagen <pragma(a)wxs.nl> Cc: Robert Schlicht <w.m.l(a)gmx.net> Hi Martin and Hans, I have heard about new kerning facilities coming with pdftex 1.40 and started playing with them (through the microtype interface, latest version 1.37 2006-09-09 with \betatrue). I would love to get rid of the four active characters (:;!?) in babel/frenchb. Unfortunately, after discussing with Robert (in copy), it appears that these new kerning facilities do not quite fulfil what would be needed for French. I'd like to make a summary of the required specifications in case you can think of a possible solution for future developments of pdftex. 1) People who type correctly in French, are used to type a (normal) space before ';:!?'. pdftex 1.40 can add a kern before them, but cannot do an '\unskip' to remove the typed space. It is hopeless to try to convince French writers to change their habits and refrain from entering a space before ';:!?' ;-) frenchb currently handles the four (active) punctuation chars ;:!? in two different ways: -- with option \NoAutoSpaceBeforeFDP, frenchb _replaces_ the normal space with an unbreakable one of the correct width, _if and only if_ a space (normal or '~') is present before ';:!?'. If no space is typed, frenchb does nothing and lets the punctuation mark stick to the preceding word. This avoids to get a spurious space in URLs (http://...), Windows paths (C:/path), etc. -- with option \AutoSpaceBeforeFDP (the default), you can type carelessly "bonjour!", "bonjour !" or even "bonjour~!", frenchb will always output it correctly, but then you cannot complain if you get a spurious space in URLs... 2) Another (minor) issue occurs with ':'. Again, there are currently two different options in frenchb: -- Most people agree with our « Imprimerie nationale » that ':' should be surrounded by two spaces of the same length, the first one being unbreakable, the other three (;!?) getting a thin space (kern in TeX) before and a normal one (glue) after. That's what frenchb does by default. -- Some typographers argue that ':' should be treated like the other three, so an option is provided in frenchb to satisfy them. AFAIK pdftex 1.40 can add a kern before a character but not a glue, so the spaces around ':' might look unsymmetrical in the first case if TeX stretches the second one... 3) Guillemets are less problematic because they are currently entered with commands (\og and \og), not as characters. Spaces after the opening '«' and before the closing '»' should be unbreakable but stretchable (currently .8\fontdimen2 plus .3\fontdimen3 minus .8\fontdimen4). Moreover, a kern after '«' breaks hyphenation of the following word as Robert already already pointed out on the pdftex bug list. Feel free to forward this mail to other pdftex developers if it can be useful, I would have wished to send it to Than also but I could not find his current mail address. Best wishes and thanks for your attention, -- Daniel Flipo

1 0

[ pdftex-Bugs-609 ] Pdf "convert" primitives bug
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Bugs item #609, was opened at 2006-09-28 18:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106 Category: Primitives Group: v1.40.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Taco Hoekwater (taco) >Summary: Pdf "convert" primitives bug Initial Comment: The problem: When tex calls `conv_toks()' to execute `convert' commands, a string may already be being built. A call to scan_toks (pdf_scan_ext_toks) at that moment will incorporate that partial string to the argument of the `convert' primitive, and erase it from the output. Example code: \message{\pdfmdfivesum{knuth}} \input knuth\pdfmdfivesum{} \bye Affected primitives: \pdfescapestring \pdfescapename \pdfescapehex \pdfunescapehex \pdffilemoddate \pdffilesize \pdffiledump \pdfmdfivesum \pdfstrcmp The needed fix: Somewhen before calling scan_pdf_ext_toks, you have to store the partial string as a true tex string, then its `partialness' has to be restored sometime later before leaving conv_toks(). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:57 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-10-04 16:43 Message: Logged In: YES user_id=1608 patch against pdftex.web from 20060928 attached. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-09-28 18:52 Message: Logged In: YES user_id=1608 sorry, it is a bug, of course ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106

1 0

[ pdftex-Bugs-609 ] Pdf "convert" primitives bug
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Bugs item #609, was opened at 2006-09-28 18:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106 Category: Primitives Group: v1.40.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Taco Hoekwater (taco) >Summary: Pdf "convert" primitives bug Initial Comment: The problem: When tex calls `conv_toks()' to execute `convert' commands, a string may already be being built. A call to scan_toks (pdf_scan_ext_toks) at that moment will incorporate that partial string to the argument of the `convert' primitive, and erase it from the output. Example code: \message{\pdfmdfivesum{knuth}} \input knuth\pdfmdfivesum{} \bye Affected primitives: \pdfescapestring \pdfescapename \pdfescapehex \pdfunescapehex \pdffilemoddate \pdffilesize \pdffiledump \pdfmdfivesum \pdfstrcmp The needed fix: Somewhen before calling scan_pdf_ext_toks, you have to store the partial string as a true tex string, then its `partialness' has to be restored sometime later before leaving conv_toks(). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:57 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-10-04 16:43 Message: Logged In: YES user_id=1608 patch against pdftex.web from 20060928 attached. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-09-28 18:52 Message: Logged In: YES user_id=1608 sorry, it is a bug, of course ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106

1 0

[ pdftex-Patches-663 ] fix for bugs #481--483
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Patches item #663, was opened at 2006-10-21 14:29 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106 >Category: hz >Group: v1.40.0 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) >Assigned to: Hartmut Henkel (hhenkel) Summary: fix for bugs #481--483 Initial Comment: This is an attempt to fix bug #481--483 - This patch applies to the pristine pdftex-1.40.0-beta-20061017 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - How to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20061017/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:54 Message: Logged In: YES user_id=421 Thanks! Any idea for 484? :-) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106

1 0