December 2005 - ntg-pdftex - NTG Mailing Lists

Roadmap
by Martin Schröder 15 Feb '06

15 Feb '06

Hi, this weekend I've met Hans, Hartmut and Taco in Schwetzingen (we attended the christmas party of the Darmstadt TeXies with Hermann Zapf) and we discussed the status and future of pdfTeX. We came down with this "roadmap": 1.40 (200603): - all the current patches plus \primitive et.al - cleanup the code (fewer patchfiles) to have a better starting point for lua - move project to Gforge hosted by Fabrice, and setup a complete code repository there - start of "pdfTeX news" 1.50 - more bits, i.e. use more than 16 (and enough) where possible 1.60 or later - general map file handling for pdfTeX and all programs that use map files - OpenType -- this requires more bits and can be done in steps - lua -- integration can be done post 1.40, but the TeX<->Lua interface needs much testing and developement, so lua will stay experimental for quite some time sometime (i.e. whenever it's ready) - tagged pdf - merging hyperlinks in included documents Best Martin -- http://www.tm.oneiros.de

10 68

pdftex and xpdf (and its security bugs): What about a libxpdf?
by frank＠kuesterei.ch 24 Jan '06

24 Jan '06

Dear pdftex developers, during the last months security support for software containing xpdf code was a nightmare - not only that there were many security issues discovered, moreover everybody used a different patch, it was unclear to what extent older versions were affected, and so forth. This was also a problem for us, the teTeX maintainer in Debian, which currently has three versions of pdftex with three different versions of the xpdf code. What would you think about creating a shared library, "libxpdf", and using that for pdftex, either linked dynamically (for Linux/Unix distributions) or statically (for TeX-live and friends)? There is already such a library, libpoppler, a fork of the xpdf code (http://poppler.freedesktop.org/) However, I do not know whether the xpdf author, Derek B. Noonburg, is generally unwilling to create a shared library, or whether people simply didn't ask him. Personally I would prefer to have as little a number of versions of the same code, and thus to get a shared library from xpdf proper. If you agree, I would be oblidged if one of you would contact Derek Noonburg (derekn(a)foolabs.com) and ask him. He seems to be a little unresponsive at times, and has not answered a similar question from the maintainer of the xpdf package in Debian for a couple of weeks now. Maybe we can convince him that this is a good idea if he is approached from different sides. Alternatively, if he is unwilling to make this change, do you think using libpoppler would be feasible? Many thanks in advance, Frank Küster -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer

2 3

pdftex-1.40.0-alpha-20051221
by Martin Schröder 27 Dec '05

27 Dec '05

http://sarovar.org/download.php/866/pdftex-1.40.0-alpha-20051208-20051221.d… http://sarovar.org/download.php/867/pdftex-1.40.0-alpha-20051221.tar.bz2 - has a large patch from Thanh - pdflastlink has been fixed - remove generated pdf in case of fatal error Have fun Martin -- http://www.tm.oneiros.de

3 3

pdftex-1.40.0-alpha-20051226
by Martin Schröder 27 Dec '05

27 Dec '05

http://sarovar.org/download.php/872/pdftex-1.40.0-alpha-20051221-20051226.d… http://sarovar.org/download.php/873/pdftex-1.40.0-alpha-20051226.tar.bz2 - improved patches: - 453 Object Streams for PDF-1.5 - take PK resolution from "pk_dpi" parameter in texmf.cnf, if it has not been set by the format file or by the user - 432 Rules in a PDF qQ group - some fixes for Thanhs patch - some improvements from -Wall - .indent.pro for indent -- http://www.tm.oneiros.de

2 1

[ pdftex-Patches-453 ] Object Streams for PDF-1.5
by noreply＠sarovar.org 26 Dec '05

26 Dec '05

Patches item #453, was opened at 2005-11-26 18:05 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=453&group_id=106 Category: Object Streams Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Object Streams for PDF-1.5 Initial Comment: Rough early patch, work in progress, produces PDF-1.5 object streams and cross reference streams. With the patch, and enabled by \pdfminorversion=5, and with luck, pdfetex produces e. g. from its WEB source a PDF file with size 5.97 MByte instead of 11.2 MByte without object streams. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-12-26 20:21 Message: Logged In: YES user_id=929 Patch update. Object stream writing is now controlled by primitive \pdfobjcompresslevel = 0...3 (/pdfobjectstreams primitive removed). 0 = no object streams at all, 1 = compress objects excluding the ones from embedded PDF files (for handling of problematic PDF files) and /Info dictionary (for legibility), 2 = also compress objects from embedded PDF files, but leave /Info uncompressed, 3 = compress everything. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=453&group_id=106

1 0

[ pdftex-Patches-462 ] HZ font expansion by text matrix manipulation
by noreply＠sarovar.org 23 Dec '05

23 Dec '05

Patches item #462, was opened at 2005-12-23 23:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106 Category: Positioning Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: HZ font expansion by text matrix manipulation Initial Comment: Use textmatrix Tm instead of /FontMatrix for font expansion. Then a font file will be embedded only once for all expansion factors. Gives smaller PDF files. Works then also for non-embedded fonts. TrueType not tried yet. Rough patch only, incomplete, work in progress, no warranty, not for production. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106

1 0

unbuffered vs. buffered terminal output
by Hartmut Henkel 23 Dec '05

23 Dec '05

following trivial observation i made (several runs): $ time pdfetex samplepdf real 0m2.536s real 0m2.605s real 0m2.737s real 0m2.654s $ time pdfetex samplepdf | buffer real 0m0.900s real 0m1.035s real 0m0.900s real 0m0.913s the speed gain is impressive here, also with other files from daily business and for longer runs. Same if i write $ pdfetex samplepdf > xxx So at least here pdfetex spends lots of time just for unbuffered talk to the terminal. And it's faster with a smaller window. Maybe we should think of implementing buffered writing? See e. g. man 3 setbuf. The problem is that it should fflush() in case of errors and switch to unbuffered. And maybe it should fflush() also after a certain time of say 0.5 s, which would require select(). Has anybody similar statistics? Regards, Hartmut

5 10

[NTG-pdftex] [ pdftex-Feature Requests-87 ] In case of fatal errors, delete the output file
by noreply＠sarovar.org 22 Dec '05

22 Dec '05

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: Martin Schröder (oneiros) 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: Martin Schröder (oneiros) Date: 2005-12-19 00:38 Message: Logged In: YES user_id=421 The attached patch unlinks the current file, if a fatal error happens. Currently this is done without any checks, and may be a security problem. ---------------------------------------------------------------------- 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

4 5

doc gaps
by Pawel Jackowski 20 Dec '05

20 Dec '05

Hi, three things, I suppose, already established in releases but not documented: -- regexp support -- string comparison -- `page' modifier for \pdfliteral Experimental? -- Pawe/l Jackowski P.Jackowski(a)gust.org.pl

5 5

Re: [NTG-pdftex] various features
by Akira Kakuto 19 Dec '05

19 Dec '05

> On 2005-12-19 14:16:49 +0100, Hans Hagen wrote: > > Are all Than's recent patches included? Like the \pdfprependkern and > > alike stuff? > > No. But I included all I got. > > Thanh? http://pdftex.sarovar.org/src/pdftex-20050924.patch.gz Please include the above patch by Thanh which defines \pdfprependkern etc. I'm personally using the subfont mechanism in the patch to typeset Japanese. The patch is for 1.30.3. So some hand work will be needed. Thanks, Akira

1 0