November 2005 - ntg-pdftex - NTG Mailing Lists

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-Patches-416 ] new primitive pdflastlink
by noreply＠sarovar.org 06 Dec '05

06 Dec '05

Patches item #416, was opened at 2005-08-19 09:42 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=416&group_id=106 Category: Primitives Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Utermann (ralfu) Assigned to: Nobody (None) Summary: new primitive pdflastlink Initial Comment: This patch implements a new primitive \pdflastlink (analogous to \pdflastannot) which returns the object number of the last object created with \pdfstartlink. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=416&group_id=106

3 2

[ pdftex-Patches-415 ] various extensions and fixes
by noreply＠sarovar.org 04 Dec '05

04 Dec '05

Patches item #415, was opened at 2005-08-19 09:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106 Category: Primitives Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: various extensions and fixes Initial Comment: This is a patch for various experimental extensions: - \pdfinsertht: return the height of an insert (requested by Hans); this has similar syntax to \pdftexrevision. - do not fail when \pdfobj is used with an invalid object number (requested by Hans) - snapping: support for grid typesetting -- see snap.txt for details - kern before space: allow changing interword glues in a flexible way and inserting a kern before certain characters -- see kern-before-interword-glue.txt for details The notes in snap.txt and kern-before-interword-glue.txt are from email correspondence with people interested in; hence these notes are somewhat informal, inaccurate or out-of-date. How to apply: ~~~~~~~~~~~~~ cd /path/to/pdftex-1.30.0-srcdir/src/texk patch -p1 < /path/to/pdftex-20050818.patch cd web2c make pdfetex ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2005-09-04 18:22 Message: Logged In: YES user_id=421 The patch for invalid object numbers is included in 1.30.1++ ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106

3 2

[ pdftex-Feature Requests-454 ] distribution: rename Build script
by noreply＠sarovar.org 26 Nov '05

26 Nov '05

Feature Requests item #454, was opened at 2005-11-26 23:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=454&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: distribution: rename Build script Initial Comment: Here is a very, very minor nuisance: In order to compile pdftex on case-insensitive file systems like Windows, one always has to rename the Build script first, e.g., to Build.sh, since otherwise the directory build/ cannot be created. I would suggest to rename either the script or the build directory. Regards, Robert. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=454&group_id=106

1 0

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

26 Nov '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 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=453&group_id=106

1 0

! TeX capacity exceeded, sorry [hash size=60000]
by Vit Zyka 24 Nov '05

24 Nov '05

Hi all, I have got a message: ! TeX capacity exceeded, sorry [hash size=60000]. so I tried to increase extra_hash = 100000 (or 70000), refresh format (not sure if needed), but obtain the same error message. I have several questions and suggestions: 1. Is 'extra_hash' the proper variable? 2. Is possible that my binary (pdfeTeX 3.141592-1.21b-2.2 (Web2C 7.5.4) kpathsea version 3.5.4 from Akira) has extra_hash=50000 as maximum? 3. Sometimes the error message variable name differs from variable name that should be set. It is confusing, one is not sure if the proper variable is set. Could it be unified? Or Might be add more info like ! TeX capacity exceeded, sorry [hash size=60000, set extra_hash up to 100000]. Thanks Vit

2 1

Re: [dev-context] Re: \showskips bug
by Taco Hoekwater 21 Nov '05

21 Nov '05

Hans Hagen wrote: >> That's fixed, a while back. my pdfetex now quitted at >> >> [94729] [94730] [94731] [94732] [94733] [94734] [94735] [94736 >> ! TeX capacity exceeded, sorry [indirect objects table size=300000]. >> <output> {\shipout \box 255 >> \global \advance \pageno 1 \unhbox 255 } >> <to be read again> >> \end >> l.3 \bye >> >> ! ==> Fatal error occurred, the output PDF file is not finished! >> Transcript written on out.log. >> >> After a minute or two. > > ah, so in practice it will quit earlier depending on other objects used > (i'm not sure if for instance objects of included graphics use that > piece of memory) This is mostly the required page objects. 3 objects are used per actual (totally empty) page: 13 0 obj << /Length 0 >> stream endstream endobj 12 0 obj << /Type /Page /Contents 13 0 R /Resources 11 0 R /MediaBox [0 0 595.2756 841.8898] /Parent 7 0 R >> endobj 11 0 obj << /ProcSet [ /PDF ] >> endobj It is a bit wasteful to keep those in the indirects objects table for ever and onwards, but I am not sure if it is doable to flush them right away. (CC ntg-pdftex) Greetings, Taco

