March 2005 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-310 ] \pdfxform doesn't work with box registers > 255. Patch included.
by noreply＠sarovar.org 19 Mar '05

19 Mar '05

Bugs item #310, was opened at 2005-03-19 20:58 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=310&group_id=106 Category: etex Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: \pdfxform doesn't work with box registers > 255. Patch included. Initial Comment: Bug reported by: Date: Sat, 19 Mar 2005 00:54:40 +0100 From: Pawel Jackowski To: pdftex(a)tug.org Subject: [pdftex] \pdfxform256 Sparse array handling from etex was missing in \pdfxform. Bug solved by patch to pdfetex.ch2, see pdfetex.ch2.diff. Please check. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=310&group_id=106

1 0

[ pdftex-Patches-259 ] Expanded png inclusion support
by noreply＠sarovar.org 14 Mar '05

14 Mar '05

Patches item #259, was opened at 2005-01-11 16:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) Summary: Expanded png inclusion support Initial Comment: The attached zip file contains a change file for all pdftex's (to be applied *after* hz.cg) and a completely new writepng.c ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2005-03-14 12:03 Message: Logged In: YES user_id=1608 changes as agreed at Pont-a-Mousson: -\pdfoptionimageforcegray removed -\pdfoptionimageapplygamma is now 0 or 1 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-03 17:00 Message: Logged In: YES user_id=1608 Bugfixes in 16-bit color depth mode (needs an 8-bit alpha channel) and corrected PNG transformation discovery for gray conversion. This is a final version for now, it should be added to a pdftex beta to allow 'in the wild' testing. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-01 13:38 Message: Logged In: YES user_id=1608 This update fixes the \pdfoptionimageforcegray bugs discovered by Hartmut. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 17:27 Message: Logged In: YES user_id=1608 Sorry, I forgot the 16-bit color code in the previous version ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 16:38 Message: Logged In: YES user_id=1608 This new version incorporates the code from Hartmut's speed patch. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106

1 0

note durign talk thanh
by Hans Hagen 08 Mar '05

08 Mar '05

concerning map entries needed for hz when using dvi / dvips: why not write the map lines needed to a file "pdftex-hz.map" when in dvi mode this saves the user to figure out map lines Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

1 0

[ pdftex-Bugs-306 ] cmap: unicode ???? is mapped to multiple glyphs
by noreply＠sarovar.org 05 Mar '05

05 Mar '05

Bugs item #306, was opened at 2005-03-05 17:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=306&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Peter Dyballa (ballapete) Assigned to: Hartmut Henkel (hhenkel) Summary: cmap: unicode ???? is mapped to multiple glyphs Initial Comment: I created symlinks from the Lucida fonts that come with Java runtime and I created from them TFM files with ttf2tfm version 1.5, and also a map file fragment and FD files. When I access LucidaSans-Oblique pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) reports this: Error: pdflatex (file /usr/local/teTeX/share/texmf.local/fonts/truetype/ lucida/llsro8a.ttf): cmap: unicode 2010 is mapped to multiple glyphs ==> Fatal error occurred, the output PDF file is not finished! U+2010 is HYPHEN ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=306&group_id=106

1 0

[ pdftex-Patches-259 ] Expanded png inclusion support
by noreply＠sarovar.org 03 Mar '05

03 Mar '05

Patches item #259, was opened at 2005-01-11 16:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) Summary: Expanded png inclusion support Initial Comment: The attached zip file contains a change file for all pdftex's (to be applied *after* hz.cg) and a completely new writepng.c ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2005-03-03 17:00 Message: Logged In: YES user_id=1608 Bugfixes in 16-bit color depth mode (needs an 8-bit alpha channel) and corrected PNG transformation discovery for gray conversion. This is a final version for now, it should be added to a pdftex beta to allow 'in the wild' testing. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-01 13:38 Message: Logged In: YES user_id=1608 This update fixes the \pdfoptionimageforcegray bugs discovered by Hartmut. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 17:27 Message: Logged In: YES user_id=1608 Sorry, I forgot the 16-bit color code in the previous version ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-02-28 16:38 Message: Logged In: YES user_id=1608 This new version incorporates the code from Hartmut's speed patch. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106

1 0

[ pdftex-Bugs-303 ] bug in paper metrics?
by noreply＠sarovar.org 03 Mar '05

03 Mar '05

