- ntg-pdftex - NTG Mailing Lists

[ pdftex-Patches-462 ] HZ font expansion by text matrix manipulation
by noreply＠sarovar.org 13 Feb '06

13 Feb '06

Patches item #462, was opened at 2005-12-23 22:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106 Category: Positioning Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: HZ font expansion by text matrix manipulation Initial Comment: Use textmatrix Tm instead of /FontMatrix for font expansion. Then a font file will be embedded only once for all expansion factors. Gives smaller PDF files. Works then also for non-embedded fonts. TrueType not tried yet. Rough patch only, incomplete, work in progress, no warranty, not for production. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-02-13 18:05 Message: Logged In: YES user_id=2217 Will this make it into 1.40? I would love to see it included. I've tested it a bit and did not find any problems (I'm also using it for the pre-built microtype documentation on CTAN). Regards, Robert ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106

1 0

[ pdftex-Bugs-484 ] extra kerning inhibits hyphenation
by noreply＠sarovar.org 13 Feb '06

13 Feb '06

Bugs item #484, was opened at 2006-02-13 18:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=484&group_id=106 Category: hz Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: extra kerning inhibits hyphenation Initial Comment: Hyphenation will be inhibited by appended or prepended kerns: \showhyphens{pdftex} { \pdfprependkern=1 \knbccode\font`e=100 \showhyphens{pdftex} } { \pdfappendkern=1 \knaccode\font`e=100 \showhyphens{pdftex} } \bye (In a milder mood, I would have filed this as a feature request, not as a bug report. But I do think that it's a major drawback, which renders this new extension useless for a lot of applications.) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=484&group_id=106

1 0

[ pdftex-Bugs-483 ] extra kerning inhibits extra spacing
by noreply＠sarovar.org 13 Feb '06

13 Feb '06

Bugs item #483, was opened at 2006-02-13 18:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=483&group_id=106 Category: hz Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: extra kerning inhibits extra spacing Initial Comment: The new extension don't work together: \pdfadjustinterwordglue=1 \knbscode\font`\e=1000 The test \pdfappendkern=1 \knaccode\font`\e=1 The test \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=483&group_id=106

1 0

[ pdftex-Bugs-482 ] extra kerning does not work with ligatures
by noreply＠sarovar.org 13 Feb '06

13 Feb '06

Bugs item #482, was opened at 2006-02-13 18:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=482&group_id=106 Category: hz Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: extra kerning does not work with ligatures Initial Comment: Appending or prepending kerns with the new primitives does not work with ligatures. It works, though, when the ligatures are accessed via \char: \pdfprependkern=1 \pdfappendkern=1 \def\setkn#1{% \knbccode\font #1 = 200\relax \knaccode\font #1 = 200\relax } \setkn{`a} \setkn{11} % ff \setkn{12} % fi \setkn{`z} afffiz\par a\char11 \char12 z \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=482&group_id=106

1 0

[ pdftex-Bugs-481 ] "This can't happen (flushing)" with extra kerning+expansion+ligatures
by noreply＠sarovar.org 13 Feb '06

13 Feb '06

Bugs item #481, was opened at 2006-02-13 18:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=481&group_id=106 Category: hz Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: "This can't happen (flushing)" with extra kerning+expansion+ligatures Initial Comment: With the following test file, pdftex will abort with "This can't happen (flushing)": \pdfadjustspacing=1 \pdffontexpand\font 20 20 4 autoexpand \pdfappendkern=1 \knaccode\font`i=100 \hsize10em foo fii foo foo foo foo % but this works: %foo f{}ii foo foo foo foo \bye Hartmut's analysis was: ----------------------------------- FWIW, this happens in function do_subst_font(). But it starts with auto_expand_kern(), where the given kern indeed is appended to the i of "fi" and also to the 2nd "i". It seems as if at this time "fi" is not yet seen as a ligature. Then in do_subst_font() the "fi" is somehow already a ligature, and now the kern is part of the lig_ptr list (which is wrong). Then font(r) is recursively changed to 51, the expanded font number, and so the kern, which should not be in this list, gets the 51 as its type. But it must be 11 for a kern. Maybe a change should be that the kern does not end up in the lig_ptr list, but should come after the "fi" ligature. No idea, how. ----------------------------------- ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=481&group_id=106

1 0

[ pdftex-Patches-466 ] \primitive and \ifprimitive
by noreply＠sarovar.org 13 Feb '06

13 Feb '06

Patches item #466, was opened at 2006-01-07 17:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106 Category: Primitives Group: v1.40.0 Status: Open Resolution: Accepted Priority: 4 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \primitive and \ifprimitive Initial Comment: This patch implements two new primitives: \primitive \par This will run the 'primitive' command \par, even if it has been re- or undefined in the meantime. \primitive is not expandable, because it may be asked to execute unexpandable primitives as well as expandable ones. If you supply a nonexistant primitive, it will be ignored (no error is raised). The second primitive is a new type of \if: \ifprimitive \par ... \else .. \fi returns true if the current meaning of \par is the 'primitive' command \par. The patch is against alpha-20051226, i hope that is not too old (?). I expect to do at least one minor update during the beta cycle, after the pdftex code is flattened. It was quite a struggle to make this change file work ok, and as a result, there are a few ugly web hacks. ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2006-02-13 18:56 Message: Logged In: YES user_id=1608 We need to think about this. I see your point, but making \primitive expandable forces the introduction of un-redefinable tokens, and that has its own problematic side-effects (like slowing down each and every definition). I welcome third opinions on whether the benefits outweigh that downside. At one point I tried making the expandability depend on the referred primitive, but that gave me headaches at the implementation stage (a pity, because that would have been nice). Yet another solution is to have an expandable command as well as an unexpandable command (two primitives instead of just the single \primitive). On the side note: I will happily write an implementation ... but only if someone comes up with a specification that works under all conditions instead of only under specific programming styles :-) ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-13 17:40 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106

