February 2005 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-294 ] pdfmovechars/encoding problem
by noreply＠sarovar.org 01 Apr '05

01 Apr '05

Bugs item #294, was opened at 2005-02-15 21:06 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: pdfmovechars/encoding problem Initial Comment: This has been reported by Jörg Heinrich at 1 Feb. 2005 on the pdftex list (Subject: [pdftex] pdfetex). The following derived example leads to a segfault: % this works: %\pdfmovechars=1 % this gives segfault: \pdfmovechars=2 % this works: %\pdfmapline{phvr8r Helvetica <8r.enc <phvr8a.pfb} % this gives segfault: \pdfmapline{phvr8r Helvetica <phvr8a.pfb} \font\phv phvr8r at 10pt \phv a \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106

5 4

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 23 Feb '05

23 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