- ntg-pdftex - NTG Mailing Lists

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

29 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: Fixed 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-29 23:26 Message: Logged In: YES user_id=929 Now for each \pdfstartlink and \pdfannot node in the case of multiple \copy a new object is generated. This gives each of multiple annotation copies a new correctly placed rectangle on the page. New is that now in the case of duplicate \pdfrefobj only the 1st one will be written, copies are silently ignored. New patch for testing/discussion. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-28 22:56 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: Hartmut Henkel (hhenkel) Date: 2007-05-27 23:06 Message: Logged In: YES user_id=929 same simple patch on pdftex.web. The suspicion of an "obscure possible bug" was wrong. Sorry for the noise. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-27 22:49 Message: Logged In: YES user_id=929 sorry, that was wrong. ---------------------------------------------------------------------- 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-Bugs-799 ] \pdfstartlink duplicate objects when copying boxes
by noreply＠sarovar.org 29 May '07

29 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: Fixed 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: Martin Schröder (oneiros) Date: 2007-05-28 22:56 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: Hartmut Henkel (hhenkel) Date: 2007-05-27 23:06 Message: Logged In: YES user_id=929 same simple patch on pdftex.web. The suspicion of an "obscure possible bug" was wrong. Sorry for the noise. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-27 22:49 Message: Logged In: YES user_id=929 sorry, that was wrong. ---------------------------------------------------------------------- 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-Bugs-799 ] \pdfstartlink duplicate objects when copying boxes
by noreply＠sarovar.org 28 May '07

28 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: Closed >Resolution: Fixed 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: Martin Schröder (oneiros) Date: 2007-05-28 22:56 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: Hartmut Henkel (hhenkel) Date: 2007-05-27 23:06 Message: Logged In: YES user_id=929 same simple patch on pdftex.web. The suspicion of an "obscure possible bug" was wrong. Sorry for the noise. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-27 22:49 Message: Logged In: YES user_id=929 sorry, that was wrong. ---------------------------------------------------------------------- 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-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 23:06 Message: Logged In: YES user_id=929 same simple patch on pdftex.web. The suspicion of an "obscure possible bug" was wrong. Sorry for the noise. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-05-27 22:49 Message: Logged In: YES user_id=929 sorry, that was wrong. ---------------------------------------------------------------------- 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-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:49 Message: Logged In: YES user_id=929 sorry, that was wrong. ---------------------------------------------------------------------- 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-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

