- 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 03 May '07

03 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

[ 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

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

16 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: None Status: Open Resolution: None 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

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

16 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: None Status: Open Resolution: None 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: ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=775&group_id=106

1 0

[ pdftex-Bugs-774 ] UniqueID in subsetted Type1 fonts
by noreply＠sarovar.org 15 Apr '07

15 Apr '07

Bugs item #774, was opened at 2007-04-15 23:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=774&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Hartmut Henkel (hhenkel) Summary: UniqueID in subsetted Type1 fonts Initial Comment: The currant version of pdftex removes the UniqueID from the font dictionary when a subset of a Type1 font is included. However, there is still a UniqueID in the Private dictionary which should be removed too. >From the PostScript Language Reference Manual (p. 336): > When you copy a font dictionary for the purpose of > creating a modified font, you should not copy the > UniqueID or XUID entry. As an exception to this > general rule, it is acceptable (and preferable) to > retain the original UniqueID or XUID entry if > the only modified entries are FontName, FontInfo, > FontMatrix, or Encoding, because those changes do not > affect the glyphs’ appearance or metrics. Regards, Reinhard ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=774&group_id=106

1 0

Re: [NTG-pdftex] [ pdftex-Bugs-772 ] Option -recorder does not work for Type1 or PK files
by Akira Kakuto 15 Apr '07

15 Apr '07

Hi Heiko, > Bugs item #772, was opened at 2007-04-13 04:54 > 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. I think texmf.cnf is not read by using open_input also in the case of the other TeX programs. Best regards, Akira --- writet1.c.orig Wed Dec 27 08:37:36 2006 +++ writet1.c Sun Apr 15 11:00:09 2007 @@ -921,10 +921,18 @@ static boolean t1_open_fontfile(const char *open_name_prefix) { ff_entry *ff; - ff = check_ff_exist(fd_cur->fm->ff_name, is_truetype(fd_cur->fm)); - if (ff->ff_path != NULL) - t1_file = xfopen(cur_file_name = ff->ff_path, FOPEN_RBIN_MODE); - else { + boolean is_tt = is_truetype (fd_cur->fm); + ff = check_ff_exist(fd_cur->fm->ff_name, is_tt); + if (ff->ff_path != NULL) { + cur_file_name = ff->ff_path; + if (nameoffile) free (nameoffile); + nameoffile = (char *)malloc (strlen (cur_file_name) + 2); + (void)strcpy (nameoffile + 1, cur_file_name); + if (is_tt) + open_input (&t1_file, kpse_truetype_format, FOPEN_RBIN_MODE); + else + open_input (&t1_file, kpse_type1_format, FOPEN_RBIN_MODE); + } else { set_cur_file_name(fd_cur->fm->ff_name); pdftex_warn("cannot open Type 1 font file for reading"); return false; --- writet3.c.orig Wed Dec 27 08:37:36 2006 +++ writet3.c Sun Apr 15 11:02:10 2007 @@ -197,7 +197,13 @@ cur_file_name = NULL; return false; } - t3_file = xfopen(name, FOPEN_RBIN_MODE); + if (nameoffile) free (nameoffile); + nameoffile = (char *)malloc (strlen (name) + 2); + strcpy (nameoffile + 1, name); + if (!open_input (&t3_file, kpse_pk_format, FOPEN_RBIN_MODE)) { + pdftex_warn ("missing pk font %s.", name); + return false; + } t3_image_used = true; is_pk_font = true; tex_printf(" <%s", (char *) name);

2 1

Re: [NTG-pdftex] [pdftex] Font (embedding) problem
by Reinhard Kotucha 14 Apr '07

14 Apr '07

Hi, I now added pdftex, NTG-pdftex, and Eddie to the CC. For people who did not follow the thread on the pdftex mailing list, here is a short summary: Marcel created some subsets of an OTF font using lcdf typetools. One subset used normal figures, one used oldstyle figures and one used superscript figures. His printer produced wrong output. I examined the output files produced by pdftex: All the subsets used the same encoding scheme, the glyph names had been /one, /two, and /three in all subsets, the /UniqueID is the same in all subsets. The only difference was /FontName since an arbitrary string had been prepended to the original /FontName. It turned out that Marcel's printer ignores /FontName and entirely depends on the /UniqueID. I converted the three subsets to PFA and wrote a small test file and even Ghostscript (-sDEVICE=X11alpha) produced wrong output. See: http://ms25.ath.cx/testfonts.ps It works with gs if you comment out the /UniqueID in testfonts.ps but this seems not to be sufficient for Marcel's printer because: >>>>> "Marcel" == Marcel Korpel <marcel.lists(a)gmail.com> writes: > On 04/04/07, Reinhard Kotucha <reinhard.kotucha(a)web.de> wrote: >> The current release (1.40.3) does this already. At least it >> removes the first occurrence of the UniqueID. But there is still >> a UniqueID in the /Private dictionary. Maybe it should be >> removed too. I'm quite confident that no interpreter looks for a >> UniqueID in the /Private dictionary. > Well, at least the mentioned Océ printer seems to use it. When I > only remove the first instance of the /UniqueID, the bug pops up > again... In my opinion it is wrong to ignore /FontName. But on the other hand I think that it is also wrong *not* to delete the /UniqueID when a subset of a font is created. I don't know what the Adobe reference manuals say, the nasty things are in the TechNotes, but it seems that developers of PS interpreters interpret the specs slightly different anyway. Though I think that the /UniqueID is helpful to distinguish between Adobe Courier and IBM Courier (shipped with X11), I now come to the conclusion that it causes more trouble than it helps. I don't think that it's bad that a font provides a /UniqueID. But it is probably quite appropriate to remove it when a subset is created. The current release of pdftex deletes the /UniqueID from the font dictionary but not the instance in the /Private dictionary. But certainly it should. I also think that lcdf typetools should remove the /UniqueID if a font is altered. 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 4

problem when using package color with floats
by Bintu Vasudevan 13 Apr '07

13 Apr '07

Hi when i redefine the macro used for floats (including figures and tables) so that single spacing is used. My tex file compile and as work fine. But when i want to usepackage{color} is hangs througing with message: ============================================= ! Too many }'s. \color@endbox ->\color@endgroup \egroup l.39 \end{figure} ? ============================================== Here is Redefined the macro defined ----------------------------------------------------------------------------------------------------- % (Note \def\figure{\@float{figure}set single spacing} doesn't work % because figure has an optional argument) \def\@xfloat#1[#2]{\ifhmode \@bsphack\@floatpenalty -\@Mii\else \@floatpenalty-\@Miii\fi\def\@captype{#1}\ifinner \@parmoderr\@floatpenalty\z@ \else\@next\@currbox\@freelist{\@tempcnta\csname ftype@#1\endcsname \multiply\@tempcnta\@xxxii\advance\@tempcnta\sixt@@n \@tfor \@tempa :=#2\do {\if\@tempa h\advance\@tempcnta \@ne\fi \if\@tempa t\advance\@tempcnta \tw@\fi \if\@tempa b\advance\@tempcnta 4\relax\fi \if\@tempa p\advance\@tempcnta 8\relax\fi }\global\count\@currbox\@tempcnta}\@fltovf\fi \global\setbox\@currbox\vbox\bgroup \def\baselinestretch{1}\@normalsize \boxmaxdepth\z@ \hsize\columnwidth \@parboxrestore} ----------------------------------------------------------------------------------------------------- can some body help in this case. Thanks in Advance bintu --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.