Bugs item #303, was opened at 2005-03-02 13:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=303&group_id=106 Category: None >Group: v1.21a >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Wolfgang Glitzner (wolfgang_gg) Assigned to: Nobody (None) Summary: bug in paper metrics? Initial Comment: Hello there, Texies. Is there a bug in the paper metrics of pdftex or in an involved package? Or just only in the acrobat reader? I produce a pdf doc with pdftex. In particular I use \documentclass[twoside,a5paper]{book} . . . \setlength{\topmargin}{-2.04mm} \setlength{\textheight}{140.15mm} \setlength{\textwidth}{99.1mm} \setlength{\oddsidemargin}{-8.88mm} \setlength{\evensidemargin}{7.63mm} . . . The Check produces: 1) a dump of \the\paperwidth in the logfile gives 421.10078pt, which is 147.999999999mm. 2) the document properties in the acrobat reader displays 148 x 210 mm 3) invoking printing on my canon i450 opens a window in which the field preview tells Paper: 209.97 x 296.7 mm (I have DINA4 mounted, so far, so good) Document: 147.8 x 209.9 mm 4) DINA5 has exactly 210.22 x 148.65 mm 5) DINA4 has exactly 297.30 x 210.22 mm What width my document really has? 148mm or 147,8mm or 148,65mm ?? There is physically only one! And what I assumed and need is a width of 148,65mm. How to apply? Moreover, gluing 2 pages of my doc together with the pdfpages package works fine. 2 DINA5 onto 1 DINA4. In particular I use \documentclass[twoside,a4paper]{book} However, because a DINA5-page misses approx. 0.65mm, some additional adaption is necessary. However, pdfpages applies a parameter for that action. good luck. The Check produces: 1) a dump of \the\paperheight in the logfile gives 421.10078pt, which is 147.999999999mm. 2) the document properties in the acrobat reader displays 297 x 210mm 3) invoking printing on my canon i450 opens a window in which the field preview tells Paper 209.9 x 296.7mm Document 296.7 x 209.9mm General question: IS THE PAPER-metric FOR DINA5 AND DINA4 CORRECT IN THE APPROPRIATE PACKAGE? Regards Wolfgang Glitzner(a)gmx.de n.b. 1a) A logged metric of pdfpages compilation which keeps the DINA5 is: 421.10124pt x 597.50829pt which is 148.00015991mm x 210.0001462mm. 1b) A logged metric of pdfpages compilation which keeps the DINA4 is: 597.50787pt x 845.04684pt which is 209.9999986mm x 296.9999963mm 2) Some conversions: 72,27 point (amerikanische) sind 1 inch -- exakt! 1 inch sind 25,4 mm -- exakt! 72,27 point/ 25,4 mm = 2,845 point/mm oder 0,3513 mm/point. dots sind nicht points und schon gar nicht pixel. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2005-03-02 14:46 Message: Logged In: YES user_id=421 \usepackage{geometry} ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-02 14:39 Message: Logged In: YES user_id=1608 This is a 'bug' in article.cls, not pdftex. I suggest closing this tracker item. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=303&group_id=106

3 3

Re: [NTG-pdftex] pdfetex banner
by Akira Kakuto 03 Mar '05

03 Mar '05

> > I recompiled pdfetex from p4 source.development, but even NEWS and > > README say about ver. 1.21a, the banner still shows > > > > ./pdfetex --version > > pdfeTeX 3.141592-1.20a-2.2 (Web2C 7.5.3) > > kpathsea version 3.5.3 > > the file pdftex.version is missing from pdftexdir (teTeX-3.0 has it, it > just contains a "1.21a"). pdftex.version is automatically recreated if pdftex.ch is changed. If not, check the Makefile. Best regards, Akira

1 0

pdfetex banner
by Staszek Wawrykiewicz 02 Mar '05

02 Mar '05

I recompiled pdfetex from p4 source.development, but even NEWS and README say about ver. 1.21a, the banner still shows ./pdfetex --version pdfeTeX 3.141592-1.20a-2.2 (Web2C 7.5.3) kpathsea version 3.5.3 -- Staszek Wawrykiewicz StaW(a)gust.org.pl

2 2

[ pdftex-Bugs-303 ] bug in paper metrics?
by noreply＠sarovar.org 02 Mar '05

02 Mar '05

