- ntg-pdftex - NTG Mailing Lists

Re: backslashes in \pdfoutline
by Martin Schröder 11 Jul '04

11 Jul '04

On 2004-07-10 20:39:06 -0400, Karl Berry wrote: > Hi Martin, > > As you may have noticed, I reported an issue on the pdftex lists a few > days ago regarding catcode 12 backslashes in \pdfoutline et al. > Although Hartmut and Heiko and I have discussed it some, and Hartmut has > written some patches, I haven't seen any definitive decisions on what we > want to do, and I want to fix texinfo.tex accordingly. > > (It comes up in practice with Texinfo because in Texinfo, unlike most > (all?) other common formats, backslash is supposed to be a "normal" > character that can be used in cross-reference targets.) > > In short, suppose we have: > > \catcode`\/=0 /catcode`\\=12 > /pdfcompresslevel=0 > /pdfdest name {xyz\} hello from xyz /vfill/eject > /pdfoutline goto name{xyz\}{to xyz\} > > This produces an invalid PDF file, because the \ escapes the > end-of-string ) delimiter in the output: > > << /S /GoTo /D (xyz\) >> > ... > (to xyz\) > > The choices seem to be: > > 1) do nothing, and leave it up to the document's TeX code to double the > backslashes in all cases. This is the current situation, de facto. > > 2) have pdftex escape the backslashes in the target names only, so that > it would produce (xyz\\) and (to xyz\). > > 3) have pdftex escape the backslashes in the outline text only, so that > it would produce (xyz\) and (to xyz\\). > > 4) have pdftex escape the backslashes in all situations, so that > it would produce (xyz\\) and (to xyz\\). Karl, 4 would be the logical choice for pdf. > Escaping the backslashes implies that TeX code cannot produce PDF string > escapes. This does not seem like a serious limitation to me, since TeX > can write any byte value (and pdftex "should" escape as necessary into > \nnn octal notation in string constants -- I have not tested this). I will. > Not escaping the backslashes implies that it's possible to write TeX > documents which produce invalid PDF. This seems bad, however, if this > is the case with other pdftex commands also, the argument loses its force. We'll have to check this for consistency. Best regards Martin PS: I'm cc'ing the ntg-pdftex list so that Hans and Thanh and others are included. -- 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 -output-comment=STRING
by Hartmut Henkel 11 Jul '04

11 Jul '04

pdftex --help gives -output-comment=STRING use STRING for PDF file comment instead of date but the manpage says that "In DVI mode, use string for the DVI file comment instead of the date. This option is ignored in PDF mode." And i couldn't find any trace of STRING in the PDF file, but it's in the DVI file. So it seems this would be more correct: -output-comment=STRING use STRING for DVI file comment instead of date Regards, Hartmut

1 0

PNG image embedding
by Hartmut Henkel 08 Jul '04

08 Jul '04

There is a small q+d patch on my homepage at http://www.circuitwizard.de/pdftex/patch5/index.html which tries to embed PNG files natively, without the usual slow decompressing + compressing steps done by pdftex---only if the PNG image type allows that. This usually results in a smaller overall PDF file size, as the original line-by-line predictor type informations from the PNG image are carried over into the PDF file. And the PNG embedding is speedier. Best Regards, Hartmut P.S. The newest libtiff comes with a tiff2pdf program. Quite handy.

4 3

[ pdftex-Feature Requests-89 ] Handle missing pages in included pdfs better
by noreply＠sarovar.org 08 Jul '04

08 Jul '04

Feature Requests item #89, was opened at 2004-07-08 14:38 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=89&group_id=106 Category: None Group: v1.21 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) Summary: Handle missing pages in included pdfs better Initial Comment: Currently, when one tries to include page 10 of a 9 page document, pdftex quits. Proposed change: Behaviour of pdfTeX for pdf image inclusion: UNKNOWN := -1 Initialization: \pdflastximagepages := UNKNOWN Continue := Continue with empty xform object with dimension 1bp x 1bp. // 1bp because it avoids zero and possible problems and // the output is small (/BBox [0 0 1 1]) if PDFFileExists if PageNumber < 1 \pdflastximagepages = UNKNOWN Warning "Invalid page number" Continue elsif PageNumber > \pdflastximagepages \pdflastximagepages is set Warning "Page number to large (out of range) Continue else \pdflastximagepages is set image is included fi else Warning "PDF file does not exist" \pdflastximagepages = UNKNOWN Continue fi Failure/Success checking: if [page] < 1 * Page number too small elsif \pdflastximagepages = -1 * PDF file does not exist elsif [page] > \pdflastximagepages * Page number too large else * Success fi or with optimization for success: if [page] < 1 * Page number too small elsif [page] > \pdflastximagepages if \pdflastximagepages = -1 * PDF file does not exist else * Page number too large fi else * Success fi ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=89&group_id=106

