- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-611 ] Bug of pdftex beta upon reading some truetype
by noreply＠sarovar.org 30 Sep '06

30 Sep '06

Bugs item #611, was opened at 2006-09-30 02:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=611&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Dohyun Kim (nomos) Assigned to: The Thanh Han (hanthethanh) Summary: Bug of pdftex beta upon reading some truetype Initial Comment: I have recently installed pdftex beta on my Linux box. But I am puzzled by a strange behavior of newly installed pdftex. For your test, I've put a minimal tarball (1.6M) to a server: http://210.94.201.157/~nomos/KTUG/truetypetest.tar.gz On my i686 Linux machine, compiling the following file (which is included in the tarball above) with pdftex beta version 20060906 fails with Segmentation Fault. ==================== %\pdfmapline{+oungtb4e <oungtb4e.enc <UnDotumBold.ttf} %%% it works. \pdfmapline{+oungtb@Unicode@ <UnDotumBold.ttf} %%% it segfaults. \font\mytt=oungtb4e\relax \mytt \char0 \char1 \bye ==================== PDFTeX beta 20060928, the most recent version at the time of this reporting, crashes too. Please inspect the problem. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-09-30 19:30 Message: Logged In: YES user_id=421 Just FTR: I've tried to attach the file from nomos to this bug, but this fails silently; probably some size limit. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=611&group_id=106

1 0

[ pdftex-Bugs-611 ] Bug of pdftex beta upon reading some truetype
by noreply＠sarovar.org 30 Sep '06

30 Sep '06

Bugs item #611, was opened at 2006-09-30 02:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=611&group_id=106 >Category: Fonts >Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Dohyun Kim (nomos) >Assigned to: The Thanh Han (hanthethanh) Summary: Bug of pdftex beta upon reading some truetype Initial Comment: I have recently installed pdftex beta on my Linux box. But I am puzzled by a strange behavior of newly installed pdftex. For your test, I've put a minimal tarball (1.6M) to a server: http://210.94.201.157/~nomos/KTUG/truetypetest.tar.gz On my i686 Linux machine, compiling the following file (which is included in the tarball above) with pdftex beta version 20060906 fails with Segmentation Fault. ==================== %\pdfmapline{+oungtb4e <oungtb4e.enc <UnDotumBold.ttf} %%% it works. \pdfmapline{+oungtb@Unicode@ <UnDotumBold.ttf} %%% it segfaults. \font\mytt=oungtb4e\relax \mytt \char0 \char1 \bye ==================== PDFTeX beta 20060928, the most recent version at the time of this reporting, crashes too. Please inspect the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=611&group_id=106

1 0

[ pdftex-Patches-462 ] HZ font expansion by text matrix manipulation
by noreply＠sarovar.org 30 Sep '06

30 Sep '06

Patches item #462, was opened at 2005-12-23 22:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106 Category: Positioning Group: v1.40.0 Status: Open Resolution: Later Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: HZ font expansion by text matrix manipulation Initial Comment: Use textmatrix Tm instead of /FontMatrix for font expansion. Then a font file will be embedded only once for all expansion factors. Gives smaller PDF files. Works then also for non-embedded fonts. TrueType not tried yet. Rough patch only, incomplete, work in progress, no warranty, not for production. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-09-30 14:22 Message: Logged In: YES user_id=2217 It's great to have this included! However, pdftex is now a bit too keen on autoexpanding -- it does so, even if `autoexpand' is not specified. Although the pre-created metrics are read, the physical font (pfb resp. pk) is ignored. As has been discussed re: bug 304, *not* using autoexpansion gives better results for MM (and MF) fonts, since the fonts are not stretched blindly but stroke widths are adjusted etc. Compare the output of the test file from bugs/304 compiled with an old pdftex and with 20060928. With the latter, the strokes are slightly heavier. Same here (with an existing file cmr10+100.mf): \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr =cmr10 \cmr \pdffontexpand\cmr 100 0 100 %autoexpand Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 18:41 Message: Logged In: YES user_id=421 The last word from Hartmut was that it's not ready yet and he'd be working on an improved version. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-02-13 18:05 Message: Logged In: YES user_id=2217 Will this make it into 1.40? I would love to see it included. I've tested it a bit and did not find any problems (I'm also using it for the pre-built microtype documentation on CTAN). Regards, Robert ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106