2 1

Re: [NTG-pdftex] [pdftex] Font (embedding) problem
by Thanh Han The 13 Apr '07

13 Apr '07

yes. At least for me. Regards, Thanh On Thu, Apr 12, 2007 at 07:21:14AM -0700, Eddie Kohler wrote: > Fonts produced by lcdf-typetools usually work fine with pdftex!... ?? > > Eddie > > > Marcel Korpel wrote: > > On 12/04/07, Eddie Kohler <kohler(a)cs.ucla.edu> wrote: > >> How did Marcel create the subsets? I imagine that pdftex was > >> responsible for the real subsetting; that the lcdf-typetools simply > >> created the initial font. > > > > No, I didn't use lcdf-tools, it wasn't an OTF font. I was wrong in my > > initial mail. When using a different font encoding with the same PFB > > fle (produced by lcdf-tools), everything was ok. > > > > I created the subsets using Fontforge, manually, and put the right > > characters in the right positions, so I could use them with pdfTeX. > > > > Sorry for this confusion caused, I was not wholly clear. > > > > Regards, > > Marcel > _______________________________________________ > pdftex mailing list > pdftex(a)tug.org > http://tug.org/mailman/listinfo/pdftex

1 0

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

13 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. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106

1 0

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

13 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) 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. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106

1 0

\pdfprimitive
by Heiko Oberdiek 11 Apr '07

11 Apr '07

Hello, \def\show{Hello World} \pdfprimitive\show\relax I would expect that the primitive \show (not the macro) is executed and shows \relax. Instead I get an error (pdfTeX 1.40.3): ! Undefined control sequence. l.2 \pdfprimitive\show Did I misunderstood \pdfprimitive? Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> --

6 23

[ pdftex-Bugs-762 ] symbolic font gets /Flags as nonsymbolic
by noreply＠sarovar.org 04 Apr '07

04 Apr '07

Bugs item #762, was opened at 2007-04-04 19:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: Accepted Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: symbolic font gets /Flags as nonsymbolic Initial Comment: The input file \pdfcompresslevel=0 \pdfmapline{psyr Symbol} \nopagenumbers \font\sy=psyr \sy a \end results in a pdf with a Font Descriptor with /Flags 34 for the Symbol font, which is wrong; it should be 4. The flags are initialized as 4 in mapfile.c and writefont.c sees this as the default value and writes 34 to the pdf. Reported by TeX Guy <pdftexlist(a)gmail.com> and analyzed by George N. White III <gnwiii(a)gmail.com>; see the thread starting at http://tug.org/pipermail/pdftex/2007-April/007133.html ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-04-04 19:42 Message: Logged In: YES user_id=421 The default might be reasonable, but even setting the fontflags as 4 (symbol) doesn't work, as this is interpreted as being the default and changed to 34. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106

1 0

[ pdftex-Bugs-762 ] symbolic font gets /Flags as nonsymbolic
by noreply＠sarovar.org 04 Apr '07

04 Apr '07

Bugs item #762, was opened at 2007-04-04 19:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106 Category: Fonts Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: symbolic font gets /Flags as nonsymbolic Initial Comment: The input file \pdfcompresslevel=0 \pdfmapline{psyr Symbol} \nopagenumbers \font\sy=psyr \sy a \end results in a pdf with a Font Descriptor with /Flags 34 for the Symbol font, which is wrong; it should be 4. The flags are initialized as 4 in mapfile.c and writefont.c sees this as the default value and writes 34 to the pdf. Reported by TeX Guy <pdftexlist(a)gmail.com> and analyzed by George N. White III <gnwiii(a)gmail.com>; see the thread starting at http://tug.org/pipermail/pdftex/2007-April/007133.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106

1 0