- ntg-pdftex - NTG Mailing Lists

[ 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 22:31 Message: Logged In: YES user_id=929 much simpler patch, only on pdftex.web, no need for yet another AVL tree. And maybe some obscure possible bug with object streams caught. ---------------------------------------------------------------------- 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-Patches-735 ] patch for simplified horizontal positional tracking
by noreply＠sarovar.org 27 May '07

27 May '07

Patches item #735, was opened at 2007-02-19 22:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=735&group_id=106 Category: Positioning Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) >Assigned to: Hartmut Henkel (hhenkel) Summary: patch for simplified horizontal positional tracking Initial Comment: 1. simpler calculations for horizontal position update when inside []TJ arrays, now by pure additions within a fontsize/10000 raster; no rounding errors can accumulate. Gives about 7 % pdftex speed gain when typesetting fiction-type stuff. 2. writet3.c now also with standard /FontMatrix [0.001 0 0 0.001 0 0], tidied up a little (.pgc part untested). No need anymore (hope it's right) to handle PK fonts specially by adv_char_width() in pdftex.web. 3. wrong use of printf() at a few places corrected by Martin. Work in progess, not safe for production. Needs more testing, particularly with PK fonts. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-03-04 11:27 Message: Logged In: YES user_id=929 the extended patch 70226a needs more work; removed the patch file. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-02-25 23:51 Message: Logged In: YES user_id=929 The previous patch 735 is now extended to general text and graphics positioning on the PDF page. pdf_set_origin() (now pdf_move_to()), pdf_set_textmatrix(), and pdf_begin_string() are rewritten. In low placement resolution (e. g. \pdfdecimaldigits=0) now the glyph placement is corrected within the []TJ array by a leading number, like [7(a)...]TJ, if required, so that always full TeX precision is kept (very early pdftex versions might have used this also). Any accumulation of rounding errors should be avoided now by the used calculation principle. Needs lots of testing. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=735&group_id=106

1 0

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

27 May '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: v1.40.3 Status: Open >Resolution: Accepted 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

[ 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