- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-609 ] Pdf "convert" primitives bug
by noreply＠sarovar.org 28 Sep '06

28 Sep '06

Bugs item #609, was opened at 2006-09-28 18:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106 >Category: Primitives >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) >Assigned to: Taco Hoekwater (taco) >Summary: Pdf "convert" primitives bug Initial Comment: The problem: When tex calls `conv_toks()' to execute `convert' commands, a string may already be being built. A call to scan_toks (pdf_scan_ext_toks) at that moment will incorporate that partial string to the argument of the `convert' primitive, and erase it from the output. Example code: \message{\pdfmdfivesum{knuth}} \input knuth\pdfmdfivesum{} \bye Affected primitives: \pdfescapestring \pdfescapename \pdfescapehex \pdfunescapehex \pdffilemoddate \pdffilesize \pdffiledump \pdfmdfivesum \pdfstrcmp The needed fix: Somewhen before calling scan_pdf_ext_toks, you have to store the partial string as a true tex string, then its `partialness' has to be restored sometime later before leaving conv_toks(). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-09-28 18:52 Message: Logged In: YES user_id=1608 sorry, it is a bug, of course ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106

1 0

Pdf "convert" primitives bug
by Taco Hoekwater 28 Sep '06

28 Sep '06

Hi, While working on luatex's \directlua, I ran into a rather interesting bug that affects a number of pdftex primitives as well. Because these do not all have the same author and the needed fix is not identical for all, I thought it easier to write an email message than to try to create a patch myself. The problem: When tex calls `conv_toks()' to execute `convert' commands, a string may already be being built. A call to scan_toks (pdf_scan_ext_toks) at that moment will incorporate that partial string to the argument of the `convert' primitive, and erase it from the output. Example code: \message{\pdfmdfivesum{knuth}} \input knuth\pdfmdfivesum{} \bye Affected primitives: \pdfescapestring \pdfescapename \pdfescapehex \pdfunescapehex \pdffilemoddate \pdffilesize \pdffiledump \pdfmdfivesum \pdfstrcmp The needed fix: Somewhen before calling scan_pdf_ext_toks, you have to store the partial string as a true tex string, then its `partialness' has to be restored sometime later before leaving conv_toks(). Greetings, Taco

3 4

[ pdftex-Bugs-609 ] Pdf "convert" primitives bug
by noreply＠sarovar.org 28 Sep '06

28 Sep '06

Bugs item #609, was opened at 2006-09-28 18:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) >Assigned to: Nobody (None) >Summary: Pdf "convert" primitives bug Initial Comment: The problem: When tex calls `conv_toks()' to execute `convert' commands, a string may already be being built. A call to scan_toks (pdf_scan_ext_toks) at that moment will incorporate that partial string to the argument of the `convert' primitive, and erase it from the output. Example code: \message{\pdfmdfivesum{knuth}} \input knuth\pdfmdfivesum{} \bye Affected primitives: \pdfescapestring \pdfescapename \pdfescapehex \pdfunescapehex \pdffilemoddate \pdffilesize \pdffiledump \pdfmdfivesum \pdfstrcmp The needed fix: Somewhen before calling scan_pdf_ext_toks, you have to store the partial string as a true tex string, then its `partialness' has to be restored sometime later before leaving conv_toks(). ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2006-09-28 18:52 Message: Logged In: YES user_id=1608 sorry, it is a bug, of course ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106

1 0

[ pdftex-Feature Requests-609 ] Pdf "convert" primitives bug
by noreply＠sarovar.org 28 Sep '06

28 Sep '06

Feature Requests item #609, was opened at 2006-09-28 18:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=609&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Taco Hoekwater (taco) Summary: Pdf "convert" primitives bug Initial Comment: The problem: When tex calls `conv_toks()' to execute `convert' commands, a string may already be being built. A call to scan_toks (pdf_scan_ext_toks) at that moment will incorporate that partial string to the argument of the `convert' primitive, and erase it from the output. Example code: \message{\pdfmdfivesum{knuth}} \input knuth\pdfmdfivesum{} \bye Affected primitives: \pdfescapestring \pdfescapename \pdfescapehex \pdfunescapehex \pdffilemoddate \pdffilesize \pdffiledump \pdfmdfivesum \pdfstrcmp The needed fix: Somewhen before calling scan_pdf_ext_toks, you have to store the partial string as a true tex string, then its `partialness' has to be restored sometime later before leaving conv_toks(). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=609&group_id=106

1 0

[ pdftex-Bugs-608 ] baseurl=./ of hyperref ignored
by noreply＠sarovar.org 27 Sep '06

27 Sep '06

