July 2003 - ntg-pdftex - NTG Mailing Lists

Re: [NTG-pdftex] pdf_version_found > pdf_version_wanted
by Hans Hagen 12 Jul '03

12 Jul '03

At 17:29 10/07/2003 +0200, Martin Schroeder wrote: >On 2003-07-08 17:55:17 +0200, Martin Schröder wrote: > > one to be produced. I want to make this behaviour configurable > > through pdftex.cfg (and a corresponding primitive). pdfTeX would > >Currently the primitive is tentatively named >\pdfoptionpdfversionerrorlevel. Any better idea? ^^^ omit the second pdf -) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma(a)wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

1 0

Re: [NTG-pdftex] PDF inclusion with annotations
by Hans Hagen 12 Jul '03

12 Jul '03

At 14:01 10/07/2003 +0200, Martin Schroeder wrote: >I must confess I have not cared for annotations yet so I just >hope that this is correct (it certainly sounds so) and leave that >to the experts. an option is to support this under user control: \pdfmergeannots=0 : not enabled \pdfmergeannots=1 : enabled defaulting to 0 (not enabled) that way macro packages can control it also, it will need some extensive testing, esp for user annotations which may have object references, resources etc; since this would involve parsing of content, it's also a dangerous excersise (hard to make foolproof); this means that we should be able to control this at the annotation level: - links - widgets - etc so, we should need something \pdfmergelinkannots=1 etc as well > > Another important this which happens within the function out_image, > > is the calculation to the new coordinates of the annotation's /Rect. > > There are no big problems if an images is scaled with the help of > > <rule spec> of \pdfximage. But their are a lot of problems if > > macro packages do something like \pdfliteral{.5 0 0 .5 0 0 cm} > > for scaling and similar things for rotating images. To calculate > > the coordinates of /Rect, pdftex must know exactly which coordinate > > transformations are actually taking place. So I introduced two > > new primitives: \pdfsetctm and \pdfresetctm. > >This I find much more interesting. this problem is more general, since it also concerns normal (not xpdf related) code; i remember discussing this with thanh a few years a go but forgot about the implications, but for out_image situations it sounds ok to me >[...] > > > Since TeX does not have a function to scan floating-point numbers, > > I used scan_dimen as a work around to scan the arguments of \pdfsetctm. > > That's why you must write > > > > \pdfsetctm 0bp 1bp -1bp 0bp 0bp > > > > so far. It should be no problem to change this in the future. > >This could be added. i don't like the unit; we could use numbers here and assume that they are scaled points (as happened in some dvi postprocessors); an alternative is to make it a token list \pdfsetctm{....} and treat each component as what it is: floating point or dimension. Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma(a)wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

1 0

Re: [NTG-pdftex] 1.10b
by Heiko Oberdiek 11 Jul '03

11 Jul '03

At Tue, 11 Feb 2003 17:41:42 +0100 Hans Hagen wrote: > > At 04:36 PM 2/11/2003 +0100, Martin Schroeder wrote: > >On 2003-02-07 19:51:27 +0100, Thomas Esser wrote: > > > > also on the todo list: > > > > > > What about the things that Heiko Oberdieck has proposed: > > > http://omnibus.uni-freiburg.de/~oberdiek/pdftex.html > > >The map files need a bit more thinking. > > indeed, esp since the optimization only looks at the first 8 chars of a > filename if i remember right; No, you have already given that hint last year and I have changed the patch using all chars. To make it clear, the patch improves the performance of the *current* map file handling of pdfTeX. It saves me *much* time in comparison to the binary of TeXLive 7. But for *future* versions we should find an agreement about the behaviour of pdfTeX regarding map files, eg: * Map files: * Where can they specified? * config file (pdftex.cfg) * support of other config files * config files given on command line * map files given on command line * config files given by command * map files given by command * ... * When they are evaluated? * static, first use * dynamic changes possible? * Which order? * default, if no map file is given? * adding mapfiles * replacing mapfiles * order ... * ... * Map entries: * later entries are ignored with warning (current) * later entries replaces older ones silently * syntax ... * ... I hope I will find some time next days to give a suggestion for a specification. One aim can be to make the behaviour similar to dvips. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de>

