- ntg-pdftex - NTG Mailing Lists

[ 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

[ 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: None Status: Open Resolution: None 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: 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-303 ] bug in paper metrics?
by noreply＠sarovar.org 02 Mar '05

02 Mar '05

Bugs item #303, was opened at 2005-03-02 12:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=303&group_id=106 Category: None Group: None Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=303&group_id=106

1 0

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

01 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-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

Re: Slow PNG inclusion with pdfLaTeX
by Taco Hoekwater 28 Feb '05

28 Feb '05

Hartmut, I saw this on c.t.t. Shall I attempt a merge of yours and my patches? Taco Hartmut Henkel wrote: > <remolinero(a)hotmail.com> wrote: > > >>I need to put a lot of PNG pictures in a tex document. But including >>PNGs makes pdfLaTeX to hang a few seconds after including each PNG. >>This doen't happens with other file types as JPG, PDF, etc. >> >>Is there a way to ommit this delay? Without converting all PNGs to >>other format? > > > If you compile from source, maybe check > > http://www.circuitwizard.de/pdftex/patch5 > > which should read much faster, if the PNG files are of the right type. The > problem with this rough patch is that it's now getting obsolete as it > doesn't (yet) support new transparency features to come. > > Regards, Hartmut

3 5

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

28 Feb '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-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-Patches-259 ] Expanded png inclusion support
by noreply＠sarovar.org 28 Feb '05

28 Feb '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-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-300 ] "page is rotated 90 degrees" for no reason
by noreply＠sarovar.org 24 Feb '05

24 Feb '05

Bugs item #300, was opened at 2005-02-24 00:15 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=300&group_id=106 Category: PDF inclusion Group: v1.21a Status: Closed Resolution: Invalid Priority: 5 Submitted By: John Denker (jsd) Assigned to: Martin Schröder (oneiros) >Summary: "page is rotated 90 degrees" for no reason Initial Comment: Hi -- I have a good-sized document that uses \includegraphics{} to include about 250 images, each of which was prepared in the same way, converting a .eps file to a .pdf file using epstopdf. Of these, 65 of them end up rotated 90 degrees for no reason. The .log file mentions the fact, saying page is rotated 90 degrees and a glance at the output document confirms this. What is happening? Why is it happening? Why is it not documented? How do I make it stop happening? I have looked at the source to pdflatex without finding anything that fiddles with the "rotate" angle. I have done experiments including changing the \textwidth without finding anything that has any effect. I have no clue why some images are rotated and some are not; it is not a function of image-width or anything simple like that. Putting an explicit [angle=0] directive on the \includegraphics has no effect. I have scrutinized the image files using "identify -verbose" and "pdfinfo" without finding anything that would explain the observed behavior. I have searched the archives of the mailing-list as best I could using the modest search facilities available. I have skimmed the open and closed bugs on the bug-reporting system. I downloaded the latest tetex-texmf distro from ctan to make sure the problem exists in that version. The problem is 100% reproducible. Version info from the head of the .log file is: This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (format=pdflatex 2005.2.23) 23 FEB 2005 23:32 entering extended mode **how.tex (./how.tex LaTeX2e <2003/12/01> Babel <v3.8d> .... If you need the next level of detail, I will have to cobble up a document that demonstrates the problem. (I don't think you want to look at the multi-megabyte example I already have, and it's proprietary anyway.) But for the moment I'm hoping somebody will instantly recognize the problem and know the solution, saving me the trouble of cobbling up a demo document. Please let me know what info you need. ---------------------------------------------------------------------- >Comment By: John Denker (jsd) Date: 2005-02-24 08:58 Message: Logged In: YES user_id=2267 Thanks! The response to my report was very helpful. One slight correction: the solution is not -dPDFSETTINGS=printer but rather -dAutoRotatePages=/None ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-02-24 05:11 Message: Logged In: YES user_id=421 This is not a bug in pdftex, but a (mis)feature of ghostscript (which follows a (mis)feature of Adobe Distiller): Both distillers try to find pages that really should be landscape but are portrait and then set the /Rotate attribute of the page, which pdftex honours. This behaviour of gs can be configured: The parameter is AutoRotatePages; more information is at http://www.cs.wisc.edu/~ghost/doc/cvs/Ps2pdf.htm Try with ps2pdf -dPDFSETTINGS=printer ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=300&group_id=106

1 0

\pdfoptionpdfminorversion
by Reinhard Kotucha 24 Feb '05

24 Feb '05

Hi, I'm wondering whether pdftex complains if I set the variable \pdfoptionpdfminorversion to a very low value and use PDF features which had been introduced in more recent versions of Acrobat. Does pdftex complain in this case? There is a problem with the manual, the file pdftex-a.pdf contains the line "%PDF-1.5" which requires AR6 which is not available for Linux. I doubt that this is necessary here because it doesn't make use of the latest features. So "%PDF-1.4" would be better. Maybe even a lower value could be used. Because many people work on the manual, it makes sense to set \pdfoptionpdfminorversion explicitely in the file. 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. ----------------------------------------------------------------------------

5 9

[ pdftex-Bugs-300 ] "page is rotated 90 degrees" for no reason
by noreply＠sarovar.org 24 Feb '05

24 Feb '05

Bugs item #300, was opened at 2005-02-24 06:15 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=300&group_id=106 Category: PDF inclusion Group: v1.21a >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: John Denker (jsd) Assigned to: Martin Schröder (oneiros) >Summary: "page is rotated 90 degrees" for no reason Initial Comment: Hi -- I have a good-sized document that uses \includegraphics{} to include about 250 images, each of which was prepared in the same way, converting a .eps file to a .pdf file using epstopdf. Of these, 65 of them end up rotated 90 degrees for no reason. The .log file mentions the fact, saying page is rotated 90 degrees and a glance at the output document confirms this. What is happening? Why is it happening? Why is it not documented? How do I make it stop happening? I have looked at the source to pdflatex without finding anything that fiddles with the "rotate" angle. I have done experiments including changing the \textwidth without finding anything that has any effect. I have no clue why some images are rotated and some are not; it is not a function of image-width or anything simple like that. Putting an explicit [angle=0] directive on the \includegraphics has no effect. I have scrutinized the image files using "identify -verbose" and "pdfinfo" without finding anything that would explain the observed behavior. I have searched the archives of the mailing-list as best I could using the modest search facilities available. I have skimmed the open and closed bugs on the bug-reporting system. I downloaded the latest tetex-texmf distro from ctan to make sure the problem exists in that version. The problem is 100% reproducible. Version info from the head of the .log file is: This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (format=pdflatex 2005.2.23) 23 FEB 2005 23:32 entering extended mode **how.tex (./how.tex LaTeX2e <2003/12/01> Babel <v3.8d> .... If you need the next level of detail, I will have to cobble up a document that demonstrates the problem. (I don't think you want to look at the multi-megabyte example I already have, and it's proprietary anyway.) But for the moment I'm hoping somebody will instantly recognize the problem and know the solution, saving me the trouble of cobbling up a demo document. Please let me know what info you need. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2005-02-24 11:11 Message: Logged In: YES user_id=421 This is not a bug in pdftex, but a (mis)feature of ghostscript (which follows a (mis)feature of Adobe Distiller): Both distillers try to find pages that really should be landscape but are portrait and then set the /Rotate attribute of the page, which pdftex honours. This behaviour of gs can be configured: The parameter is AutoRotatePages; more information is at http://www.cs.wisc.edu/~ghost/doc/cvs/Ps2pdf.htm Try with ps2pdf -dPDFSETTINGS=printer ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=300&group_id=106

1 0

[ pdftex-Bugs-300 ] "page is rotated 90 degrees" for no reason
by noreply＠sarovar.org 24 Feb '05

24 Feb '05

Bugs item #300, was opened at 2005-02-24 00:15 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=300&group_id=106 Category: PDF inclusion Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: John Denker (jsd) Assigned to: Martin Schröder (oneiros) Summary: "page is rotated 90 degrees" for no reason Initial Comment: Hi -- I have a good-sized document that uses \includegraphics{} to include about 250 images, each of which was prepared in the same way, converting a .eps file to a .pdf file using epstopdf. Of these, 65 of them end up rotated 90 degrees for no reason. The .log file mentions the fact, saying page is rotated 90 degrees and a glance at the output document confirms this. What is happening? Why is it happening? Why is it not documented? How do I make it stop happening? I have looked at the source to pdflatex without finding anything that fiddles with the "rotate" angle. I have done experiments including changing the \textwidth without finding anything that has any effect. I have no clue why some images are rotated and some are not; it is not a function of image-width or anything simple like that. Putting an explicit [angle=0] directive on the \includegraphics has no effect. I have scrutinized the image files using "identify -verbose" and "pdfinfo" without finding anything that would explain the observed behavior. I have searched the archives of the mailing-list as best I could using the modest search facilities available. I have skimmed the open and closed bugs on the bug-reporting system. I downloaded the latest tetex-texmf distro from ctan to make sure the problem exists in that version. The problem is 100% reproducible. Version info from the head of the .log file is: This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (format=pdflatex 2005.2.23) 23 FEB 2005 23:32 entering extended mode **how.tex (./how.tex LaTeX2e <2003/12/01> Babel <v3.8d> .... If you need the next level of detail, I will have to cobble up a document that demonstrates the problem. (I don't think you want to look at the multi-megabyte example I already have, and it's proprietary anyway.) But for the moment I'm hoping somebody will instantly recognize the problem and know the solution, saving me the trouble of cobbling up a demo document. Please let me know what info you need. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=300&group_id=106

1 0

gmail
by Martin Schröder 21 Feb '05

21 Feb '05

If anybody wants a gmail account: I've got 49 invitations left. :-) Best regards Martin -- Martin Schröder, ms(a)artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de

1 0

[ pdftex-Bugs-292 ] protuding leads to "This can't happen (paragraph)."
by noreply＠sarovar.org 18 Feb '05

18 Feb '05

Bugs item #292, was opened at 2005-02-14 15:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106 Category: hz Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) >Summary: protuding leads to "This can't happen (paragraph)." Initial Comment: The input --------------------- \pdfoutput=1 \input edmac \input protcode \font\eightrm=ptmr8t \setprotcode\eightrm \pdfprotrudechars=2 \linenummargin{outer} %% left|right|inner|outer \footparagraph{A} \tracingall\tracingonline=0 \beginnumbering \pstart \text{There}\Afootnote{Habent sua fata libelli. (Der Satz wurde auf Wunsch der Redaktion von »Living Marxism« gestrichen; siehe Korsch an P.~Mattick am 3.10.1938.)}/ is a striking contrast between the impression produced in the minds of West"=European revolutionaries by those short pamphlets of Lenin and Trotsky which appeared in poorly translated and poorly printed editions during the final stage and the aftermath of the war, and the response called forth in Europe and U.S.A. by the belated appearance, in 1927, of the first extra"=Russian versions of Lenin's philosophical work of 1908, on »Materialism and Empirio"=Criticism«. \pend \endnumbering \bye --------------------- (all input files are in the attached archive) leads to --------------------- ! This can't happen (paragraph). <recently read> \par \do@feet ...s \else \Afootstart {A}\Afootgroup {A} \fi \ifvoid \Bfootins \els... \pagecontents ...p \@cclv \unvbox \@cclv \do@feet \ifr@ggedbottom \kern -\di... \pagebody ...\boxmaxdepth \maxdepth \pagecontents } \edmac@output ...e \vbox {\makeheadline \pagebody \makefootline }\fi }\advan... <output> {\edmac@output } ... l.30 \bye I'm broken. Please show this to someone who can fix can fix --------------------- ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-02-14 20:42 Message: Logged In: YES user_id=929 Now we know which side effects patch-274 has. When it's reverted, the file is processed without error, but margin kerning is missing (which was the original problem before patch-274). Following experiment is done _with_ patch-274. The "this can't happen" error happens within the line_break routine, which chokes on a margin_kern_node (which was filtered out before patch-274).If one adds margin_kern_node to the do_nothing list, like: mark_node,ins_node,adjust_node,margin_kern_node: do_nothing; othercases confusion("paragraph") it apparently works ok, and margin kerning is fine also (requires patch in hz.ch). But i need to understand how the line_break routine works, whether a do_nothing is the right thing to do... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-02-14 15:30 Message: Logged In: YES user_id=421 The submitter used the attached edmac.doc; the error is the same. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106

4 4

Type3 fonts and the way to go
by andreas.lobinger＠freenet.de 16 Feb '05

16 Feb '05

Aloha,The Thanh Han posted:>I spent a few hours playing with type3 fonts, but was not able to create>a type3 font that uses another font (type1). It seems that the text>operators somehow doesn't work inside the CharProc stream for type3>fonts.> ...>But anyway, if someone is interested in this issue, please>have a look into the pdf I created, maybe I did something wrong.-Ressources, as Hans Hagen pointed out, the /Ressources of the pageand therefore object 13 need both /Fonts defined. -Encoding, as you're defining chars 97 and 98 and use 'A' and 'B' which are 65 and 66 in my StdEncoding table you won't get that muchpage impression...-Scaling, you need to reread the chapter about text space details. You aredefining a /FontMatrix of [0.001 etc.] which gives you a 1000x1000 glyphcoordinate system. For /A you use this (750 re), but for /B you definea very small /F1. I don't have a facility to compile your f2.tex with an recent pdftex, soi changed the abovementioned points directly in the f2.pdf. Here are the objects with the changes:13 0 obj << /Font << /F2 10 0 R /F1 9 0 R >> /ProcSet [/PDF /Text] >> endobj 10 0 obj << /Type /Font /FontBBox [0 0 1000 1000] /FirstChar 65 /Widths [750 750] /FontMatrix [0.001 0 0 0.001 0 0] /Encoding 5 0 R /CharProcs 4 0 R /Resources 6 0 R /LastChar 66 /Name /F2 /Subtype /Type3 >> endobj 5 0 obj << /Type /Encoding /Differences [65 /A /B] >> endobj 2 0 obj << /Length 35 >> stream 1000 0 d0 BT /F1 900 Tf (B) Tj ET endstream endobj As far as i understand f2.tex it should be very easy to change (except for the /Ressourcesentry). Wishing a happy day LOBI

3 2

[ pdftex-Bugs-292 ] protuding leads to "This can't happen (paragraph)."
by noreply＠sarovar.org 15 Feb '05

15 Feb '05

Bugs item #292, was opened at 2005-02-14 15:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106 Category: hz Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) >Summary: protuding leads to "This can't happen (paragraph)." Initial Comment: The input --------------------- \pdfoutput=1 \input edmac \input protcode \font\eightrm=ptmr8t \setprotcode\eightrm \pdfprotrudechars=2 \linenummargin{outer} %% left|right|inner|outer \footparagraph{A} \tracingall\tracingonline=0 \beginnumbering \pstart \text{There}\Afootnote{Habent sua fata libelli. (Der Satz wurde auf Wunsch der Redaktion von »Living Marxism« gestrichen; siehe Korsch an P.~Mattick am 3.10.1938.)}/ is a striking contrast between the impression produced in the minds of West"=European revolutionaries by those short pamphlets of Lenin and Trotsky which appeared in poorly translated and poorly printed editions during the final stage and the aftermath of the war, and the response called forth in Europe and U.S.A. by the belated appearance, in 1927, of the first extra"=Russian versions of Lenin's philosophical work of 1908, on »Materialism and Empirio"=Criticism«. \pend \endnumbering \bye --------------------- (all input files are in the attached archive) leads to --------------------- ! This can't happen (paragraph). <recently read> \par \do@feet ...s \else \Afootstart {A}\Afootgroup {A} \fi \ifvoid \Bfootins \els... \pagecontents ...p \@cclv \unvbox \@cclv \do@feet \ifr@ggedbottom \kern -\di... \pagebody ...\boxmaxdepth \maxdepth \pagecontents } \edmac@output ...e \vbox {\makeheadline \pagebody \makefootline }\fi }\advan... <output> {\edmac@output } ... l.30 \bye I'm broken. Please show this to someone who can fix can fix --------------------- ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-02-14 20:42 Message: Logged In: YES user_id=929 Now we know which side effects patch-274 has. When it's reverted, the file is processed without error, but margin kerning is missing (which was the original problem before patch-274). Following experiment is done _with_ patch-274. The "this can't happen" error happens within the line_break routine, which chokes on a margin_kern_node (which was filtered out before patch-274).If one adds margin_kern_node to the do_nothing list, like: mark_node,ins_node,adjust_node,margin_kern_node: do_nothing; othercases confusion("paragraph") it apparently works ok, and margin kerning is fine also (requires patch in hz.ch). But i need to understand how the line_break routine works, whether a do_nothing is the right thing to do... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-02-14 15:30 Message: Logged In: YES user_id=421 The submitter used the attached edmac.doc; the error is the same. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106

1 0

[ pdftex-Bugs-292 ] protuding leads to "This can't happen (paragraph)."
by noreply＠sarovar.org 14 Feb '05

14 Feb '05

Bugs item #292, was opened at 2005-02-14 15:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106 Category: hz Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) >Summary: protuding leads to "This can't happen (paragraph)." Initial Comment: The input --------------------- \pdfoutput=1 \input edmac \input protcode \font\eightrm=ptmr8t \setprotcode\eightrm \pdfprotrudechars=2 \linenummargin{outer} %% left|right|inner|outer \footparagraph{A} \tracingall\tracingonline=0 \beginnumbering \pstart \text{There}\Afootnote{Habent sua fata libelli. (Der Satz wurde auf Wunsch der Redaktion von »Living Marxism« gestrichen; siehe Korsch an P.~Mattick am 3.10.1938.)}/ is a striking contrast between the impression produced in the minds of West"=European revolutionaries by those short pamphlets of Lenin and Trotsky which appeared in poorly translated and poorly printed editions during the final stage and the aftermath of the war, and the response called forth in Europe and U.S.A. by the belated appearance, in 1927, of the first extra"=Russian versions of Lenin's philosophical work of 1908, on »Materialism and Empirio"=Criticism«. \pend \endnumbering \bye --------------------- (all input files are in the attached archive) leads to --------------------- ! This can't happen (paragraph). <recently read> \par \do@feet ...s \else \Afootstart {A}\Afootgroup {A} \fi \ifvoid \Bfootins \els... \pagecontents ...p \@cclv \unvbox \@cclv \do@feet \ifr@ggedbottom \kern -\di... \pagebody ...\boxmaxdepth \maxdepth \pagecontents } \edmac@output ...e \vbox {\makeheadline \pagebody \makefootline }\fi }\advan... <output> {\edmac@output } ... l.30 \bye I'm broken. Please show this to someone who can fix can fix --------------------- ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2005-02-14 15:30 Message: Logged In: YES user_id=421 The submitter used the attached edmac.doc; the error is the same. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106

1 0

[ pdftex-Bugs-292 ] protuding leads to "This can't happen (paragraph)."
by noreply＠sarovar.org 14 Feb '05

14 Feb '05

Bugs item #292, was opened at 2005-02-14 15:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106 Category: hz Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: protuding leads to "This can't happen (paragraph)." Initial Comment: The input --------------------- \pdfoutput=1 \input edmac \input protcode \font\eightrm=ptmr8t \setprotcode\eightrm \pdfprotrudechars=2 \linenummargin{outer} %% left|right|inner|outer \footparagraph{A} \tracingall\tracingonline=0 \beginnumbering \pstart \text{There}\Afootnote{Habent sua fata libelli. (Der Satz wurde auf Wunsch der Redaktion von »Living Marxism« gestrichen; siehe Korsch an P.~Mattick am 3.10.1938.)}/ is a striking contrast between the impression produced in the minds of West"=European revolutionaries by those short pamphlets of Lenin and Trotsky which appeared in poorly translated and poorly printed editions during the final stage and the aftermath of the war, and the response called forth in Europe and U.S.A. by the belated appearance, in 1927, of the first extra"=Russian versions of Lenin's philosophical work of 1908, on »Materialism and Empirio"=Criticism«. \pend \endnumbering \bye --------------------- (all input files are in the attached archive) leads to --------------------- ! This can't happen (paragraph). <recently read> \par \do@feet ...s \else \Afootstart {A}\Afootgroup {A} \fi \ifvoid \Bfootins \els... \pagecontents ...p \@cclv \unvbox \@cclv \do@feet \ifr@ggedbottom \kern -\di... \pagebody ...\boxmaxdepth \maxdepth \pagecontents } \edmac@output ...e \vbox {\makeheadline \pagebody \makefootline }\fi }\advan... <output> {\edmac@output } ... l.30 \bye I'm broken. Please show this to someone who can fix can fix --------------------- ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106

1 0

pdftex1.21a build, linker problem
by andreas.lobinger＠freenet.de 12 Feb '05

12 Feb '05

Aloha, i'm building pdftex on a sort-of standard sparc-sun-solaris2.8. I get a linker problem in building ctangleboot ... /bin/sh ../libtool --mode=link gcc -o ctangleboot ctangleboot.o cwebboot.o lib/lib.a ../kpathsea/libkpathsea.la -lm gcc -o ctangleboot ctangleboot.o cwebboot.o lib/lib.a ../kpathsea/.libs/libkpathsea.a -lm ld: fatal: symbol `main' is multiply-defined: (file ctangleboot.o and file lib/lib.a(main.o)); ld: fatal: File processing errors. No output written to ctangleboot collect2: ld returned 1 exit status gmake: *** [ctangleboot] Error 1 It seems, that the build process is assuming a ld that quietly suppresses multiply defined objects. This shouldn't be so. Wishing a happy day LOBI

4 3

[ pdftex-Patches-257 ] Experimental patch for pdftex character protrusion
by noreply＠sarovar.org 09 Feb '05

09 Feb '05

Patches item #257, was opened at 2005-01-10 21:43 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=257&group_id=106 Category: None Group: Unstable (example) >Status: Closed Resolution: None Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Experimental patch for pdftex character protrusion Initial Comment: Normally items inside a \hbox are not considered for protrusion. With this experimental patch also nested \hboxes at the left and right margin are recursively searched for items with \lpcode or \rpcode, and the outmost containing boxes are protruded correspondingly. This seems to be practical e. g. if an elevated \footnote{foo} (LaTeX) index happens to be at the right margin; in this case the footnote index normally is placed too far inward the line. This disturbance was detected by Peter Muthesius in an de.comp.text.tex news thread "pdfcprot und Ziffern am rechten Rand" started Sat Jan 08 14:05:23 CET 2005. Rough experimental patch, rudimentarily tested with left and right protrusion, see test file xx.tex with output xx.pdf. Just for discussion. No warranty. Have fun! Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-02-09 20:30 Message: Logged In: YES user_id=929 patch257h has been put into hz.ch for 1.21a (pdftex, pdfetex, pdfxtex) ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-18 22:19 Message: Logged In: YES user_id=929 Character protrusion patch news: * The protrusion character can now be inside deeply nested \hbox{}, with further (also nested) skipable \hbox{} stuff in the way. The nested list will be recursively searched until a non-skipable item (protrusion character, other character, or list end) is found. * Try to solve left protrusion at paragraph start with \parindent=0pt,by selectively skipping over TeX's empty \hbox{} there. * Protrusion character search by 2 new functions find_protchar_left() and find_protchar_right(), and simple stack. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=257&group_id=106

1 0

[Fwd: Re: [NTG-pdftex] Type3 fonts and the way to go]
by Hans Hagen 09 Feb '05

09 Feb '05

1 0

[Fwd: Re: [NTG-pdftex] Type3 fonts and the way to go]
by Hans Hagen 09 Feb '05

09 Feb '05

1 0