- ntg-pdftex - NTG Mailing Lists

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

04 Dec '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: v1.30.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) >Assigned to: Martin Schröder (oneiros) 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: Martin Schröder (oneiros) Date: 2005-12-04 15:12 Message: Logged In: YES user_id=421 This has been fixed in 1.30.5 ---------------------------------------------------------------------- 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-441 ] Debug output of makecfilename
by noreply＠sarovar.org 04 Dec '05

04 Dec '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: Image inclusion >Group: v1.30.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) >Assigned to: Martin Schröder (oneiros) 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

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

04 Dec '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: Closed 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

Xpdf 3.01pl1
by Martin Schröder 01 Dec '05

01 Dec '05

I'll investigate and do a 1.30.5 if needed. Best Martin ----- Forwarded message from "Derek B. Noonburg" <derekn(a)foolabs.com> ----- Date: 1 Dec 2005 19:55:28 -0000 Message-ID: <20051201195528.27062.qmail(a)foolabs.com> From: "Derek B. Noonburg" <derekn(a)foolabs.com> Subject: ANNOUNCE: Xpdf 3.01pl1 - a PDF viewer for X A new release of Xpdf is available to fix several security holes reported by iDEFENSE (CAN-2005-3193). The source code patch is available here: ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.01pl1.patch Updated binaries are available here: http://www.foolabs.com/xpdf/download.html - Derek ----- End forwarded message ----- -- http://www.tm.oneiros.de

1 0

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

27 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