July 2006 - ntg-pdftex - NTG Mailing Lists

LuaTeX schedule
by Reinhard Kotucha 28 Jul '06

28 Jul '06

Hi, any idea when LuaTeX will be released? AFAIK it is somewhere near the top on Taco's TODO list. TeXLive-2005 had been frozen end of October. Because Karl spent so much time to move from p4 to svn I don't expect that TL-2006 can be released earlier. Is it likely that we have LuaTeX in TL-2006? Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

3 2

[ pdftex-Bugs-577 ] Type 3 fonts: on screen fine, on paper filled and displaced
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #577, was opened at 2006-06-28 13:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=577&group_id=106 Category: Fonts Group: v1.30.0 >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Peter Dyballa (ballapete) Assigned to: Hartmut Henkel (hhenkel) Summary: Type 3 fonts: on screen fine, on paper filled and displaced Initial Comment: Hello! It's pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5), on Mac OS X 10.4.6, PPC. The Type 3 font is dijkstra, a famous person's handwriting, as distributed by many SunOS and Solaris versions. Until mid May I had no problem with pdfTeX, dijkstra, and my EPSON EPL-5800 (PostScript 3). This week I again wanted to print a personal letter with Prof. Dijkstra's handwriting used for my letter head. And some letters were filled (P,e,9), others were horizontally and/or vertically displaced from their correct positions. Dijkstra was installed with fontinst. Can this be a pdfTeX problem? End of May I added almost 1 GB of files to update SDKs etc. in Mac OS X to be able to produce Universal Binaries. The last few Tiger versions are known as a bit buggy. My last TeX binaries updates happened in the middle of May, but I have no LOG files from this. The recent LOGs from making the format files contain the string above ... Greetings Pete ---------------------------------------------------------------------- Comment By: Peter Dyballa (ballapete) Date: 2006-07-26 15:25 Message: Logged In: YES user_id=2303 *I* am terribly sorry! Examining again my printer drivers upon your findings I now found that the PS3<version number> part of its name was removed! So I had some filter that converted PS or PDF into raster that was sent via ESP/P or such to the printer? I found the right PPD file in the right place and re-installed this as my printer -- and it prints again. (Although it puzzles me why I could print the PDF output from XeTeX! This worked all the last weeks.) Probably *I* was choosing the wrong items in the printer configuration dialog! Sorry for this! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-24 23:46 Message: Logged In: YES user_id=421 [Sorry for not reacting earlier, but gforge sends no mail when a file is attached; you also have to add a comment.] The attached file uses a Type 1 font and prints perfectly on an Lexmark Optra T612 (which has a PS3 RIP)... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-06-28 16:09 Message: Logged In: YES user_id=421 Please provide a pdf showing the problems (attach it to this bug). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=577&group_id=106

1 0

[ pdftex-Bugs-577 ] Type 3 fonts: on screen fine, on paper filled and displaced
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #577, was opened at 2006-06-28 13:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=577&group_id=106 Category: Fonts Group: v1.30.0 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Peter Dyballa (ballapete) Assigned to: Hartmut Henkel (hhenkel) Summary: Type 3 fonts: on screen fine, on paper filled and displaced Initial Comment: Hello! It's pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5), on Mac OS X 10.4.6, PPC. The Type 3 font is dijkstra, a famous person's handwriting, as distributed by many SunOS and Solaris versions. Until mid May I had no problem with pdfTeX, dijkstra, and my EPSON EPL-5800 (PostScript 3). This week I again wanted to print a personal letter with Prof. Dijkstra's handwriting used for my letter head. And some letters were filled (P,e,9), others were horizontally and/or vertically displaced from their correct positions. Dijkstra was installed with fontinst. Can this be a pdfTeX problem? End of May I added almost 1 GB of files to update SDKs etc. in Mac OS X to be able to produce Universal Binaries. The last few Tiger versions are known as a bit buggy. My last TeX binaries updates happened in the middle of May, but I have no LOG files from this. The recent LOGs from making the format files contain the string above ... Greetings Pete ---------------------------------------------------------------------- >Comment By: Peter Dyballa (ballapete) Date: 2006-07-26 15:25 Message: Logged In: YES user_id=2303 *I* am terribly sorry! Examining again my printer drivers upon your findings I now found that the PS3<version number> part of its name was removed! So I had some filter that converted PS or PDF into raster that was sent via ESP/P or such to the printer? I found the right PPD file in the right place and re-installed this as my printer -- and it prints again. (Although it puzzles me why I could print the PDF output from XeTeX! This worked all the last weeks.) Probably *I* was choosing the wrong items in the printer configuration dialog! Sorry for this! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-24 23:46 Message: Logged In: YES user_id=421 [Sorry for not reacting earlier, but gforge sends no mail when a file is attached; you also have to add a comment.] The attached file uses a Type 1 font and prints perfectly on an Lexmark Optra T612 (which has a PS3 RIP)... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-06-28 16:09 Message: Logged In: YES user_id=421 Please provide a pdf showing the problems (attach it to this bug). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=577&group_id=106