[ 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

Libpng-1.0.25 and libpng-1.2.17
by Martin Schröder 16 May '07

16 May '07

---------- Forwarded message ---------- From: Glenn Randers-Pehrson <glennrp(a)comcast.net> Date: 15.05.2007 23:05 Subject: [png-mng-implement] Libpng-1.0.25 and libpng-1.2.17 To: png-mng-implement(a)lists.sf.net Cc: png-mng-announce(a)lists.sf.net libpng-1.0.25 and libpng-1.2.17 are available at ftp://ftp.simplesystems.org/pub/png/src and at libpng.sf.net These releases fix a vulnerability in png_handle_tRNS() by which a malformed PNG file can crash a libpng application. The bug has existed since libpng-0.90. The vulnerability is identified as CVE-2007-2445 and CERT VU#684664. Glenn ------------------------------------------------------------------------- Merging the changes was easy; it will be included in 1.40.4. Best Martin

2 3

Pdflatex Bugs with figures
by Heba Soliman 15 May '07

15 May '07

When I use pdflatex with an article that has no figures, it is more than perfect. But when the article has figures there are problems with the resolution and the testing with PDF/A. Please help me I don't know how to fix the resolution of the figures using pdflatex, also how to make it compatible with PDF/A in Acrobat 7.0, it gives me an error "Unknown error (unknown exception)". Thanks, Heba ntg-pdftex-request(a)ntg.nl wrote: > Send ntg-pdftex mailing list submissions to > ntg-pdftex(a)ntg.nl > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ntg.nl/mailman/listinfo/ntg-pdftex > or, via email, send a message with subject or body 'help' to > ntg-pdftex-request(a)ntg.nl > > You can reach the person managing the list at > ntg-pdftex-owner(a)ntg.nl > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ntg-pdftex digest..." > > > Today's Topics: > > 1. [ pdftex-Bugs-796 ] Different behaviour of latex/pdflatex > with word breakups (noreply(a)sarovar.org) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 13 May 2007 16:51:53 +0530 > From: noreply(a)sarovar.org > Subject: [NTG-pdftex] [ pdftex-Bugs-796 ] Different behaviour of > latex/pdflatex with word breakups > To: noreply(a)sarovar.org > Message-ID: <E1HnC9B-0006xr-00(a)sarovar.org> > Content-Type: text/plain; charset=UTF-8 > > 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: 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 > > > ------------------------------ > > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex > > > End of ntg-pdftex Digest, Vol 35, Issue 8 > ***************************************** >

1 0

[ pdftex-Bugs-796 ] Different behaviour of latex/pdflatex with word breakups
by noreply＠sarovar.org 13 May '07

13 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: 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

[ pdftex-Bugs-796 ] Different behaviour of latex/pdflatex with word breakups
by noreply＠sarovar.org 13 May '07

13 May '07

Bugs item #796, was opened at 2007-05-13 13:15 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=796&group_id=106 Category: None Group: None Status: Open Resolution: None 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: Nobody (None) Date: 2007-05-13 13:37 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

[ pdftex-Bugs-796 ] Different behaviour of latex/pdflatex with word breakups
by noreply＠sarovar.org 13 May '07

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

1 0

[ pdftex-Feature Requests-718 ] Request of pdfsync
by noreply＠sarovar.org 10 May '07

10 May '07

Feature Requests item #718, was opened at 2007-01-02 03:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Juan Luis Varona (jlvm) Assigned to: Nobody (None) Summary: Request of pdfsync Initial Comment: The syncronization between the .tex and the .pdf files is veeeeeery useful. It is not necessary to explain it. Now, there are some tools to do it, but they are far of being good enough. For instance, pdfsync makes some work, but it has a lot of problems. Of instance, the output is different with or without pdfsync. I have read in TUGboat that, perhaps in the near future, pdfsync can be integrated en pdftex itself and improved. I request to do it as soon as possible. Yours sincerely, Juan L. Varona jvarona(a)unirioja.es ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-05-10 18:26 Message: Logged In: NO I second that strongly. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106

1 0

[ pdftex-Patches-474 ] Use dynamically linked poppler library instead of xpdf code
by noreply＠sarovar.org 08 May '07

08 May '07

Patches item #474, was opened at 2006-01-30 17:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Postponed >Priority: 6 Submitted By: Frank Küster (frank) Assigned to: Martin Schröder (oneiros) Summary: Use dynamically linked poppler library instead of xpdf code Initial Comment: This has already been applied and tested in Debian and Ubuntu, but we suggest to apply it upstream. There are a few things to do, however, as Martin already pointed out to me in a private mail. I paraphrase the main points: - the pdftex distribution should not ship libpoppler. Instead it should be possible to switch from xpdf to libpoppler using autoconf magic, if libpoppler headers are installed. This needs some coding work - We need a common API for xpdf and poppler. This is the tricky part, because the very reason for poppler's existence is that the xpdf developer, Derek Noonburg, refuses any patches that would lead to a shared library. As Martin said, "for the beginning, a header file with a couple of #ifdef'ed definitions should be enough". I'm going to subscribe to the pdftex devel list soon, but am not yet subscribed currently. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-05-08 18:54 Message: Logged In: YES user_id=421 Just an update: SUSE has also started switching to poppler. My idea is to first add an abstraction layer for xpdf/poppler/... and then add the autofoo stuff. ---------------------------------------------------------------------- Comment By: Frank Küster (frank) Date: 2006-08-14 21:20 Message: Logged In: YES user_id=3360 Hi Martin, this is clearly post-1.40, I agree. I have not worked on any autofoo stuff, and I won't be able to do that soon (instead, I try to integrate pdftex-1.40 into teTeX 3.0 which proved to be non-trivial). Regards, Frank ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-13 22:02 Message: Logged In: YES user_id=421 Frank, have you done any further work on this? I just had a first look at integrating poppler and see a very different use of configure... :-{ Also your diff only patches the sources, but not the autofoo-stuff. What I want is: - a distribution of poppler in src/libs, which can be used instead of xpdf - a way to switch bewteen xpdf and poppler via configure - for poppler to be able to switch between static and dynamic via configure - and finally, a header file abstracting poppler/xpdf would be nice, but is not really needed, as poppler/xpdf are only used by two source files. Best Martin ---------------------------------------------------------------------- Comment By: Frank Küster (frank) Date: 2006-02-13 08:58 Message: Logged In: YES user_id=3360 I agree that this is something to think over and check very well, so better not push it into 1.40. But I'd appreciate if someone could answer my mail to ntg-pdftex regarding the autoconf setup in pdftex, or if you could tell me whom to ask specifically if nobody among the active developers knows about it. See you in Berlin, Frank ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 01:50 Message: Logged In: YES user_id=421 I've attached the patch by Frank from http://www.ntg.nl/pipermail/ntg-pdftex/2006-February/001993.html ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 01:46 Message: Logged In: YES user_id=421 This is too late for 1.40, so I'll postpone it. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=474&group_id=106

1 0