- ntg-pdftex - NTG Mailing Lists

[ 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