Hi, I just have found that a fix for xpdf-2.01 is available: CTAN:support/xpdf/xpdf-2.01-patch1 It is quite short, so I have added it to this mail. Thomas Index: GfxState.cc =================================================================== RCS file: /home/derekn/src/cvs/xpdf/GfxState.cc,v retrieving revision 1.52 retrieving revision 1.55 diff -c -r1.52 -r1.55 *** GfxState.cc 21 Nov 2002 18:55:57 -0000 1.52 --- GfxState.cc 16 Dec 2002 21:57:13 -0000 1.55 *************** *** 815,823 **** --- 815,833 ---- obj1.free(); if (!arr->get(2, &obj1)->isInt()) { error(-1, "Bad Indexed color space (hival)"); + delete baseA; goto err2; } indexHighA = obj1.getInt(); + if (indexHighA < 0 || indexHighA > 255) { + // the PDF spec requires indexHigh to be in [0,255] -- allowing + // values larger than 255 creates a security hole: if nComps * + // indexHigh is greater than 2^31, the loop below may overwrite + // past the end of the array + error(-1, "Bad Indexed color space (invalid indexHigh value)"); + delete baseA; + goto err2; + } obj1.free(); cs = new GfxIndexedColorSpace(baseA, indexHighA); arr->get(3, &obj1);
Hi Martin, When pdftex includes an invalid pdf file, it ends up in some ** waiting for input mode; this is probably a result from the fact that the xpdf error is not passed on to tex's own error handler. This also means that batchmode fails. I think that in the case of a problematic pdf file inclusion, a null object should be generated (or an xform with zero dimensions, or a zero last object pointer so that we can catch such errors) instead of entering some undefined state resulting in (1) infinite waiting in vatch mode and (2) an errorous file. Another improvement could be to let pdftex remove its own output file when it is invalid (no xref table). (or produce some simple empty file) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@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 -------------------------------------------------------------------------
On 2002-12-27 12:55:03 +0100, Hans Hagen wrote:
When pdftex includes an invalid pdf file, it ends up in some ** waiting for input mode; this is probably a result from the fact that the xpdf error is not passed on to tex's own error handler. This also means that batchmode fails.
Hu? Well, we run pdftex in nonstopmode (batchmode is too quiet), but I've never seen that phenomen. Could you send me a simple test case? [...]
Another improvement could be to let pdftex remove its own output file when it is invalid (no xref table). (or produce some simple empty file)
Yep. Noted for 1.11a :-) Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10
Hi,
pdfTeX's (teTeX-beta-20021221) precedence for font .map files is
different from dvips (my former mail to the pdftex list). Here is a
patch to file mapfile.c in the pdftexdir directory.
If, after the patch, you enable reading myfonts.map in the pdftex.cfg
file, a myfonts.map in a local working directory is read first, then
other myfont.map files, if they exist, in kpathsea sequence, and then
the main pdftex.map file. In case of conflicts, a local myfonts.map
entry overrides the others. This allows e. g. to do a quick local font
remapping for experiments. E. g. an entry
cmr10 CMR10
participants (4)
-
Hans Hagen -
Hartmut Henkel -
Martin Schroeder -
Thomas Esser