1 0

[ pdftex-Patches-466 ] \primitive and \ifprimitive
by noreply＠sarovar.org 13 Feb '06

13 Feb '06

Patches item #466, was opened at 2006-01-07 17:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106 Category: Primitives Group: v1.40.0 Status: Open Resolution: Accepted Priority: 4 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \primitive and \ifprimitive Initial Comment: This patch implements two new primitives: \primitive \par This will run the 'primitive' command \par, even if it has been re- or undefined in the meantime. \primitive is not expandable, because it may be asked to execute unexpandable primitives as well as expandable ones. If you supply a nonexistant primitive, it will be ignored (no error is raised). The second primitive is a new type of \if: \ifprimitive \par ... \else .. \fi returns true if the current meaning of \par is the 'primitive' command \par. The patch is against alpha-20051226, i hope that is not too old (?). I expect to do at least one minor update during the beta cycle, after the pdftex code is flattened. It was quite a struggle to make this change file work ok, and as a result, there are a few ugly web hacks. ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-13 17:40 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106

1 0

Bug in pdftex. Fixed by attached pdftex.ini.
by hutch＠psfc.mit.edu 13 Feb '06

13 Feb '06

---------- Forwarded message ---------- Date: Fri, 10 Feb 2006 23:07:36 -0500 (EST) From: hutch(a)psfc.mit.edu To: tetex(a)dbs.uni-hannover.de Subject: Bug in pdftex. Fixed by attached pdftex.ini In tetex-3... pdftex has a serious bug. 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 http://www.psfc.mit.edu/people/hutch/

6 9

[ pdftex-Patches-474 ] Use dynamically linked poppler library instead of xpdf code
by noreply＠sarovar.org 13 Feb '06

13 Feb '06

Patches item #474, was opened at 2006-01-30 17:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Postponed Priority: 5 Submitted By: Frank Küster (frank) Assigned to: Martin Schröder (oneiros) Summary: Use dynamically linked poppler library instead of xpdf code Initial Comment: This has already been applied and tested in Debian and Ubuntu, but we suggest to apply it upstream. There are a few things to do, however, as Martin already pointed out to me in a private mail. I paraphrase the main points: - the pdftex distribution should not ship libpoppler. Instead it should be possible to switch from xpdf to libpoppler using autoconf magic, if libpoppler headers are installed. This needs some coding work - We need a common API for xpdf and poppler. This is the tricky part, because the very reason for poppler's existence is that the xpdf developer, Derek Noonburg, refuses any patches that would lead to a shared library. As Martin said, "for the beginning, a header file with a couple of #ifdef'ed definitions should be enough". I'm going to subscribe to the pdftex devel list soon, but am not yet subscribed currently. ---------------------------------------------------------------------- >Comment By: Frank Küster (frank) Date: 2006-02-13 08:58 Message: Logged In: YES user_id=3360 I agree that this is something to think over and check very well, so better not push it into 1.40. But I'd appreciate if someone could answer my mail to ntg-pdftex regarding the autoconf setup in pdftex, or if you could tell me whom to ask specifically if nobody among the active developers knows about it. See you in Berlin, Frank ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 01:50 Message: Logged In: YES user_id=421 I've attached the patch by Frank from http://www.ntg.nl/pipermail/ntg-pdftex/2006-February/001993.html ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 01:46 Message: Logged In: YES user_id=421 This is too late for 1.40, so I'll postpone it. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106

1 0

[ pdftex-Patches-474 ] Use dynamically linked poppler library instead of xpdf code
by noreply＠sarovar.org 13 Feb '06

13 Feb '06

Patches item #474, was opened at 2006-01-30 17:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106 >Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Postponed Priority: 5 Submitted By: Frank Küster (frank) Assigned to: Martin Schröder (oneiros) Summary: Use dynamically linked poppler library instead of xpdf code Initial Comment: This has already been applied and tested in Debian and Ubuntu, but we suggest to apply it upstream. There are a few things to do, however, as Martin already pointed out to me in a private mail. I paraphrase the main points: - the pdftex distribution should not ship libpoppler. Instead it should be possible to switch from xpdf to libpoppler using autoconf magic, if libpoppler headers are installed. This needs some coding work - We need a common API for xpdf and poppler. This is the tricky part, because the very reason for poppler's existence is that the xpdf developer, Derek Noonburg, refuses any patches that would lead to a shared library. As Martin said, "for the beginning, a header file with a couple of #ifdef'ed definitions should be enough". I'm going to subscribe to the pdftex devel list soon, but am not yet subscribed currently. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-02-13 01:50 Message: Logged In: YES user_id=421 I've attached the patch by Frank from http://www.ntg.nl/pipermail/ntg-pdftex/2006-February/001993.html ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 01:46 Message: Logged In: YES user_id=421 This is too late for 1.40, so I'll postpone it. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106

1 0