April 2007 - ntg-pdftex - NTG Mailing Lists

This is such a mess...
by David Kastrup 25 Apr '07

25 Apr '07

Take a look at the error locating lines in the log file produced from the following plain TeX file: The last error message can actually be considered correct, even though it is startling. In addition to the \endlinechar mess, it is disconcerting that ^^xx-like sequences in control sequence names get clobbered into something different in the top error context line but not in the second one. Some shortcuts in tex.web appear to be at fault here. Probably the main problem here is that Knuth chose not to copy control sequence names somewhere else while they are being assembled, but rather do the lookups/hash entries straight from the input buffer, if necessary, transforming the input buffer into something else on the way. Maybe it would be saner to copy the stuff out, either into a separate buffer, or to a designated free area at the end of the buffer area (like \csname does). Maybe it is possible to do this just conditionally when the control sequence name either has ^^ stuff in it, _or_ if it hits a buffer boundary (with the patch I am currently devising). But it maybe would not be expensive to copy always and use a dedicated buffer for the purpose of \cs assembly. Whatever. Still hunting through the TeX code. -- David Kastrup

1 0

[ pdftex-Bugs-777 ] Bug fix for \pdfunescapehex
by noreply＠sarovar.org 20 Apr '07

20 Apr '07

Bugs item #777, was opened at 2007-04-20 22:18 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=777&group_id=106 >Category: Primitives >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) >Assigned to: Martin Schröder (oneiros) Summary: Bug fix for \pdfunescapehex Initial Comment: The patch is based on pdftex-1.40.3 and fixes a bug of \pdfunescapehex: \pdfunescapehex returns a wrong result, if the last character is not a hexadecimal digit and the last hex pair is incomplete. Test: \def\test#1#2{% \edef\x{\pdfunescapehex{#1}}% \edef\y{\detokenize{#2}}% \immediate\write16{% [\detokenize{#1}] -> % [\x] \ifx\x\y= \else<> \fi [\y]% }% } \test{50}{P}% ok \test{50X}{P}% ok \test{5 }{P}% bug \test{5X}{P}% bug \csname @@end\endcsname \end Bug fix is attached: utils.c.diff patches pdftexdir/utils.c. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=777&group_id=106

1 0

[ pdftex-Bugs-777 ] Bug fix for \pdfunescapehex
by noreply＠sarovar.org 20 Apr '07

20 Apr '07

Bugs item #777, was opened at 2007-04-20 22:18 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=777&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Bug fix for \pdfunescapehex Initial Comment: The patch is based on pdftex-1.40.3 and fixes a bug of \pdfunescapehex: \pdfunescapehex returns a wrong result, if the last character is not a hexadecimal digit and the last hex pair is incomplete. Test: \def\test#1#2{% \edef\x{\pdfunescapehex{#1}}% \edef\y{\detokenize{#2}}% \immediate\write16{% [\detokenize{#1}] -> % [\x] \ifx\x\y= \else<> \fi [\y]% }% } \test{50}{P}% ok \test{50X}{P}% ok \test{5 }{P}% bug \test{5X}{P}% bug \csname @@end\endcsname \end Bug fix is attached: utils.c.diff patches pdftexdir/utils.c. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=777&group_id=106

1 0

[ pdftex-Bugs-776 ] Filenames with multiple spaces are not recognized
by noreply＠sarovar.org 18 Apr '07

18 Apr '07

Bugs item #776, was opened at 2007-04-17 22:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106 Category: Primitives >Group: v1.40.0 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Nobody (None) Summary: Filenames with multiple spaces are not recognized Initial Comment: $ echo 'hello world\bye' > hello\ \ world.tex $ cat hello\ \ world.tex hello world\bye $ pdftex hello\ \ world.tex This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6) entering extended mode ! I can't find file `"hello world.tex"'. <*> "hello world.tex" Please type another input file name: It seems that pdftex gets the correct name (with two spaces) but it is searching for something different. Regards, Reinhard ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-04-18 18:13 Message: Logged In: YES user_id=421 I agree: This is simply an undocumented misfeature. Anybody who uses space in filenames in TeX does so at this own risk, and this should be documented. I don't think the time for fixing this is justified. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-17 23:36 Message: Logged In: NO The command line is scanned by TeX. The catcodes for the filename are determined by the format. If you want TeX to be able to deal with multiple spaces, you can do so by doing \everyjob\expandafter{\the\everyjob \catcode`\ =10\relax} \catcode`\ =12 \dump% as the last thing when generating your format file. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-04-17 23:20 Message: Logged In: YES user_id=1608 It will handle this properly: $ pdftex hello\ \space\ world.tex The problem (of course) is that the tokenizer will fold two (or more) tokens of \catcode 10 into a single one, so you have to prevent tex from seeing two of these in-a-row. It may actually be possible to fix the case where the file is given as a single argument on the commandline, but fixing the general case is unreasonably hard (e.g. \input commands used inside macros), I do not think would be worth the effort and therefore vote for documenting the current behaviour as a known limitation. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106