Bugs item #608, was opened at 2006-09-27 16:55 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=608&group_id=106 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Jan Schween (janschween) Assigned to: Nobody (None) Summary: baseurl=./ of hyperref ignored Initial Comment: I try to make a \href to a file which is located relative to the PDF document. When loading the hyperref package i use the option baseurl=./ to indicate the actual location of the PDF document: \usepackage[ pdftex , baseurl=./ ]{hyperref} Inside the document i make a reference to an external file: \href{movies/map.m1v} % link to movie {movie {\tt map.m1v}.} % text to appear The examples A1 and A2 on http://www.meteo.physik.uni-muenchen.de/~hase/banner/texte/movie_example/ show the result. Look at the links in the caption of figure 1. A2 was created with pdfTeX : The link is expanded into 'movies/map.m1v' and does not work. If you download the pdf to your local machine and open it, the link will be expanded into 'movies/map.m1v' Accordingly the baseurl=./ is ignored. A1 was created with dvipdfm : The link is expanded into 'http://www.../movies/map.m1v' If you download the pdf to your local machine and open it the link will be expanded into 'file:///<localdir>/movies/map.m1v' that is what i would (naiveley) expect. Since dvipdfm is capable to produce a meaningful expansion of baseurl=./ the problem lies not within hyperef and not within the capabilites of PDF. (I sent this question yesterday also to pdtftex(a)tug.org - sorry if you read this twice) - Jan - ---------------------------------------------------------------------- >Comment By: Jan Schween (janschween) Date: 2006-09-27 19:49 Message: Logged In: YES user_id=3905 pdfTeX can be forced to omit the /URI<</Base(...)>> statement by setting the hyperref options: \hypersetup{baseurl={}} \hypersetup{linkfileprefix={}} - jan - ---------------------------------------------------------------------- Comment By: Jan Schween (janschween) Date: 2006-09-27 19:02 Message: Logged In: YES user_id=3905 I am aware that hyperref is independent of pdfTex. I allready mentioned: > Since dvipdfm is capable to produce a meaningful > expansion of baseurl=./ the problem lies not within > hyperef and not within the capabilites of PDF. Ommiting the pdftex option for hyperef does not change the behaviour. (The only remaining difference between using pdftex and dvipdfm is the pdfTex option of hyperref) It must be a problem in pdfTeX. ... or in PDF: if baseurl=./ is set the following PDF-output is produced: pdfTeX: /URI<</Base(./)>> dvipdfm: there is NO /URI<</Base(...)>> statement in the pdf ! Test: If you just erase the /URI<</Base(./)>> statement in the pdfTeX output then adobe-reader expands the link as you would expect it ! (see A3 on the www-page) Remains the question: Is this strange behaviour of adobe-reader, or is this documented in the PDF-standard ? - Jan - ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-27 17:35 Message: Logged In: YES user_id=421 Sorry, unless you can demonstrate that this is a bug in pdfTeX, I will assume that it is a problem of hyperref, which we don't maintain. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=608&group_id=106

1 0

[ pdftex-Bugs-608 ] baseurl=./ of hyperref ignored
by noreply＠sarovar.org 27 Sep '06

27 Sep '06

Bugs item #608, was opened at 2006-09-27 16:55 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=608&group_id=106 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Jan Schween (janschween) Assigned to: Nobody (None) Summary: baseurl=./ of hyperref ignored Initial Comment: I try to make a \href to a file which is located relative to the PDF document. When loading the hyperref package i use the option baseurl=./ to indicate the actual location of the PDF document: \usepackage[ pdftex , baseurl=./ ]{hyperref} Inside the document i make a reference to an external file: \href{movies/map.m1v} % link to movie {movie {\tt map.m1v}.} % text to appear The examples A1 and A2 on http://www.meteo.physik.uni-muenchen.de/~hase/banner/texte/movie_example/ show the result. Look at the links in the caption of figure 1. A2 was created with pdfTeX : The link is expanded into 'movies/map.m1v' and does not work. If you download the pdf to your local machine and open it, the link will be expanded into 'movies/map.m1v' Accordingly the baseurl=./ is ignored. A1 was created with dvipdfm : The link is expanded into 'http://www.../movies/map.m1v' If you download the pdf to your local machine and open it the link will be expanded into 'file:///<localdir>/movies/map.m1v' that is what i would (naiveley) expect. Since dvipdfm is capable to produce a meaningful expansion of baseurl=./ the problem lies not within hyperef and not within the capabilites of PDF. (I sent this question yesterday also to pdtftex(a)tug.org - sorry if you read this twice) - Jan - ---------------------------------------------------------------------- >Comment By: Jan Schween (janschween) Date: 2006-09-27 19:02 Message: Logged In: YES user_id=3905 I am aware that hyperref is independent of pdfTex. I allready mentioned: > Since dvipdfm is capable to produce a meaningful > expansion of baseurl=./ the problem lies not within > hyperef and not within the capabilites of PDF. Ommiting the pdftex option for hyperef does not change the behaviour. (The only remaining difference between using pdftex and dvipdfm is the pdfTex option of hyperref) It must be a problem in pdfTeX. ... or in PDF: if baseurl=./ is set the following PDF-output is produced: pdfTeX: /URI<</Base(./)>> dvipdfm: there is NO /URI<</Base(...)>> statement in the pdf ! Test: If you just erase the /URI<</Base(./)>> statement in the pdfTeX output then adobe-reader expands the link as you would expect it ! (see A3 on the www-page) Remains the question: Is this strange behaviour of adobe-reader, or is this documented in the PDF-standard ? - Jan - ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-27 17:35 Message: Logged In: YES user_id=421 Sorry, unless you can demonstrate that this is a bug in pdfTeX, I will assume that it is a problem of hyperref, which we don't maintain. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=608&group_id=106

