- ntg-pdftex - NTG Mailing Lists

q..Q rules again
by Paweł Jackowski 08 May '07

08 May '07

Hello, there is something which still puzzles me in \pdfliteral regarding q..Q rules. Lets take \def\test{\vrule width12bp height12bp depth0pt } To make some graphic-safe stuff in old pdfTeX one could to say \test \pdfliteral{q}% \test \pdfliteral{Q 1 0 0 1 12 0 cm}% \test Starting from pdfTeX 1.30 one can accomplish that using `page' keyword, which results in better content stream \test \pdfliteral page{q}% \test \pdfliteral page{Q}% \test But once we use both (which is not quite useless!) we finish somewhere outside the page; \test \pdfliteral page{q}% some graphic operators \pdfliteral{q}% some transform \test \pdfliteral{Q 1 0 0 1 12 0 cm}% \pdfliteral page{Q}% \test The reason is that last the matrix (translating coordinates back to the lower-left corner) is placed after the _second_ Q. But I'd rather expect that transform after the first (inner) one. What is the reason for that? -- Pawe/l Jackowski P.Jackowski(a)gust.org.pl

2 6

Re: [NTG-pdftex] Decode issue
by Thanh Han The 07 May '07

07 May '07

I had problem sending this mail and try it again, so my apologize to people who receive this mail twice. ========================================================== Hi, I looked into the sources. The Decode array insertion is hardcoded whenever a jpeg image with colorspace CMYK is included. The support of additional colorspace was added by request of Hans Hagen IIRC, he needed a mean to change the default colorspace of images. So it was done with this assumption: if someone supplies his own colorspace, he is responsible for everything related. I am not sure what can be done with this, since it's hard to define the right behaviour of pdftex in this situation. My vote is to leave things as they are, and document relevant issues in the manual. Thanh PS: I uploaded the test files here: http://www.sendspace.com/file/rc04al On Thu, May 03, 2007 at 08:48:10PM +0200, Pawel Jackowski wrote: > Hi! > > While making a sample for Jano in BachoTeX I've found the following > issue. Please consider the attached example. > > pdfTeX automatically recognizes embedded JPEG colorspace. I guess it > also reads decoding parameters from the image and (re)inserts them to > PDF if necessary; in the first case one may see > > /ColorSpace /DeviceCMYK > /Decode [1 0 1 0 1 0 1 0] > > key in XObject dictionary. Once the user povides 'colorspace' keyword, > no /Decode is inserted, that (may) result in negative output, as in > example. Obviously one can insert decoding as a custom image attribute, > but one cannot control what is the proper decoding. > > This happens for all cmyk jpegs from photoshop. > > Cheers, > -- > Pawe/l Jackowski > GUST, Poland > P.Jackowski(a)gust.org.pl > www.pawcoo.com > www.acchsh.com

5 4

[ pdftex-Bugs-794 ] Non-embedding Helvetica leads to invalid font flags
by noreply＠sarovar.org 04 May '07

04 May '07

Bugs item #794, was opened at 2007-05-04 01:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=794&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: None Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: Non-embedding Helvetica leads to invalid font flags Initial Comment: This is related to #762: PDFs with Helvetica not embedded get a Helvetica with /FontName /Helvetica /Flags 34 which leads to a strange behaviour: AR7 uses Adobe Serif for online viewing (i.e. you get a Serif approximation of Helvetica) and prints to a PostScript printer use Helvetica. This is also tracked by Debian at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421464 A much simpler testcase is attached. The manual is interesting in this case: "If the font flags are not given, pdfTEX treats it as being 4, a symbolic font. If you do not know the correct value, it is best not to specify it at all, as specifying a bad value of font flags may cause troubles in viewers." The usual map files have no font flag entry for Helvetica. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=794&group_id=106

1 0

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