1 0

[ pdftex-Bugs-548 ] Forwarded problem with Test.jpg
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #548, was opened at 2006-05-10 18:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=548&group_id=106 Category: Image inclusion Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Forwarded problem with Test.jpg Initial Comment: Hello, in de.comp.text.tex Simon Eugster has problems with a jpg file: http://livingshadow.uttx.net/uploads/Test.jpg (Message-ID: <1147112925.079314.323190(a)v46g2000cwv.googlegroups.com>) I don't have a JPEG validator, but mozilla/firefox/ImageMagick/xzgv/file don't show any sign of problems with the JPEG file. Also I could reproduce his problems with pdfTeX 1.40.0-beta-20060213: \pdfximage{Test.jpg} | Error: pdftex (file ./Test.jpg): reading JPEG image failed | ==> Fatal error occurred, no output PDF file produced! Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 14:54 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-05-10 21:50 Message: Logged In: YES user_id=929 The test for JFIF file format was not adequate. Please test the patch. Bear in mind that currently only JFIF files allow to extract the image resolution values. For all others either explicitly give the wished dimensions (usual way), or set \pdfimageresolution. Else you get some default resolution. The problem went away also after treating Test.jpg (which is an EXIF file) by jhead -de, as this removed all EXIF headers. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=548&group_id=106

1 0

[ pdftex-Bugs-555 ] pdfLaTeX coredumps on OpenBSD
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #555, was opened at 2006-05-20 16:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106 Category: hz Group: v1.30.0 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Dag Leine (dag) Assigned to: Taco Hoekwater (taco) Summary: pdfLaTeX coredumps on OpenBSD Initial Comment: I've found, that pdfLaTeX coredumps on OpenBSD if I use amsmath and microtype in some math environments. Here is a minimal latex document for showing the bug: > cat minidump.tex \documentclass{article} \usepackage{amsmath} \usepackage{microtype} \setlength{\parindent}{0pt} \begin{document} \begin{align} x \end{align} \end{document} % end of minidump.tex > pdflatex minidump This is pdfeTeX, Version 3.141592-1.30.6-2.2 (Web2C 7.5.5) entering extended mode (./minidump.tex LaTeX2e <2003/12/01> Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur kish, ukrainian, nohyphenation, loaded. (/usr/local/share/texmf-dist/tex/latex/base/article.cls Document Class: article 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/share/texmf-dist/tex/latex/base/size10.clo)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/local/share/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.sty (/usr/local/share/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.cfg)) (./minidump.aux) (/usr/local/share/texmf-dist/tex/latex/microtype/mt-cmr.cfg)Segmentation fault (core dumped) A quick look with gdb shows, that it hangs in line 4396 of pdfetex2.c: c = getrpcode ( f , mem [p ].hh.b1 ) ; Here p=999996 and f=-4096 Since f seems to be a table index to pdffontrbase a negative value does not make sense to my mind. I've tryed the same on a LINUX machine. There pdfLaTeX does not crash, but p and f have the same values as under OpenBSD. As the most bad work around after taking *Word I've added a line of code which leaves the routine if f becomes negative. This seems to work in the sense, that there isn't any more a core dump. regards Dag ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 14:52 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-07-26 14:08 Message: Logged In: YES user_id=1608 FWIW, I looked at it and agree with Hartmut. --- pdftex.web.orig 2006-07-25 20:22:54.000000000 +0200 +++ pdftex.web 2006-07-26 14:19:35.514413422 +0200 @@ -24600,9 +24600,9 @@ p := q; ptmp := p; end else begin - p := prev_rightmost(temp_head, q); {get |link(p) = q|} + p := prev_rightmost(link(temp_head), q); {get |link(p) = q|} ptmp := p; - p := find_protchar_right(temp_head, p); + p := find_protchar_right(link(temp_head), p); end; @{ short_display_n(p, 1); ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-26 00:04 Message: Logged In: YES user_id=929 the value of temp_head seems to be right, but maybe it must be p := prev_rightmost(link(temp_head), q); {get |link(p) = q|} p := find_protchar_right(link(temp_head), p); with link(temp_head) instead of temp_head, as "The current line to be justified appears in a horizontal list starting at |link(temp_head)| and ending at |cur_break(cur_p)|." wild guess only, seems to work. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-25 23:33 Message: Logged In: YES user_id=929 seems it happens at this line in pdftex.web: p := prev_rightmost(temp_head, q); {get |link(p) = q|} the temp_head before this call is 1499996 which seems to be wrong. Then after the call p = 1499996, and there is font f=-4096 attached to this node which is also wrong. So it seems that somehow temp_head got lost before call of prev_rightmost(). No clue how. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-07-25 23:06 Message: Logged In: YES user_id=1608 ok, will check tomorrow ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 21:30 Message: Logged In: YES user_id=421 This still happens with the latest beta (I've got an OpenBSD machine now myself): Program received signal SIGSEGV, Segmentation fault. 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; (gdb) bt #0 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 #1 0x1c053d53 in zpostlinebreak (d=1) at pdftex2.c:7715 #2 0x1c007659 in zlinebreak (d=1) at pdftexini.c:2136 #3 0x1c05bb11 in initmath () at pdftex3.c:141 #4 0x1c065091 in maincontrol () at pdftex3.c:4582 #5 0x1c0130a2 in mainbody () at pdftexini.c:5647 #6 0x1c069d9e in main (ac=2, av=0xcfbd239c) at pdftexextra.c:340 (gdb) l pdftex2.c:3191 3186 c = getlpcode ( f , mem [p ].hh.b1 ) ; 3187 lastleftmostchar = p ; 3188 } 3189 else { 3190 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; 3192 lastrightmostchar = p ; 3193 } 3194 if ( c == 0 ) 3195 return Result ; (gdb) p f $1 = -4096 (gdb) p p $2 = 999996 (gdb) p mem[p].hh $3 = {v = {LH = -268435455, RH = 675}, u = {B1 = 1, B0 = -4096}} ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106