1 0

[ pdftex-Bugs-608 ] baseurl=./ of hyperref ignored
by noreply＠sarovar.org 27 Sep '06

27 Sep '06

Bugs item #608, was opened at 2006-09-27 16:55 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=608&group_id=106 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jan Schween (janschween) Assigned to: Nobody (None) Summary: baseurl=./ of hyperref ignored Initial Comment: I try to make a \href to a file which is located relative to the PDF document. When loading the hyperref package i use the option baseurl=./ to indicate the actual location of the PDF document: \usepackage[ pdftex , baseurl=./ ]{hyperref} Inside the document i make a reference to an external file: \href{movies/map.m1v} % link to movie {movie {\tt map.m1v}.} % text to appear The examples A1 and A2 on http://www.meteo.physik.uni-muenchen.de/~hase/banner/texte/movie_example/ show the result. Look at the links in the caption of figure 1. A2 was created with pdfTeX : The link is expanded into 'movies/map.m1v' and does not work. If you download the pdf to your local machine and open it, the link will be expanded into 'movies/map.m1v' Accordingly the baseurl=./ is ignored. A1 was created with dvipdfm : The link is expanded into 'http://www.../movies/map.m1v' If you download the pdf to your local machine and open it the link will be expanded into 'file:///<localdir>/movies/map.m1v' that is what i would (naiveley) expect. Since dvipdfm is capable to produce a meaningful expansion of baseurl=./ the problem lies not within hyperef and not within the capabilites of PDF. (I sent this question yesterday also to pdtftex(a)tug.org - sorry if you read this twice) - Jan - ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-09-27 17:35 Message: Logged In: YES user_id=421 Sorry, unless you can demonstrate that this is a bug in pdfTeX, I will assume that it is a problem of hyperref, which we don't maintain. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=608&group_id=106

1 0

[ pdftex-Bugs-608 ] baseurl=./ of hyperref ignored
by noreply＠sarovar.org 27 Sep '06

27 Sep '06

Bugs item #608, was opened at 2006-09-27 16:55 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=608&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Schween (janschween) Assigned to: Nobody (None) Summary: baseurl=./ of hyperref ignored Initial Comment: I try to make a \href to a file which is located relative to the PDF document. When loading the hyperref package i use the option baseurl=./ to indicate the actual location of the PDF document: \usepackage[ pdftex , baseurl=./ ]{hyperref} Inside the document i make a reference to an external file: \href{movies/map.m1v} % link to movie {movie {\tt map.m1v}.} % text to appear The examples A1 and A2 on http://www.meteo.physik.uni-muenchen.de/~hase/banner/texte/movie_example/ show the result. Look at the links in the caption of figure 1. A2 was created with pdfTeX : The link is expanded into 'movies/map.m1v' and does not work. If you download the pdf to your local machine and open it, the link will be expanded into 'movies/map.m1v' Accordingly the baseurl=./ is ignored. A1 was created with dvipdfm : The link is expanded into 'http://www.../movies/map.m1v' If you download the pdf to your local machine and open it the link will be expanded into 'file:///<localdir>/movies/map.m1v' that is what i would (naiveley) expect. Since dvipdfm is capable to produce a meaningful expansion of baseurl=./ the problem lies not within hyperef and not within the capabilites of PDF. (I sent this question yesterday also to pdtftex(a)tug.org - sorry if you read this twice) - Jan - ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=608&group_id=106

1 0

Spurious output to stderr
by Reinhard Kotucha 23 Sep '06

23 Sep '06

Hi, whenever I use \pdfximage the filename and "\n" is printed to stderr. Everything looks as expected when I say "pdftex somefile 2>/dev/null". It seems that one of the developers inserted some code for debugging and forgot to remove it. Has this been fixed already? I'm talking about This is pdfeTeXk, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5) 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. ----------------------------------------------------------------------------

4 3

[ pdftex-Bugs-606 ] Forbidden ... while scanning ???
by noreply＠sarovar.org 21 Sep '06

21 Sep '06

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