8 28

Patch ShellEscape
by Heiko Oberdiek 11 Jul '03

11 Jul '03

Patch ShellEscape Packages such as pdftricks.sty, epstopdf.sty (or pdftex.def) call external programs. They do not work at all, if the \write18 feature is not enabled. Therefore a robust method would be useful in order to inform the user. For security reasons the \write18 featuer must not be set by TeX macro code. Thus the patch introduces a new readonly primitive \pdfshellescape that expands to "0" if the \write 18 feature is disabled and "1" in the other case. Use, for instance: \ifnum\pdfshellescape=0 \message{The \string\write18 feature is disabled.} \else \message{The \string\write18 feature is enabled.} \fi Patch files: pdftex.ch.diff for TeX/texk/web2c/pdftexdir/pdftex.ch pdfetex.ch2.diff for TeX/texk/web2c/pdfetexdir/pdfetex.ch2 Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> --

5 11

Tracking Bugs, Patches and Feature Requests
by Martin Schroeder 11 Jul '03

11 Jul '03

Hi, the pdfTeX project needs a system for tracking bugs, patches and feature requests (whenever I integrate all the latest patches and look for open bugs I fear I forget one). We could of course set up the needed software by ourself, but there are already places that offer the needed services. I did a quick survey: - Sourceforge (http://sf.net) - Tracker for bugs, support requests, patches, feature requests - Limited to OSI-compatible software (which pdfTeX is) - Savannah (savannah.nongnu.org) - Tracker for bugs, support requests, patches - Limited to GPL-compatible software (which pdfTeX is) - Emphasises on freeness - Berlios (berlios.de): - Tracker for bugs, support requests, patches - Not limited to OSI-compatible software (which pdfTeX is) - It seems you can't automatically get mail about new bugs/patches - Management is german It seems Sourceforge is offering the most with the least strings attached. I propose we set up pdfTeX at Sourceforge in the near future (post-Hawaii) for project management but keep the sources in the p4 repository at DANTE/TeXlive (it works perfectly). Comments? 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

4 4

pdf_version_found > pdf_version_wanted
by Martin Schroeder 11 Jul '03

11 Jul '03

Hi, current pdfTeX will not embed pdfs with a newer version than the one to be produced. I want to make this behaviour configurable through pdftex.cfg (and a corresponding primitive). pdfTeX would then only emit a warning but embed the pdf anyway (like older versions did). Reason is to be backwards-compatible: We have installations where we want to upgrade the pdfTeX-installation but not the TeX-producing application. Objections? 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

2 5

Patch OutlineAttr
by Heiko Oberdiek 10 Jul '03

10 Jul '03

Hello, Patch OutlineAttr Since PDF 1.3/1.4 further entries are supported in the outline item dictionary: /SE, /C, /F. Especially the last to keys can be interesting. Currently there is no support in pdfTeX to set these entries. Therefore I have added the possibility to specify further attributes to the \pdfoutline command: \pdfoutline <outline spec> <outline spec> --> <attr spec> <action spec> [count <number>] <general text> Patch files, based on 2002/06/05 v1.11a: pdftex.ch.diff for pdftexdir/pdftex.ch pdftex-syntax.txt for pdftexdir/pdftex-syntax.txt Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> --

2 1

Re: ANNOUNCE: Xpdf 2.02 - a PDF viewer for X
by Martin Schroeder 10 Jul '03

10 Jul '03

On 2003-03-24 19:58:02 -0000, Derek B. Noonburg wrote: > Glyph & Cog, LLC is pleased to announce a new version of Xpdf, the > open source Portable Document Format (PDF) viewer for X. The Xpdf > project also includes a PDF text extractor, PDF-to-PostScript > converter, and various other utilities. > > Xpdf runs under the X Window System on Unix, VMS, and OS/2. The non-X > components (pdftops, pdftotext, etc.) also run on Win32 systems and > should run on pretty much any system with a decent C++ compiler. > > Major changes: > * Rewrote the text extractor code that assembles words into lines to > better handle vertically overlapping lines. > * Add the "match" option for paper size (in PostScript output). > * Added support for external 16-bit TrueType fonts; added the > displayCIDFontTT and displayNamedCIDFontTT commands to the xpdfrc > file. > * Added an Arabic language support package. > * Added the Windows-1255 encoding to the Hebrew language package. > > See the `CHANGES' file for a complete list of changes. I'll integrate it next week (i.e. hopefully before DANTE2003) and thus start work on 1.11a 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

4 10

PDF inclusion with annotations
by Andreas Matthias 10 Jul '03

10 Jul '03

Last month on pdftex mailing list we had a short discussion, whether annotations of external PDFs could be copied when including PDFs. I gave it a try and now I have a first partial success. The code is far from being complete and there are still a lot of bugs in it. Nevertheless I think it is the right time now to show you the code, so we can discuss whether this is the right way to go on. You can download the patches at: http://stud3.tuwien.ac.at/~e9225580/pdftex-1.10b-incl-annot.tar.bz2 Here is a short description of the changes I did: (1)While reading the image (function read_pdf_info), the annotations of this image are read, too, and a map with all relevant details about the annotations is set up. (2)While writing the reference (/Im1 Do) to the content stream (function out_image), a dummy annotation node is created to get a correct /Annots array. Those dummy annotations nodes are caught during module @<Flush out PDF annotations@> and are just delete; no dummy annotation object it written out. (3)Eventually in function epdf_write all annotation objects of this image are copied are written out. Another important this which happens within the function out_image, is the calculation to the new coordinates of the annotation's /Rect. There are no big problems if an images is scaled with the help of <rule spec> of \pdfximage. But their are a lot of problems if macro packages do something like \pdfliteral{.5 0 0 .5 0 0 cm} for scaling and similar things for rotating images. To calculate the coordinates of /Rect, pdftex must know exactly which coordinate transformations are actually taking place. So I introduced two new primitives: \pdfsetctm and \pdfresetctm. Instead of \pdfximage {doc.pdf} \pdfliteral{q 0 1 -1 0 0 0 cm} \pdfrefximage\pdflastximage \pdfliteral{Q} macro packages should do \pdfximage {doc.pdf} \pdfsetctm 0 1 -1 0 0 0 \pdfrefximage\pdflastximage \pdfresetctm Now pdftex does know about the current transformation matrix and can calculate the correct coordinates of /Rect. Since TeX does not have a function to scan floating-point numbers, I used scan_dimen as a work around to scan the arguments of \pdfsetctm. That's why you must write \pdfsetctm 0bp 1bp -1bp 0bp 0bp so far. It should be no problem to change this in the future. The primitives \pdfsetctm and \pdfresetctm create whatsit nodes. When these nodes a shipped out \pdfsetctm pushed its arguments on a stack and \pdfresetctm pop them again. When a \pdfrefximage node is shipped out it can look at the stack to get the current CTM and calculate a correct /Rect. The tarball contains 2 plain TeX files and 2 LaTeX files which show some examples. To compile the LaTeX files you must apply the patch pdftex.def.diff to pdftex.def. And now comes the unpleasant part. Here is a list of major bugs that those patches have :-( * If an image is included several times, all copies have the same image number. Unfortunately I used this image number as the key to the map of annotations. That's why you cannot include pages several times, without getting false /Rects. This bug shouldn't be too difficult to fix. * \pdfsetctm should only be used in horizontal mode. I have not idea why it chokes in vertical mode. * There should be no material between \pdfsetctm and \pdfrefximage. Any material there would cause pdftex to call pdf_set_origin, which introduces a new CTM not taken into account by \pdfsetctm. * LaTeX, graphicx: foolish things like \includegraphics[angle=90, angle=90]{doc.pdf} causes the call of the function pdf_set_origin and therefore don't work either. * There must not be a page break between \pdfsetctm and \pdfresetctm. * There are probably more ... Ciao Andreas

2 1