1 0

[ pdftex-Bugs-555 ] pdfLaTeX coredumps on OpenBSD
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #555, was opened at 2006-05-20 16:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106 Category: hz Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Dag Leine (dag) Assigned to: Taco Hoekwater (taco) Summary: pdfLaTeX coredumps on OpenBSD Initial Comment: I've found, that pdfLaTeX coredumps on OpenBSD if I use amsmath and microtype in some math environments. Here is a minimal latex document for showing the bug: > cat minidump.tex \documentclass{article} \usepackage{amsmath} \usepackage{microtype} \setlength{\parindent}{0pt} \begin{document} \begin{align} x \end{align} \end{document} % end of minidump.tex > pdflatex minidump This is pdfeTeX, Version 3.141592-1.30.6-2.2 (Web2C 7.5.5) entering extended mode (./minidump.tex LaTeX2e <2003/12/01> Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur kish, ukrainian, nohyphenation, loaded. (/usr/local/share/texmf-dist/tex/latex/base/article.cls Document Class: article 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/share/texmf-dist/tex/latex/base/size10.clo)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/local/share/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.sty (/usr/local/share/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.cfg)) (./minidump.aux) (/usr/local/share/texmf-dist/tex/latex/microtype/mt-cmr.cfg)Segmentation fault (core dumped) A quick look with gdb shows, that it hangs in line 4396 of pdfetex2.c: c = getrpcode ( f , mem [p ].hh.b1 ) ; Here p=999996 and f=-4096 Since f seems to be a table index to pdffontrbase a negative value does not make sense to my mind. I've tryed the same on a LINUX machine. There pdfLaTeX does not crash, but p and f have the same values as under OpenBSD. As the most bad work around after taking *Word I've added a line of code which leaves the routine if f becomes negative. This seems to work in the sense, that there isn't any more a core dump. regards Dag ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2006-07-26 14:08 Message: Logged In: YES user_id=1608 FWIW, I looked at it and agree with Hartmut. --- pdftex.web.orig 2006-07-25 20:22:54.000000000 +0200 +++ pdftex.web 2006-07-26 14:19:35.514413422 +0200 @@ -24600,9 +24600,9 @@ p := q; ptmp := p; end else begin - p := prev_rightmost(temp_head, q); {get |link(p) = q|} + p := prev_rightmost(link(temp_head), q); {get |link(p) = q|} ptmp := p; - p := find_protchar_right(temp_head, p); + p := find_protchar_right(link(temp_head), p); end; @{ short_display_n(p, 1); ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-26 00:04 Message: Logged In: YES user_id=929 the value of temp_head seems to be right, but maybe it must be p := prev_rightmost(link(temp_head), q); {get |link(p) = q|} p := find_protchar_right(link(temp_head), p); with link(temp_head) instead of temp_head, as "The current line to be justified appears in a horizontal list starting at |link(temp_head)| and ending at |cur_break(cur_p)|." wild guess only, seems to work. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-07-25 23:33 Message: Logged In: YES user_id=929 seems it happens at this line in pdftex.web: p := prev_rightmost(temp_head, q); {get |link(p) = q|} the temp_head before this call is 1499996 which seems to be wrong. Then after the call p = 1499996, and there is font f=-4096 attached to this node which is also wrong. So it seems that somehow temp_head got lost before call of prev_rightmost(). No clue how. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-07-25 23:06 Message: Logged In: YES user_id=1608 ok, will check tomorrow ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 21:30 Message: Logged In: YES user_id=421 This still happens with the latest beta (I've got an OpenBSD machine now myself): Program received signal SIGSEGV, Segmentation fault. 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; (gdb) bt #0 0x1c048f03 in zcharpw (p=999996, side=1 '\001') at pdftex2.c:3191 #1 0x1c053d53 in zpostlinebreak (d=1) at pdftex2.c:7715 #2 0x1c007659 in zlinebreak (d=1) at pdftexini.c:2136 #3 0x1c05bb11 in initmath () at pdftex3.c:141 #4 0x1c065091 in maincontrol () at pdftex3.c:4582 #5 0x1c0130a2 in mainbody () at pdftexini.c:5647 #6 0x1c069d9e in main (ac=2, av=0xcfbd239c) at pdftexextra.c:340 (gdb) l pdftex2.c:3191 3186 c = getlpcode ( f , mem [p ].hh.b1 ) ; 3187 lastleftmostchar = p ; 3188 } 3189 else { 3190 3191 c = getrpcode ( f , mem [p ].hh.b1 ) ; 3192 lastrightmostchar = p ; 3193 } 3194 if ( c == 0 ) 3195 return Result ; (gdb) p f $1 = -4096 (gdb) p p $2 = 999996 (gdb) p mem[p].hh $3 = {v = {LH = -268435455, RH = 675}, u = {B1 = 1, B0 = -4096}} ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106

