May 2007 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-606 ] Forbidden ... while scanning ???
by noreply＠sarovar.org 27 May '07

27 May '07

Bugs item #606, was opened at 2006-09-16 22:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=606&group_id=106 Category: Primitives Group: v1.40.0 Status: Open Resolution: Postponed Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: Forbidden ... while scanning ??? Initial Comment: \pdftrailer {abc \bye gives ! Forbidden control sequence found while scanning text of \pdftrailer. but \pdfximage {abc \bye or \pdfliteral {abc \bye give ! Forbidden control sequence found while scanning text of ???. Instead of these three question marks there should be the name of the primitive. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-05-27 17:40 Message: Logged In: YES user_id=421 Hartmut, can you please check this again for 1.50? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-21 14:22 Message: Logged In: YES user_id=421 I've backed out the change; this is low priority and probably needs more changes. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-17 21:10 Message: Logged In: YES user_id=929 yes, the patch works, thanks a lot! But there are in fact many more \pdf... primitives that suffer from this problem, actually any with a scan_keyword call before the scan_pdf_ext_toks. After the way how it's done in @<Implement \.{\write}@>=, it seems that a new variable save_cur_cs is not needed if one uses k for this purpose. Needs change of a few k uses to j. But problematic is \pdfoutline as it has another scan_pdf_ext_toks for the attr keyword. Wouldn't these many changes be too risky for 1.40.0? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 18:34 Message: Logged In: YES user_id=421 The patch was missing. Fixed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 16:30 Message: Logged In: YES user_id=421 The cause seems to be that some scan_functions loose the meaning of cur_cs, which leads to the ??? when reaching <Tell the user what has run away...@>. The attached (IMHO crude) patch fixes this for the cases you mentioned, but there are probably other cases not found... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=606&group_id=106

1 0

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

27 May '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: Closed >Resolution: Fixed 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> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-27 15:16 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=777&group_id=106

1 0

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

27 May '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: Closed >Resolution: Wont Fix 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: Martin Schröder (oneiros) Date: 2007-05-27 15:14 Message: Logged In: YES user_id=421 This has been fixed upstream (in gcc). ---------------------------------------------------------------------- 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-799 ] \pdfstartlink duplicate objects when copying boxes
by noreply＠sarovar.org 27 May '07

27 May '07

Bugs item #799, was opened at 2007-05-27 12:07 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=799&group_id=106 Category: Annotations Group: v1.40.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) >Assigned to: Hartmut Henkel (hhenkel) Summary: \pdfstartlink duplicate objects when copying boxes Initial Comment: When \pdfstartlink is used inside a \hbox, repeated \copy of that box produces the same /Link annotation object multiply, with same object number and identical coordinates on the page. That's wrong, and it gives also problems with object streams, as reported by Luigi Scarso. The tiny patch tries to solve this. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-27 14:56 Message: Logged In: YES user_id=929 patch extended to general \pdfannot. Without the patch acroread 7.0.9 (linux) refuses to display test4.pdf. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=799&group_id=106

1 0

[ pdftex-Bugs-799 ] \pdfstartlink duplicate objects when copying boxes
by noreply＠sarovar.org 27 May '07

27 May '07

Bugs item #799, was opened at 2007-05-27 12:07 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=799&group_id=106 Category: Annotations Group: v1.40.3 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: \pdfstartlink duplicate objects when copying boxes Initial Comment: When \pdfstartlink is used inside a \hbox, repeated \copy of that box produces the same /Link annotation object multiply, with same object number and identical coordinates on the page. That's wrong, and it gives also problems with object streams, as reported by Luigi Scarso. The tiny patch tries to solve this. ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-27 14:56 Message: Logged In: YES user_id=929 patch extended to general \pdfannot. Without the patch acroread 7.0.9 (linux) refuses to display test4.pdf. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=799&group_id=106

1 0

[ pdftex-Bugs-799 ] \pdfstartlink duplicate objects when copying boxes
by noreply＠sarovar.org 27 May '07

27 May '07

Bugs item #799, was opened at 2007-05-27 12:07 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=799&group_id=106 Category: Annotations Group: v1.40.3 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: \pdfstartlink duplicate objects when copying boxes Initial Comment: When \pdfstartlink is used inside a \hbox, repeated \copy of that box produces the same /Link annotation object multiply, with same object number and identical coordinates on the page. That's wrong, and it gives also problems with object streams, as reported by Luigi Scarso. The tiny patch tries to solve this. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=799&group_id=106

1 0

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

26 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: Closed Resolution: Fixed 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. ---------------------------------------------------------------------- Comment By: Norbert Preining (norbusan) Date: 2007-05-26 18:44 Message: Logged In: YES user_id=2156 Hi Martin! Could you send me a diff for the fix if it is not too invasive? Thanks a lot. Norbert ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-25 19:48 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=794&group_id=106

1 0

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

25 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: Closed >Resolution: Fixed 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. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-25 19:48 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=794&group_id=106

1 0

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

25 May '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: Closed >Resolution: Fixed 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-05-25 19:47 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- 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-796 ] Different behaviour of latex/pdflatex with word breakups
by noreply＠sarovar.org 19 May '07

19 May '07

Bugs item #796, was opened at 2007-05-13 09:45 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=796&group_id=106 Category: None Group: v1.40.0 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Ingo H. de Boer (idb_winshell) Assigned to: Nobody (None) Summary: Different behaviour of latex/pdflatex with word breakups Initial Comment: Hi, I am working on a document with latex2html and the tag \htmlref. I have the sentence: "... My program provides the following command line arguments, used for e.g. \htmlref{Forward and inverse search}{forwardinversesearch}: ..." Now, I have compiled it with latex and pdflatex. latex does no breakup of the words, whereas pdflatex does it. Due to this fact, I do not think that it is a problem of the latex2html package. I do have the latest packages/version of Miktex 2.6 which is working with pdftex 1.40.3 Please find attached a screenshot of the dvi file and the pdf file to make this more clear. greets Ingo ---------------------------------------------------------------------- >Comment By: Ingo H. de Boer (idb_winshell) Date: 2007-05-19 16:41 Message: Logged In: YES user_id=4469 Hi, I didn't use the hyperref package directly in my code and I by default I do not expect different behaviour between pdflatex and latex. For latex there is a must of having this line: \usepackage[breaklinks=true]{hyperref} but not for pdflatex. In pdflatex it is autotmatic. It's kinda odd to the normal user that it behaves differently. greets Ingo ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-13 13:21 Message: Logged In: YES user_id=421 This is a feature of the hyperref package. If you think otherwise, please provide a minimal example. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-05-13 10:07 Message: Logged In: NO You could try reading the documentation of the hyperref package. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=796&group_id=106

1 0