3 2

[ pdftex-Bugs-775 ] Build failure on alpha-linux with certain gcc versions
by noreply＠sarovar.org 18 Apr '07

18 Apr '07

Bugs item #775, was opened at 2007-04-16 11:59 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=775&group_id=106 Category: Build process >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Frank Küster (frank) Assigned to: Martin Schröder (oneiros) Summary: Build failure on alpha-linux with certain gcc versions Initial Comment: pdftex fails to build on Linux-alpha with newer gcc versions. This is a known bug in gcc, but it's very obscure and it seems unlikely to be solved soon. Therefore you might consider to apply the patch below as a workaround. Falk Hueffner wrote in the Debian BTS (http://bugs.debian.org/419434) [...] gcc -DHAVE_CONFIG_H -I. -I../../../../texk/web2c/pdftexdir -I.. -I../../../../texk/web2c/pdftexdir/../.. -I.. -I../../../../texk/web2c/pdftexdir/.. -I../.. -I../../../../texk/web2c/pdftexdir/../.. -I../../../libs/md5 -I../../../../texk/web2c/pdftexdir/../../../libs/md5 -I../../../libs/xpdf -I../../../libs/xpdf/.. -I../../../../texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../texk/web2c/pdftexdir/../../../libs/xpdf/.. -I../../../libs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../../texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DpdfTeX -g -O2 -c ../../../../texk/web2c/pdftexdir/writezip.c -o writezip.o ../../../../texk/web2c/pdftexdir/writezip.c: In function 'writezip': ../../../../texk/web2c/pdftexdir/writezip.c:75: error: unrecognizable insn: (insn 139 138 140 9 ../../../../texk/web2c/pdftexdir/writezip.c:54 (set (reg:DI 141) (plus:DI (reg/f:DI 138) (const_int 32768 [0x8000]))) -1 (nil) (nil)) ../../../../texk/web2c/pdftexdir/writezip.c:75: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>. Preprocessed source stored into /tmp/ccKHjfIv.out file, please attach this to your bugreport. make[4]: *** [writezip.o] Error 1 make[4]: Leaving directory `/build/buildd/texlive-bin-2007/build/source/Work/texk/web2c/pdftexdir' (log at http://buildd.debian.org/fetch.cgi?pkg=texlive-bin&arch=alpha&ver=2007-3&st…) The reason is an obscure bug in gcc that only triggers when accessing exactly the 32767th element of a character array. Since I don't know how fix it in gcc and nobody else seems to be working on that, I suggest you apply the following workaround: ---------------------------------------------------------------------- Comment By: Frank Küster (frank) Date: 2007-04-16 12:04 Message: Logged In: YES user_id=3360 forgot to tick the "attach file" box ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=775&group_id=106

1 0

\mathsurround
by Javier Múgica de Rivera 18 Apr '07

18 Apr '07

I recently needed to typeset a narrow column with some math, so very dificult to find break points resulting in acceptable looking lines. I found that the best solution would be achieved if I had, say, \mathsurround=0pt plus2pt, but \muthsurround is a dimen, not a skip. Is there any particular reason why it is not a glue? If there is not, it would be easy to implement, wouldn't it? --Javier

3 5

[ pdftex-Bugs-776 ] Filenames with multiple spaces are not recognized
by noreply＠sarovar.org 17 Apr '07

17 Apr '07