1 0

[ pdftex-Bugs-611 ] Bug of pdftex beta upon reading some truetype
by noreply＠sarovar.org 30 Sep '06

30 Sep '06

Bugs item #611, was opened at 2006-09-30 09:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=611&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dohyun Kim (nomos) Assigned to: Nobody (None) Summary: Bug of pdftex beta upon reading some truetype Initial Comment: I have recently installed pdftex beta on my Linux box. But I am puzzled by a strange behavior of newly installed pdftex. For your test, I've put a minimal tarball (1.6M) to a server: http://210.94.201.157/~nomos/KTUG/truetypetest.tar.gz On my i686 Linux machine, compiling the following file (which is included in the tarball above) with pdftex beta version 20060906 fails with Segmentation Fault. ==================== %\pdfmapline{+oungtb4e <oungtb4e.enc <UnDotumBold.ttf} %%% it works. \pdfmapline{+oungtb@Unicode@ <UnDotumBold.ttf} %%% it segfaults. \font\mytt=oungtb4e\relax \mytt \char0 \char1 \bye ==================== PDFTeX beta 20060928, the most recent version at the time of this reporting, crashes too. Please inspect the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=611&group_id=106

1 0

[ pdftex-Bugs-605 ] \pdfescapestring + \pdfescapename are broken in beta-20060906
by noreply＠sarovar.org 28 Sep '06

28 Sep '06

Bugs item #605, was opened at 2006-09-13 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=605&group_id=106 Category: None Group: v1.40.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: Martin Schröder (oneiros) Summary: \pdfescapestring + \pdfescapename are broken in beta-20060906 Initial Comment: The last char of escaped characters will always be ^^0: \def\text{P^^D (F)} \message{\pdfescapestring{\text}} \message{\pdfescapename {\text}} \bye % log output is: % P\00^^@\04^^@\(F\) % P#0^^@#2^^@#2^^@F#2^^@ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-14 14:36 Message: Logged In: YES user_id=421 Found and fixed it. The snprintfs in escapestring and escapename were wrong. I'll check the other printf -> nprintf changes. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=605&group_id=106

1 0

[ 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

Since "An embedded message was scrubbed...", I repeat it inline !
by Philip TAYLOR 20 Sep '06

20 Sep '06

Reinhard Kotucha wrote: > Nobody forces you to use double quotes. TeX still works as it did 20 > years ago. Why do we need a TeX parser to process filenames? We don't. But we do need to know how TeX operates, and in this context it is a many-layered operation. Scanning, parsing and tokenization all take place, as do execution and expansion, and with (I think) the sole exception of \lowercase and \uppercase (which are /horribly/ anomalous), each phase is quite distinct from the other. What you are suggesting (if I understand you correctly) would make \input even more anomalous than \...case, and that would (I believe) be a very retrograde step in the evolution of (derivates of) TeX. > What is the advantage if files are inaccessible? They are not. It is not impossible (or even outrageously difficult) to construct a control sequence that will expand to "foo<space><space>bar"; what /cannot/ be achieved is for "foo<space><space>bar" to appear in the input stream with normal catcodes and for the two spaces to still be there after the scanner has performed its function. ** Phil.

1 0

Re: [NTG-pdftex] Passing Underscore
by Philip TAYLOR 20 Sep '06

20 Sep '06

1 0

Re: [NTG-pdftex] [texhax] Passing Underscore
by Reinhard Kotucha 20 Sep '06

20 Sep '06

>>>>> "John" == John R Culleton <john(a)wexfordpress.com> writes: > Very interesting, although I usually rename all those (IMO silly) > Windows type filenames with spaces in them. I do so as well. It's more a GUI than a Windows problem. > Now what about two spaces in a row? Just curious. I tried and it seems that there is a severe bug in pdftex. \input "foo bar" loads the file "foo bar.tex" which is certainly not desired behavior. I send this mail to the pdftex developers list as well. Maybe this problem had been fixed already, I'm using "This is pdfeTeXk, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5)" Regards, and thanks for the hint, 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. ----------------------------------------------------------------------------

5 6

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

17 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: None Priority: 5 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: 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

2 1

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

17 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: None Priority: 5 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-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-606 ] Forbidden ... while scanning ???
by noreply＠sarovar.org 17 Sep '06