1 0

[ pdftex-Feature Requests-87 ] In case of fatal errors, delete the output file
by noreply＠sarovar.org 08 Jul '04

08 Jul '04

Feature Requests item #87, was opened at 2004-07-02 11:13 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&group_id=106 Category: None >Group: v1.21 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) Summary: In case of fatal errors, delete the output file Initial Comment: When pdfTeX currently encounters a fatal error, it closes it's output file, which leads to incomplete/corrupt files. pdfTeX should produce only valid files, and in case of fatal errors the output should be deleted. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-07-02 14:35 Message: Logged In: YES user_id=1608 When you truncate a file, the result is an empty file. From a user's viewpoint, that is not the same thing as a corrupt PDF. The distinction is small, but the advantage of an empty file is that it is not likely to be confused for a correct PDF. If it is possible, then deleting the PDF file is definately better, but file deletion doesn't always work. Truncation almost always does work, and it's only two syscalls extra, so why not? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-07-02 14:21 Message: Logged In: YES user_id=421 Simply truncating a pdf still makes it invalid (because the file structure is incomplete). Producing a valid truncated output file in case of fatal errors will be tricky and not always possible. Deleting the corrupt output is much easier. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-07-02 13:50 Message: Logged In: YES user_id=1608 If deleting the file doesnt work, truncation is probably still better than nothing. (?) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&group_id=106

1 0

[ pdftex-Bugs-88 ] \pdforigin=0pt shifts output on 1in
by noreply＠sarovar.org 08 Jul '04

08 Jul '04

Bugs item #88, was opened at 2004-07-06 16:55 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=88&group_id=106 Category: None Group: v1.20a >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: \pdforigin=0pt shifts output on 1in Initial Comment: In the attached file foo1.tex the output starts at (1in/1in), although it should start at (0pt/0pt). The output of foo2.tex starts at (1pt/1pt) as expected. Tested with the latest teTeX-beta. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2004-07-08 11:50 Message: Logged In: YES user_id=421 #5452 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=88&group_id=106

1 0

\pdfhorigin / \pdfvorigin broken?
by Thomas Esser 07 Jul '04

07 Jul '04

I wonder if there is some automatic translation from 0pt to 1in somewhere... The following \pdfhorigin=0pt \pdfvorigin=0pt \pdfximage page 1 {foo.pdf}% \setbox0=\hbox{\pdfrefximage\pdflastximage}% \pdfpagewidth=\wd0 \pdfpageheight=\ht0 \shipout\box0 \bye gives a shifted output of foo.pdf (by 1in), while \pdfhorigin=1pt \pdfvorigin=1pt \pdfximage page 1 {foo.pdf}% \setbox0=\hbox{\pdfrefximage\pdflastximage}% \pdfpagewidth=\wd0 \pdfpageheight=\ht0 \shipout\box0 \bye gives only a shift by 1pt (as specified)- Something to fix for 1.20 hopefully... Thomas

3 9

empty \special
by Rolf Niepraschk 07 Jul '04

07 Jul '04

Processing a TeX document with \special{} inside the pdfTeX compiler writes the warning Non-PDF special ignored! My suggestion: Let an empty \special to be a valid PDF special. ...Rolf -- || Rolf Niepraschk c/o Physikalisch-Technische Bundesanstalt || || Abbestr. 2-12; D-10587 Berlin, Germany || || Tel/Fax: ++49-30-3481-316/490, email: Rolf.Niepraschk(a)ptb.de ||

2 1

[ pdftex-Bugs-88 ] \pdforigin=0pt shifts output on 1in
by noreply＠sarovar.org 06 Jul '04

06 Jul '04

Bugs item #88, was opened at 2004-07-06 16:55 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=88&group_id=106 Category: None Group: v1.20a Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: \pdforigin=0pt shifts output on 1in Initial Comment: In the attached file foo1.tex the output starts at (1in/1in), although it should start at (0pt/0pt). The output of foo2.tex starts at (1pt/1pt) as expected. Tested with the latest teTeX-beta. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=88&group_id=106

1 0

pdfannot in xform
by Hans Hagen 06 Jul '04

06 Jul '04

Hi, Something to keep an eye on: pdftex bombs when an pdfannot happens inside an xform (still playing with that, so no pattern yet) 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 -----------------------------------------------------------------

6 24