Bugs item #776, was opened at 2007-04-18 02:18 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106 Category: Primitives Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Nobody (None) Summary: Filenames with multiple spaces are not recognized Initial Comment: $ echo 'hello world\bye' > hello\ \ world.tex $ cat hello\ \ world.tex hello world\bye $ pdftex hello\ \ world.tex This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6) entering extended mode ! I can't find file `"hello world.tex"'. <*> "hello world.tex" Please type another input file name: It seems that pdftex gets the correct name (with two spaces) but it is searching for something different. Regards, Reinhard ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-18 03:06 Message: Logged In: NO The command line is scanned by TeX. The catcodes for the filename are determined by the format. If you want TeX to be able to deal with multiple spaces, you can do so by doing \everyjob\expandafter{\the\everyjob \catcode`\ =10\relax} \catcode`\ =12 \dump% as the last thing when generating your format file. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-04-18 02:50 Message: Logged In: YES user_id=1608 It will handle this properly: $ pdftex hello\ \space\ world.tex The problem (of course) is that the tokenizer will fold two (or more) tokens of \catcode 10 into a single one, so you have to prevent tex from seeing two of these in-a-row. It may actually be possible to fix the case where the file is given as a single argument on the commandline, but fixing the general case is unreasonably hard (e.g. \input commands used inside macros), I do not think would be worth the effort and therefore vote for documenting the current behaviour as a known limitation. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106

1 0

[ pdftex-Bugs-776 ] Filenames with multiple spaces are not recognized
by noreply＠sarovar.org 17 Apr '07

17 Apr '07

Bugs item #776, was opened at 2007-04-17 22:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106 Category: Primitives Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Nobody (None) Summary: Filenames with multiple spaces are not recognized Initial Comment: $ echo 'hello world\bye' > hello\ \ world.tex $ cat hello\ \ world.tex hello world\bye $ pdftex hello\ \ world.tex This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6) entering extended mode ! I can't find file `"hello world.tex"'. <*> "hello world.tex" Please type another input file name: It seems that pdftex gets the correct name (with two spaces) but it is searching for something different. Regards, Reinhard ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-04-17 23:20 Message: Logged In: YES user_id=1608 It will handle this properly: $ pdftex hello\ \space\ world.tex The problem (of course) is that the tokenizer will fold two (or more) tokens of \catcode 10 into a single one, so you have to prevent tex from seeing two of these in-a-row. It may actually be possible to fix the case where the file is given as a single argument on the commandline, but fixing the general case is unreasonably hard (e.g. \input commands used inside macros), I do not think would be worth the effort and therefore vote for documenting the current behaviour as a known limitation. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106

1 0

[ pdftex-Bugs-776 ] Filenames with multiple spaces are not recognized
by noreply＠sarovar.org 17 Apr '07

17 Apr '07

Bugs item #776, was opened at 2007-04-17 22:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106 Category: Primitives Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Nobody (None) Summary: Filenames with multiple spaces are not recognized Initial Comment: $ echo 'hello world\bye' > hello\ \ world.tex $ cat hello\ \ world.tex hello world\bye $ pdftex hello\ \ world.tex This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6) entering extended mode ! I can't find file `"hello world.tex"'. <*> "hello world.tex" Please type another input file name: It seems that pdftex gets the correct name (with two spaces) but it is searching for something different. Regards, Reinhard ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106

1 0

[ pdftex-Bugs-772 ] Option -recorder does not work for Type1 or PK files
by noreply＠sarovar.org 17 Apr '07

17 Apr '07

Bugs item #772, was opened at 2007-04-13 04:54 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106 Category: web2c Group: v1.40.0 Status: Open Resolution: Accepted Priority: 4 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Option -recorder does not work for Type1 or PK files Initial Comment: Hello, pdfTeX 1.40.3 supports the Web2C feature, enabled by option -recorder. However, it does not record all files, .pfb (Type1) or .pk files are missing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: texmf.cnf isn't recorded either. ---------------------------------------------------------------------- >Comment By: Heiko Oberdiek (oberdiek) Date: 2007-04-17 13:19 Message: Logged In: YES user_id=1276 Hello, to prevent that it gets lost, a followup of mine in ntg-pdftex mailing list: After further testing (sorry) I found other gaps in file name recording: \pdfximage{<file>} \pdffilesize{<file>} \pdffilemoddate{<file>} \pdffiledump{<file>} \pdfmdfivesum file{<file>} Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106

1 0