October 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 05 Dec '05

05 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-Bugs-444 ] buffer overflow with \pdfmatch
by noreply＠sarovar.org 29 Oct '05

29 Oct '05

Bugs item #444, was opened at 2005-10-29 19:24 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: buffer overflow with \pdfmatch Initial Comment: % The new \pdfmatch primitive will run into a buffer overflow with strings % longer than 1023 characters: % % (I am using 1.30.3 with Thanh's patches from pdftex.sarovar.org/src, % compiled under cygwin.) \def\x{1,2,3,4,5,6,7,8,9,0,} \def\testlist{% ,\x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x00,}% 1024 \ifcase\pdfmatch{,1,}{\testlist}\relax \fi % Also, if the pattern is too long: %\ifcase\pdfmatch{\testlist}{1}\relax \fi \bye, Robert. PS: Is there a simple way to escape all regex special characters in a string? ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-29 21:08 Message: Logged In: YES user_id=929 see patch to utils.c. This makes makecstring() memory grow on demand. Also increase MAX_CSTRING_LEN in ptexmac.h to e. g. 10000000. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106

1 0

[ pdftex-Bugs-444 ] buffer overflow with \pdfmatch
by noreply＠sarovar.org 29 Oct '05

29 Oct '05

Bugs item #444, was opened at 2005-10-29 17:24 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: buffer overflow with \pdfmatch Initial Comment: % The new \pdfmatch primitive will run into a buffer overflow with strings % longer than 1023 characters: % % (I am using 1.30.3 with Thanh's patches from pdftex.sarovar.org/src, % compiled under cygwin.) \def\x{1,2,3,4,5,6,7,8,9,0,} \def\testlist{% ,\x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x00,}% 1024 \ifcase\pdfmatch{,1,}{\testlist}\relax \fi % Also, if the pattern is too long: %\ifcase\pdfmatch{\testlist}{1}\relax \fi \bye, Robert. PS: Is there a simple way to escape all regex special characters in a string? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106

1 0

documentation
by Reinhard Kotucha 28 Oct '05

28 Oct '05

Hi, is it possible to make documentation for pdftex and hyperref accessible to texdoc(1)? While the pdftex manual can be accessed if people know that it is called "pdftex-a" (it sounds like a joke if people say "Read the documentation" on a mailing list), the hyperref manual is inaccessible. On my system I get: $ locate manual.pdf | wc -l 164 Is it possible to solve it before TL is released? I would expect that "texdoc <packagename>" or "texdoc <progname>" provides something useful. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

7 11

Re: [tex-live] documentation
by Heiko Oberdiek 28 Oct '05

28 Oct '05