Bugs item #303, was opened at 2005-03-02 13:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=303&group_id=106 Category: None Group: v1.21a Status: Closed Resolution: Rejected Priority: 5 Submitted By: Wolfgang Glitzner (wolfgang_gg) Assigned to: Nobody (None) Summary: bug in paper metrics? Initial Comment: Hello there, Texies. Is there a bug in the paper metrics of pdftex or in an involved package? Or just only in the acrobat reader? I produce a pdf doc with pdftex. In particular I use \documentclass[twoside,a5paper]{book} . . . \setlength{\topmargin}{-2.04mm} \setlength{\textheight}{140.15mm} \setlength{\textwidth}{99.1mm} \setlength{\oddsidemargin}{-8.88mm} \setlength{\evensidemargin}{7.63mm} . . . The Check produces: 1) a dump of \the\paperwidth in the logfile gives 421.10078pt, which is 147.999999999mm. 2) the document properties in the acrobat reader displays 148 x 210 mm 3) invoking printing on my canon i450 opens a window in which the field preview tells Paper: 209.97 x 296.7 mm (I have DINA4 mounted, so far, so good) Document: 147.8 x 209.9 mm 4) DINA5 has exactly 210.22 x 148.65 mm 5) DINA4 has exactly 297.30 x 210.22 mm What width my document really has? 148mm or 147,8mm or 148,65mm ?? There is physically only one! And what I assumed and need is a width of 148,65mm. How to apply? Moreover, gluing 2 pages of my doc together with the pdfpages package works fine. 2 DINA5 onto 1 DINA4. In particular I use \documentclass[twoside,a4paper]{book} However, because a DINA5-page misses approx. 0.65mm, some additional adaption is necessary. However, pdfpages applies a parameter for that action. good luck. The Check produces: 1) a dump of \the\paperheight in the logfile gives 421.10078pt, which is 147.999999999mm. 2) the document properties in the acrobat reader displays 297 x 210mm 3) invoking printing on my canon i450 opens a window in which the field preview tells Paper 209.9 x 296.7mm Document 296.7 x 209.9mm General question: IS THE PAPER-metric FOR DINA5 AND DINA4 CORRECT IN THE APPROPRIATE PACKAGE? Regards Wolfgang Glitzner(a)gmx.de n.b. 1a) A logged metric of pdfpages compilation which keeps the DINA5 is: 421.10124pt x 597.50829pt which is 148.00015991mm x 210.0001462mm. 1b) A logged metric of pdfpages compilation which keeps the DINA4 is: 597.50787pt x 845.04684pt which is 209.9999986mm x 296.9999963mm 2) Some conversions: 72,27 point (amerikanische) sind 1 inch -- exakt! 1 inch sind 25,4 mm -- exakt! 72,27 point/ 25,4 mm = 2,845 point/mm oder 0,3513 mm/point. dots sind nicht points und schon gar nicht pixel. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2005-03-02 22:15 Message: Logged In: YES user_id=1276 \documentclass[a5paper]{article} \usepackage{hyperref} %\pdfdecimaldigits=9 \begin{document} \typeout{paperwidth: \the\paperwidth} \typeout{paperheight: \the\paperheight} \typeout{pdfpagewidth: \the\pdfpagewidth} \typeout{pdfpageheight: \the\pdfpageheight} \null \end{document} http://www.cl.cam.ac.uk/~mgk25/iso-paper.html: DIN A4: 148mm x 210mm = 421.10078740157pt x 597.50787401575pt = 419.52755905512bp x 595.27559055118bp article.cls: \DeclareOption{a5paper} {\setlength\paperheight {210mm}% \setlength\paperwidth {148mm}} log file: paperwidth: 421.10078pt paperheight: 597.50787pt pdfpagewidth: 421.10078pt pdfpageheight: 597.50787pt PDF /MediaBox: /MediaBox [0 0 419.528 595.276] pdfinfo: Page size: 419.528 x 595.276 pts AR5/Linux: 148 x 210 mm 419.5 x 595.3 pt (points in AR are bp in TeX!) Conclusion: * All values are correct (modulo rounding errors). * No bug. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-02 14:46 Message: Logged In: YES user_id=421 \usepackage{geometry} ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-02 14:39 Message: Logged In: YES user_id=1608 This is a 'bug' in article.cls, not pdftex. I suggest closing this tracker item. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=303&group_id=106

1 0

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 02 Mar '05

02 Mar '05

Bugs item #304, was opened at 2005-03-02 17:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0