1 0

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

26 Jul '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.30.0 >Status: Closed 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: Martin Schröder (oneiros) Date: 2006-07-26 12:27 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 08:17 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? ---------------------------------------------------------------------- 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

2 1

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

26 Jul '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.30.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: Martin Schröder (oneiros) Date: 2006-07-26 12:27 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 08:17 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? ---------------------------------------------------------------------- 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-415 ] various extensions and fixes
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #415, was opened at 2005-08-19 09:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106 Category: Primitives Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: various extensions and fixes Initial Comment: This is a patch for various experimental extensions: - \pdfinsertht: return the height of an insert (requested by Hans); this has similar syntax to \pdftexrevision. - do not fail when \pdfobj is used with an invalid object number (requested by Hans) - snapping: support for grid typesetting -- see snap.txt for details - kern before space: allow changing interword glues in a flexible way and inserting a kern before certain characters -- see kern-before-interword-glue.txt for details The notes in snap.txt and kern-before-interword-glue.txt are from email correspondence with people interested in; hence these notes are somewhat informal, inaccurate or out-of-date. How to apply: ~~~~~~~~~~~~~ cd /path/to/pdftex-1.30.0-srcdir/src/texk patch -p1 < /path/to/pdftex-20050818.patch cd web2c make pdfetex ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:31 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-09-04 18:22 Message: Logged In: YES user_id=421 The patch for invalid object numbers is included in 1.30.1++ ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106

1 0

[ pdftex-Patches-432 ] Rules in a PDF qQ group
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #432, was opened at 2005-10-06 21:01 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106 Category: Positioning Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hans Hagen (hagen) Summary: Rules in a PDF qQ group Initial Comment: Put rules with their positioning on the page inside a qQ group. Should make \pdfliteral page {...} behave consistently after text or rules or images, as then any positioning starts from the PDF origin; no delta-positioning anymore. It's already being tested in pdfluatex. Just to have it at sarovar... Testing welcome, particularily with text and graphics transforms by graphicx package, to spot backward incompatibilities, if any... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:29 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:07 Message: Logged In: YES user_id=929 Update pdf_set_origin_temp: Now has (h, v) parameters. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106

1 0