On Thu, Oct 27, 2005 at 03:00:15PM -0300, George White wrote: > Quoting Heiko Oberdiek <oberdiek(a)uni-freiburg.de>: > > > On Thu, Oct 27, 2005 at 07:00:54AM -0300, George White wrote: > > > > > Quoting Reinhard Kotucha <reinhard.kotucha(a)web.de>: > > > > > > > >>>>> "Karl" == Karl Berry <karl(a)freefriends.org> writes: > > > > > > > > > Well, if you can make a patch for the texdoc .dat file, I can > > > > > install it :). > > > > > > > > I fear that, unlike texdoctk, texdoc simply uses ls-R as a database. > > > > > > > > Thomas recently mentioned that one can define aliases, but I think > > > > that it is best if the authors provide fixes. > > > > > > It may be best, but is it practical? Will aliases help when you have > > > dozens of manual.pdf files? > > > > > > I suspect it is much easier to make changes in texdoc to support > > > "package/manual". On systems that support symlinks one could process > > > the doc tree to make package/manual.pdf -> package/package.pdf. > > > > And how you want to solve the problem of several documentation > > files? One symlink can point to just *one* file. > > Hopefully the others will at least be be mentioned in manual.pdf, Perhaps somewhere, in many cases not: * Different language versions: manual-en.pdf, manual-de.pdf, ... The normal expectation is then, that the users that open manual-en.pdf see the English version, readers of manual-de.pdf the German version, ... It would be a surprise, if theses manual versions start with a list of links to the different language versions. And which language should be choosen for this part? * Separate source code documentation and user manual, articles, slides, ... > but > this emphasizes the point that, for many packages, the directory in the > doc tree is the real connection to the package and may contain multiple files > with generic names like manual.pdf that may indicated the type of content but > tell you nothing about the package. But you still have the directory! The current texdoc behaviour is not appropriate for documentation that consist of several files: TDS:doc/.../package/package.pdf % for manual TDS:doc/.../package/package.pdf % for source code doc -> you are running out of names -> it is not clear, what the type of content is -> redundant naming, you could strip the directory "package" level A more naturally naming convention is: TDS:doc/.../package/manual.pdf TDS:doc/.../package/source.pdf Possible ways to solve the texdoc problem: * The package author offers a document for texdoc with standardized name (e.g. texdoc-index.[pdf,html,...] that contains explanations and links to the package's documentation. TDS:doc/.../packageA/texdoc-index.pdf TDS:doc/.../packageA/manual.pdf TDS:doc/.../packageA/source.pdf TDS:doc/.../packageB/texdoc-index.html TDS:doc/.../packageB/manual.html TDS:doc/.../packageB/README Then texdoc also looks for this document (texdoc-index.*). * Or a separate data base is maintained with package overviews. (e.g. source in XML. PDF and HTML are automatically generated.) source/packageA.xml source/packageB.xml pdf/packageA.pdf pdf/pacakgeB.pdf html/packageA.html html/packageB.html Then texdoc also looks for this database. * Or texdoc shows the directory and let the user decide, which file\ he wants. * ... Yours sincerely Heiko <oberdiek(a)uni-freiburg.de>

1 0

[Fwd: Producing Tagged PDF or PDF/A from LaTeX (ISO 19005-1)]
by Rolf Niepraschk 25 Oct '05

25 Oct '05

-------- Original-Nachricht -------- Betreff: Producing Tagged PDF or PDF/A from LaTeX (ISO 19005-1) Datum: 25 Oct 2005 13:36:19 GMT Von: n05W43+mgk25(a)cl.cam.ac.uk (Markus Kuhn) Organisation: University of Cambridge, England Newsgruppen: comp.text.tex Is there any solution on the horizon for turning a LaTeX document into a "Tagged PDF" file, that is a PDF 1.4 file written in such a way that the underlying Unicode plaintext in it can be recovered smoothly (for easier searching, cut&paste, NLP parsing, Braille, speech synthesis, etc.). Background: The new international standard ISO 19005-1:2005 defines an "electronic document file format for long-term preservation" called PDF/A-1. This is basically a subset of PDF 1.4, with lots of nasty and dangerous stuff (JavaScript, external references, missing fonts, encryption, etc.) removed and various historic ambiguities in the PDF spec clarified. It was mainly developed to make PDF useful for legal-deposit purposes, All very good and commendable for anyone using PDF in electronic publishing and archival applications. However: Full compliance with the PDF/A-1 format requires that "Tagged PDF" is used, such that the underlying plaintext remains accessible for further processing. How could I do that from LaTeX? Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain

1 0

[ pdftex-Patches-443 ] 512 zeros in Type1 fonts not copied anymore
by noreply＠sarovar.org 24 Oct '05

24 Oct '05

Patches item #443, was opened at 2005-10-24 22:41 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=443&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: 512 zeros in Type1 fonts not copied anymore Initial Comment: When embedding Type1 fonts in PDF files, it is not needed to copy the trailing 512 zeros; they are redundant. This has been suggested in the paper "Two Diet Plans for Fat PDF" by Thomas A. Phelps and Robert Wilensky. Reduces file size a little. Then /Length3 = 0, see Table 5.24 in the PDF Ref. v. 1.6. The tiny patch to writet1.c does this for pdfTeX. No change in the dvips portion. In the patch also the font matrix transform is streamlined by use of generic transform macros. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=443&group_id=106

1 0

[ pdftex-Bugs-441 ] Debug output of makecfilename
by noreply＠sarovar.org 22 Oct '05

22 Oct '05

Bugs item #441, was opened at 2005-10-22 09:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=441&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Debug output of makecfilename Initial Comment: Hello, since pdfTeX 1.30.4, e.g. \pdfximage prints the file name twice, the first time stderr is used and messes up the output, e.g.: <screen_output lines="8"> This is pdfTeX, Version 3.141592-1.30.4 (Web2C 7.5.5) (./test.tex (./dir.tex antrschl.jpg [1 <./antrschl.jpg>] console.jpg [1 <./console.jpg>] img002.jpg [1 <./img002.jp g>]) ) Output written on test.pdf (3 pages, 451963 bytes). Transcript written on test.log. </screen_output> The line break in "<.\img002.jpg>" looks funny. The reason is some debug output in function makecfilename of utils.c: fprintf(stderr, " %s\n", name); Patch attached that removes that line. (With comment that at least marks the incompatibiliy introduced in 1.30.4 regarding file names, but that is another topic). Output after the patch is applied: <screen_output lines="5"> This is pdfTeX, Version 3.141592-1.30.4 (Web2C 7.5.5) (./test.tex (./dir.tex [1 <./antrschl.jpg>] [1 <./console.jpg>] [1 <./img002.jp g>]) ) Output written on test.pdf (3 pages, 451963 bytes). Transcript written on test.log. </screen_output> Perhaps the output is messed up by the web interface of the bug report system. There should be five lines. The funny line break in "<.img002.jpg>" is now the normal TeX line break because of screen line. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=441&group_id=106

1 0