September 2006 - 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