- ntg-pdftex - NTG Mailing Lists

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

Re: [NTG-pdftex] PandaLex
by Tom Kacvinsky 21 May '03

21 May '03

Second try: first time this went to Martin instead of the list. D'oh! As Martin should know, as I figure he is the best person around for forwarding from one list to the other. ;-) Well, maybe Nelson Beebe can take that "title". Tom On 2003/05/19 at 15:01, Martin Schroeder <ms(a)artcom-gmbh.de> wrote: > On 2003-05-19 14:41:21 +0200, Rolf Niepraschk wrote: > <snip> NOTE: http://www.tinyurl.com is great for long links in emails. > Thanks. > > It's from the author of the comp.text.pdf USENET frequently asked > questions document. :-) >

1 0

PandaLex
by Rolf Niepraschk 19 May '03

19 May '03

About: PandaLex is the PDF parsing code from Panda, which has been split into its own project to increase its utility. It is a flex and bison description of the PDF specification, which allows programmers to define callbacks to handle different document elements. ==> http://www.stillhq.com/cgi-bin/getpage?area=pandalex&page=index.htm ...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

Re: [NTG-pdftex] SockeTeX :-)
by Hans Hagen 01 Apr '03

01 Apr '03

At 08:11 PM 3/30/2003 -0500, Tom Kacvinsky wrote: >Hi all, > >Cool. Fabrice, didn't you work on something similar? I remember you >showing me some work you were doing on use of URLs in TeX documents >at EuroTeX 2001 (in Kerkrade). Whatever became of that? that should work out of the box: \input http://someplace.somewhere/somefile.sometype 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 -------------------------------------------------------------------------

4 4

splitting pdftex
by The Thanh Han 01 Apr '03

01 Apr '03

Hi all, I am considering to split pdftex into 3 programs: 1) pdftex -- a (hopefully) stable version that contains only features often used by regular users 2) pdfetex -- pdftex + etex 3) pdfxtex ('x' stands for experiment; suggestions for another name are much welcome) -- contains features that are normally not used + features being tested; ie pdftex + etex + all testing and buggy features ;) This version is for brave only ;) Please let me know what you think of it? Thanh

2 1

Re: [pdftex] Bug in 1.10a: \pdfximage with pdf file and width
by Hans Hagen 25 Feb '03

25 Feb '03

At 07:44 PM 2/24/2003 +0100, you wrote: >On Mon, 24 Feb 2003, Hans Hagen wrote: > > > mediaboxes (in xforms etc) should also be as accurate as possible since > > otherwise the viewers clip engine starts spoiling things > >Scaling seems to be precise everywhere now. There is no scale in the >xforms, the /Matrix [1 0 0 1 0 0] is used. > >But /BBox dimensions ARE rounded to these decimal_digits when written >out, as are also still the width and height of the PDF images. > >Do you suggest, that even the width and height of images and xforms >should be written out with max. number digits? It costs nearly nothing, >but this is currently NOT done. If you complain quickly enough, it might >go into the next release. :-) This is in pdftex.ch code lines 3549, >3550, 8274, 8275, 8286, 8290. those dimensions should indeed be precise (and better be rounded up (nth digit) than down in order not to clip lines 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