17 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: None Priority: 5 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-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

about TrueType Font can't be embedded by use the pdftex
by zhaohs 17 Sep '06

17 Sep '06

Dear Michael, You say: ########################################## Otftotfm generates map lines that tell pdftex to embed the TTF directly (cool!). Unfortunately, pdftex does not like the Version 3.0 OS/2 table included in OpenType TTFs (boo!), so I hacked the font to change the OS/2 version number to 2.0. Alternately, one could recompile pdftex, after changing line 1026 of writettf.c to: if (version != 0x0000 && version != 0x0001 && version != 0x0002 && version != 0x0003) ================================================= Martin, can you please include this patch into the next release? Thanks. ########################################### But I can't compile the pdftex 1.30.6 from source, when I use ./build.sh in the directory pdftex-1.30.6 , the error message are: ############################# cat: ../src/Makefile.in: No such file or directory ./build.sh: line 49: cd: texk/web2c/web2c: 没有那个文件或目录 make: Nothing to be done for `all'. ./build.sh: line 50: cd: texk/web2c: 没有那个文件或目录 make: *** 没有规则可以创建目标“../kpathsea/libkpathsea.la”。停止。 ################################# Why? In addition, how can I hack the font to change the OS/2 version number to 2.0. as you hve done? Best, Hongsheng. __________________________________________________ �Ͽ�ע��Ż��? http://cn.mail.yahoo.com

2 1

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

16 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: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) 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. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=606&group_id=106

1 0

[ pdftex-Patches-427 ] Character positioning patch
by noreply＠sarovar.org 16 Sep '06

16 Sep '06

Patches item #427, was opened at 2005-09-11 12:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106 Category: Positioning Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hans Hagen (hagen) Summary: Character positioning patch Initial Comment: Experimental patch increases resolution of /Widths array by 1 fractional digit, makes corrections of type ")-1(" and ")1(" in the TJ array happen much less often, particularily for CM fonts. Gives e. g. 1 % PDF file size shrink for pdfetex web sources compiled into PDF. Rough patch only, not for production. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-16 20:09 Message: Logged In: YES user_id=929 this is in pdftex 1.40.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:06 Message: Logged In: YES user_id=929 Patch extended: Now pdf_set_origin has (h, v) parameters, simplifies pdf_begin_text procedure. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 00:25 Message: Logged In: YES user_id=929 Removed pdf_first_space_corr variable, as it seems that it was defunct anyway: There was no pdf_end_string procedure call (only place where something is done with pdf_first_space_corr), where afterwards the pdf_h variable (then modified by pdf_first_space_corr) would actually be used. E. g. pdf_moveto uses pdf_last_h instead, and after pdf_end_text there is anyway a pdf_set_origin call. And pdf_begin_string gets simpler. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-03 01:16 Message: Logged In: YES user_id=929 patch updated: now the TJ array building in procedure pdf_begin_string is simplified/tidied up. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106

1 0

[ pdftex-Bugs-605 ] \pdfescapestring + \pdfescapename are broken in beta-20060906
by noreply＠sarovar.org 14 Sep '06

14 Sep '06

Bugs item #605, was opened at 2006-09-13 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=605&group_id=106 Category: None Group: v1.40.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) >Assigned to: Martin Schröder (oneiros) Summary: \pdfescapestring + \pdfescapename are broken in beta-20060906 Initial Comment: The last char of escaped characters will always be ^^0: \def\text{P^^D (F)} \message{\pdfescapestring{\text}} \message{\pdfescapename {\text}} \bye % log output is: % P\00^^@\04^^@\(F\) % P#0^^@#2^^@#2^^@F#2^^@ ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-09-14 14:36 Message: Logged In: YES user_id=421 Found and fixed it. The snprintfs in escapestring and escapename were wrong. I'll check the other printf -> nprintf changes. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=605&group_id=106

1 0