6 24

fix_int() corrections
by Hartmut Henkel 17 Nov '05

17 Nov '05

i wonder whether one should feed back the fix_int() clipping corrections into the variables, e. g. like fixed_pk_resolution := fix_int(pdf_pk_resolution, 72, 2400); pdf_pk_resolution = fixed_pk_resolution; {== this line would be new ==} Currently e. g. \pdfpkresolution is copied to an internal fixed_pk_resolution variable which is silently clipped to 72--2400 dpi and isn't accessible. But \pdfpkresolution remains at its original possibly out-of-range value, so one can't rely on it. This would affect about the following variables: \pdfdecimaldigits \pdfpkresolution \pdfimageresolution \pdfgamma \pdfimagegamma \pdfimagehicolor \pdfimageapplygamma Regards, Hartmut

4 4

a dream about options
by Pawel Jackowski 15 Nov '05

15 Nov '05

Hello, I suppose the issue was discussed before but couldn't find that is archives. Making high level macros in (pure) TeX encounters problem of optionality; the number of macro `properties' (agruments) is limited and making parameters *optional* needs some trickery. And yes, syntax like \macro[...,...,...]{...} is quite robust ConTeXt or LaTeX but is also time, space and resource consuming. Must be, since there is no robust way to build macros with parameters organized similar to <rulespec>, \macro key1 val1 key2=val2 key3{val3} ... at least not with optional key-val pairs. In pure TeX, such optional parameter text is rather exceptional, but in pdfTeX it becomes quite common. Would it be possible to implement some extension to definition building mechanism that allows to create macros with rulespec-like shape? I admit for the moment I can't even imagine a consistent syntax for such a feature. Macro parameters rules are Knuthish enough :) Regards, -- Pawe/l Jackowski P.Jackowski(a)gust.org.pl

5 10

[ pdftex-Bugs-450 ] error copying .pfb font to pdf
by noreply＠sarovar.org 10 Nov '05

10 Nov '05

Bugs item #450, was opened at 2005-11-09 20:33 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=450&group_id=106 Category: Fonts Group: v1.21a Status: Open >Resolution: Fixed Priority: 5 Submitted By: Christian Heusquin (chrisheus) Assigned to: Hartmut Henkel (hhenkel) Summary: error copying .pfb font to pdf Initial Comment: I'm an user of MikTeX package (vers 2.4) and uses pdfLaTeX on a regular basis. I bought a Poscript Type 1 Sabon Font family from Monotype and when using the italic (msbri8a.pfb) pdfeTex has a problem and stops writing output. The pdf is unusable. I checked the .pfb and its Ok. I can use it with Latex but then I have other problems (graphics, and symbol fonts). Here is an extract of the log file: This is pdfeTeX, Version 3.141592-1.21a-2.2 (MiKTeX 2.4) (preloaded format=latex 2005.11.7) 9 NOV 2005 19:41 . . . {8r.enc}<C:\localtexmf\fonts\type1\monotype\s abon\msbr8a.pfb><C:\localtexmf\fonts\type1 \monotype\sabon\msbri8a.pfb Warning: pdflatex (file C:\localtexmf\fonts\type1 \monotype\sabon\msbri8a.pfb): 532 bytes more than expected were ignored Error: pdflatex (file C:\localtexmf\fonts\type1 \monotype\sabon\msbri8a.pfb): un expected end of file ==> Fatal error occurred, the output PDF file is not finished! ---------------------------- If you need, I have all the necessary .pfb, .afm, .tfm, .fd, .vf, .map, .enc, .sty and a short .tex file to reproduce the problem. Anyway I attach them so you have them if you need. Many thanks in advance ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-11-09 23:29 Message: Logged In: YES user_id=929 seems the font file msbri8a.pfb is broken. It is missing the line mark currentfile closefile near the end. The other fonts in this family are ok! With the missing line, pdftex can't find the end of the eexec section. The above statements are normally part of any Type1 font, see the Type1 specification by Adobe. Just compare your font with other .pfb's after disassembling by t1disasm. Add above line at the right place, make a new .pfb by t1asm -b and pdftex will happily use the font. And complain to the font manufacturer! :-) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-11-09 20:53 Message: Logged In: YES user_id=929 it's likely that this is solved in a newer version. I can't check without the font. Try to retest on 1.30.4 from MiKTeX. Or you might send me the pack of test files to hartmut_henkel at gmx dot de. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=450&group_id=106

1 0