- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-199 ] font expansion: characters may vanish
by noreply＠sarovar.org 31 Jan '05

31 Jan '05

Bugs item #199, was opened at 2004-09-23 02:43 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=199&group_id=106 Category: hz Group: v1.20a Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody (None) Assigned to: The Thanh Han (hanthethanh) Summary: font expansion: characters may vanish Initial Comment: For extremely large shrink values, characters may not be visible in the pdf output (although the fonts seem to be embedded), e.g. in the following file: %---------------------------------------------- \hsize220pt \pdfadjustspacing=2 \font\testfont=cmr17 at 90pt\testfont \pdffontexpand\font 0 1000 100 autoexpand \efcode\font`\s=500 \efcode\font`\e=500 \efcode\font`\y=500 see what you get\penalty-10000 \bye %---------------------------------------------- or even worse: %---------------------------------------------- \hsize180pt \pdfadjustspacing=2 \font\testfont=cmr17 at 90pt\testfont \pdffontexpand\font 0 1000 100 autoexpand see what you get\penalty-10000 \bye %---------------------------------------------- The font `cmr17-Extend_100' will not be visible. I only managed to achieve this effect with extremely large font sizes, which may or may not be related (it could also be that I didn't find the `magic' \hsize). If you force the characters to shrink even more, for example by setting \hsize to 120pt in the latter test file, the unexpanded font will be used, thus printing the characters over each other. Regards, Robert <w.m.l(a)gmx.net> PS. I didn't bother to create expanded fonts, so I cannot tell whether it depends on the autoexpand feature. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-01-31 07:29 Message: Logged In: NO It seems as if Hartmut's patch hasn't been applied, as the following test file will still produce incorrect output for both pdftex 1.20b and 1.20c-beta: %------------------------------------------------- \pdfadjustspacing=2 \font\testfont=cmr10 \testfont \pdffontexpand\font 0 1000 100 autoexpand \hsize40pt OK: text text text text\break not OK: text text text text\break \bye %------------------------------------------------- Regards, Robert <w.m.l[at]gmx.net> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 20:23 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-10-02 00:11 Message: Logged In: YES user_id=929 tiny patch tries to solve this bug. See README and PDF test file included. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-10-01 20:47 Message: Logged In: YES user_id=421 I you mean the effect in the attached pdf: This is either a bug in Jaws (png attached) or a bug in pdftex. gs 8.30, harlequin 5.3.4a and AR 5 all display the file distorted. :-( ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2004-09-29 03:36 Message: Logged In: NO But the problem I mentioned above in the last paragraph isn't related to Acrobat Reader, is it? % ------------------------------------------ \hsize35pt \pdfadjustspacing=2 \font\testfont=cmr12\testfont \pdffontexpand\font 0 1000 100 autoexpand text text text text\penalty-10000 \bye % ------------------------------------------ Seems like a sanity check is missing somewhere. If my guess is right, pdftex tries to use the font `cmr17-Extend_0', which (incorrectly) translates into the base font. What it should probably do is use the smallest available expanded font, i.e. in this case Extend_100, and make the line overfull. Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-09-27 20:57 Message: Logged In: YES user_id=421 An Acrobat Reader bug. :-) ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2004-09-23 03:32 Message: Logged In: NO Obviously, I filed this report too early. Sorry about that. It is not a pdftex bug, but appears to be a bug in Acrobat Reader 6. (Just to tell you what I saw:) At zoom level 200% or larger, the font most shrunk (Extend_100) is not visible on screen. That is, in the first example, I only see "See y e", in the second, nothing at all. However, if I zoom out, the characters re-appear. Sorry for not zooming out earlier. Regards, Robert. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=199&group_id=106

1 0

crashing png graphic
by h h extern 30 Jan '05

30 Jan '05

3 2

[ pdftex-Bugs-262 ] Type42 inclusion
by noreply＠sarovar.org 29 Jan '05

29 Jan '05

Bugs item #262, was opened at 2005-01-21 10:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106 Category: Fonts Group: v1.20b Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Hartmut Henkel (hhenkel) Summary: Type42 inclusion Initial Comment: Hello, Trying to get ttf fonts working both with dvips and pdflatex I experimented with converting the ttf to Type42 using fontforge, disassembling it via t1disasm and creating a pfb with t1asm. The resulting pfb is included via dvips and both ghostscript and distiller can interpret it. Unfortunately, pdflatex gives me the following error trying to include the pfb: Error: pdftex (file FranklinGothic-Medium.pfb): unexpected end of file ==> Fatal error occurred, the output PDF file is not finished! Cheers, Michael ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-29 23:08 Message: Logged In: YES user_id=929 The attached simple patch for writet1.c checks the /FontType key and if it's 42, pdfTeX exits with an error message: Error: pdfetex (file ./foo.pfb): Type42 fonts unsupported by pdfTeX This could be modified so that an error is given if it's _not_ Type1.But which font types _are_ supported? Another way might be to check the header comment for "%!PS-AdobeFont" or "%!FontType1". But all this can be cheated, and there might be fonts with wrong comment lines floating around... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-01-27 10:46 Message: Logged In: YES user_id=421 If we decide that Type42 fonts are unsupported, pdftex should at least raise a clear error when it finds them. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2005-01-27 10:14 Message: Logged In: YES user_id=710 Hi, pdftex doesn't support Type42 fonts and probably won't, unless someone else implements it, as I see little sense in making it work. Thanh ---------------------------------------------------------------------- Comment By: Michael Zedler (zedler) Date: 2005-01-22 14:36 Message: Logged In: YES user_id=2197 Hello, dvips also chokes if it tries to subset the font, including it completely works though. I don't really know if it's worth implementing support for Type42 in pdftex, I wouldn't use it either -- I just tried to find out if dvips+ttf without loss of hinting information is really a no-go as often claimed. Result was: no, no problem ;-) Cheers, Michael ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-21 23:13 Message: Logged In: YES user_id=929 >From inspection of disassembled font FranklinGothic-Medium.pfb it seems that this Type 42 font is incompatible with writet1.c.Maybe handling Type 42 fonts is not implemented in general? The problem is, that after scanning of the /Encoding array the function t1_subset_ascii_part() is waiting for the string "currentfile eexec" while running the {...} while (t1_in_eexec == 0); loop. But in the Type 42 font there follows the /sfnts key and the Type 42 program is scanned. Then, as t1_in_eexec will never be changed, the while loop runs into the end of the font file, resulting in the error. Looks like it would require quite some change in writet1.c to handle these Type 42 fonts. Would such a change make sense, given that this type of font appears rather seldomly? I also wonder how it should work in dvips, as it uses the same writet1.c, and here also the same error message appears. Also dvipdfm can't process the font, it just hangs. All on teTeX-2.99.9 debian woody i686. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Michael Zedler (zedler) Date: 2005-01-21 15:57 Message: Logged In: YES user_id=2197 You may find the pfb, tfm, vf at http://www.hft.ei.tum.de/mz/test_t42.zip I suppose the error is due to pdftex trying to subset the Type42 font. Cheers, Michael ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-01-21 10:58 Message: Logged In: YES user_id=421 Please include some test files; at least the pfb is needed. Also please login when commenting on this or any other bug. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106

1 0

[ pdftex-Patches-259 ] Expanded png inclusion support
by noreply＠sarovar.org 29 Jan '05

29 Jan '05

Patches item #259, was opened at 2005-01-11 16:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) Summary: Expanded png inclusion support Initial Comment: The attached zip file contains a change file for all pdftex's (to be applied *after* hz.cg) and a completely new writepng.c ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106

4 3

Re: [pdftex] pdfeTeX: bad interaction of \pdfstartlink...\pdfendlink with \beginR...\endR
by The Thanh Han 28 Jan '05

28 Jan '05

Hi, I have no idea how to solve it. Perhaps someone with better understanding of etex internals can help? Thanh On Tue, Dec 28, 2004 at 11:51:40PM +0100, Hartmut Henkel wrote: > On Sun, 26 Dec 2004, Vladimir Volovich wrote: > > > There seems to be a bug in interaction of right-to-left features of > > eTeX with pdflink features of pdftex. > > yes, tried to localize it: When the horizontal list is reversed > (left/right swapped) by function reverse(), so are the \pdfstartlink and > \pdfendlink whatsits. Then \pdfendlink happens before \pdfstartlink, > causing the error. Tried to swap links from/to both nodes after > reversal, so that the start/end sequence is right, but then the 2nd > error appears: > > > This can't happen (copying). error: > > This seems to be due to a missing style_node: case in @ @<Case statement > to copy...@>= which might be result from some math node that is > artificially added during reversing the list or not? Copying also the > style_node makes it run. But no idea whether that's the right way to do > it. And there might be more cases like \pdfstartlink and \pdfendlink > that might need a fix. > > Regards, Hartmut > > _______________________________________________ > pdftex mailing list > pdftex(a)tug.org > http://tug.org/mailman/listinfo/pdftex >

1 0

pdfcurpageref -- does it make sense?
by The Thanh Han 28 Jan '05

28 Jan '05

Hi, I wonder how Hans and other would solve this problem. tex doesn't have a concept of `current page' while processing the input token list. The page number can be detected reliably only using 2nd pass processing, as the page where some material ends up is known only at shipping phase. It is possible to provide a primitive which returns the *next* page object number, but IMHO it doesn't make any sense. Thanh > Feature Requests item #252, was opened at 2004-12-14 16:47 > You can respond by visiting: > http://sarovar.org/tracker/?func=detail&atid=496&aid=252&group_id=106 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Nobody (None) > Assigned to: Nobody (None) > Summary: current page object number > > Initial Comment: > Dear PdfTeX-developpers, > > sometimes the reference to the current page object is > needed within the implementation of another pdf object. > > As an example may serve the `Screen Annotation' > several interactive PDF features rely on. > > Currently, the \pdfpageref command, which takes a page > number as argument, can be used for this purpose. > > It is difficult, however, to maintain a reliable page > counter as the attached file demonstrates. It uses the > `everyshi' package by M. Schroeder. > > On the first line of every page a wrong object number > is being output. > > It would be very nice to have a command like > \pdfcurrentpageref to be implemented in pdftex. > > Thanks for your attention, > > Alexander Grahn

2 2

[ pdftex-Bugs-262 ] Type42 inclusion
by noreply＠sarovar.org 27 Jan '05

27 Jan '05

Bugs item #262, was opened at 2005-01-21 10:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106 >Category: Fonts >Group: v1.20b Status: Open Resolution: None >Priority: 3 Submitted By: Nobody (None) >Assigned to: Hartmut Henkel (hhenkel) Summary: Type42 inclusion Initial Comment: Hello, Trying to get ttf fonts working both with dvips and pdflatex I experimented with converting the ttf to Type42 using fontforge, disassembling it via t1disasm and creating a pfb with t1asm. The resulting pfb is included via dvips and both ghostscript and distiller can interpret it. Unfortunately, pdflatex gives me the following error trying to include the pfb: Error: pdftex (file FranklinGothic-Medium.pfb): unexpected end of file ==> Fatal error occurred, the output PDF file is not finished! Cheers, Michael ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2005-01-27 10:46 Message: Logged In: YES user_id=421 If we decide that Type42 fonts are unsupported, pdftex should at least raise a clear error when it finds them. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2005-01-27 10:14 Message: Logged In: YES user_id=710 Hi, pdftex doesn't support Type42 fonts and probably won't, unless someone else implements it, as I see little sense in making it work. Thanh ---------------------------------------------------------------------- Comment By: Michael Zedler (zedler) Date: 2005-01-22 14:36 Message: Logged In: YES user_id=2197 Hello, dvips also chokes if it tries to subset the font, including it completely works though. I don't really know if it's worth implementing support for Type42 in pdftex, I wouldn't use it either -- I just tried to find out if dvips+ttf without loss of hinting information is really a no-go as often claimed. Result was: no, no problem ;-) Cheers, Michael ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-21 23:13 Message: Logged In: YES user_id=929 >From inspection of disassembled font FranklinGothic-Medium.pfb it seems that this Type 42 font is incompatible with writet1.c.Maybe handling Type 42 fonts is not implemented in general? The problem is, that after scanning of the /Encoding array the function t1_subset_ascii_part() is waiting for the string "currentfile eexec" while running the {...} while (t1_in_eexec == 0); loop. But in the Type 42 font there follows the /sfnts key and the Type 42 program is scanned. Then, as t1_in_eexec will never be changed, the while loop runs into the end of the font file, resulting in the error. Looks like it would require quite some change in writet1.c to handle these Type 42 fonts. Would such a change make sense, given that this type of font appears rather seldomly? I also wonder how it should work in dvips, as it uses the same writet1.c, and here also the same error message appears. Also dvipdfm can't process the font, it just hangs. All on teTeX-2.99.9 debian woody i686. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Michael Zedler (zedler) Date: 2005-01-21 15:57 Message: Logged In: YES user_id=2197 You may find the pfb, tfm, vf at http://www.hft.ei.tum.de/mz/test_t42.zip I suppose the error is due to pdftex trying to subset the Type42 font. Cheers, Michael ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-01-21 10:58 Message: Logged In: YES user_id=421 Please include some test files; at least the pfb is needed. Also please login when commenting on this or any other bug. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106

1 0

[ pdftex-Bugs-242 ] Assertion failure when including pdf file without embedded fonts
by noreply＠sarovar.org 27 Jan '05

27 Jan '05

Bugs item #242, was opened at 2004-12-02 15:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=242&group_id=106 Category: Fonts Group: v1.20b >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody (None) Assigned to: Hartmut Henkel (hhenkel) Summary: Assertion failure when including pdf file without embedded fonts Initial Comment: See included shell script ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-01-21 00:38 Message: Logged In: NO I’ve already contacted the owner of LJBOOK.com and he doesn’t see a problem with it on his end. I don’t know if it has something to do with the PDF or not. I’m writing in English in the United States. I have Adobe Reader 6.0. I’ve tried multiple times to make a copy of my Livejournal through ljbook.com without success. I have a lot of entries, all “friends only” or “private” from 2002 to 2005. When I make the copy of my journal into the PDF, a majority of the words with apostrophes and “quotes” like I’ll, Don’t, She’s, Couldn’t, That’s, How’s, etc. gets replaced by a symbol that looks like a weird letter “a” with something on top of it. The actual apostrophe gets replaced with the symbol and makes those words look separated and weird. I’ve tried multiple times and the same problem occurs. It shows more in the years 2004 and 2005 but it does show in the 2002 and 2003 entries also, when it’s in the PDF. I also tried those years on its own and get the same problem. I have the “Auto-convert older entries from” set correctly and the encodings set properly and still have the problem. Could you please help me out? I’m really in need to backup my journal and don’t know why almost all the words that have apostrophes are turning the apostrophes into that symbol when it’s in the PDF format. When it’s in my regular Livejournal, it’s perfect and doesn’t show that. Just when it’s backed up into the PDF. Please help me out. I would really appreciate it a lot. Thank you very much in advance. liveatshea(a)hotmail.com ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-13 00:19 Message: Logged In: YES user_id=929 This is a patch for file mapfile.c of pdftex-1.20, cleaning up a few bugs introduced by patch-242c. The obsolete qualifier "!" is removed from scanning. Blank handling between qualifiers "<", "<<" and .enc and f_name names has been re-introduced, to make it backward compatible and compatible to the preferences of map file writers. Please test carefully. Help welcome. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Thomas Esser (tetex) Date: 2004-12-03 00:30 Message: Logged In: YES user_id=1230 I can reproduce this bug after updmap --setoption pdftexDownloadBase14 false Thomas ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=242&group_id=106

1 0

[ pdftex-Bugs-262 ] Type42 inclusion
by noreply＠sarovar.org 27 Jan '05

27 Jan '05

Bugs item #262, was opened at 2005-01-21 09:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Type42 inclusion Initial Comment: Hello, Trying to get ttf fonts working both with dvips and pdflatex I experimented with converting the ttf to Type42 using fontforge, disassembling it via t1disasm and creating a pfb with t1asm. The resulting pfb is included via dvips and both ghostscript and distiller can interpret it. Unfortunately, pdflatex gives me the following error trying to include the pfb: Error: pdftex (file FranklinGothic-Medium.pfb): unexpected end of file ==> Fatal error occurred, the output PDF file is not finished! Cheers, Michael ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2005-01-27 09:14 Message: Logged In: YES user_id=710 Hi, pdftex doesn't support Type42 fonts and probably won't, unless someone else implements it, as I see little sense in making it work. Thanh ---------------------------------------------------------------------- Comment By: Michael Zedler (zedler) Date: 2005-01-22 13:36 Message: Logged In: YES user_id=2197 Hello, dvips also chokes if it tries to subset the font, including it completely works though. I don't really know if it's worth implementing support for Type42 in pdftex, I wouldn't use it either -- I just tried to find out if dvips+ttf without loss of hinting information is really a no-go as often claimed. Result was: no, no problem ;-) Cheers, Michael ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-21 22:13 Message: Logged In: YES user_id=929 >From inspection of disassembled font FranklinGothic-Medium.pfb it seems that this Type 42 font is incompatible with writet1.c.Maybe handling Type 42 fonts is not implemented in general? The problem is, that after scanning of the /Encoding array the function t1_subset_ascii_part() is waiting for the string "currentfile eexec" while running the {...} while (t1_in_eexec == 0); loop. But in the Type 42 font there follows the /sfnts key and the Type 42 program is scanned. Then, as t1_in_eexec will never be changed, the while loop runs into the end of the font file, resulting in the error. Looks like it would require quite some change in writet1.c to handle these Type 42 fonts. Would such a change make sense, given that this type of font appears rather seldomly? I also wonder how it should work in dvips, as it uses the same writet1.c, and here also the same error message appears. Also dvipdfm can't process the font, it just hangs. All on teTeX-2.99.9 debian woody i686. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Michael Zedler (zedler) Date: 2005-01-21 14:57 Message: Logged In: YES user_id=2197 You may find the pfb, tfm, vf at http://www.hft.ei.tum.de/mz/test_t42.zip I suppose the error is due to pdftex trying to subset the Type42 font. Cheers, Michael ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-01-21 09:58 Message: Logged In: YES user_id=421 Please include some test files; at least the pfb is needed. Also please login when commenting on this or any other bug. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106

1 0

Fwd: xpdf library bug? (fwd)
by Hartmut Henkel 26 Jan '05

26 Jan '05

---------- Forwarded message ---------- Date: Wed, 26 Jan 2005 16:19:22 -0500 From: Martin Otte <otte(a)duke.edu> To: Hartmut Henkel <hartmut_henkel(a)gmx.de> Cc: karl(a)freefriends.org, Gerben Wierda <Gerben.Wierda(a)rna.nl> Subject: Fwd: xpdf library bug? Hi, I noticed in the latest pdftex-1.20c-beta-20050121 is a patch that I made to the file FoFiType1.cc which corrects a seg-fault in pdftex that occurs when including a document with the Mathematica fonts. It is probably preferable to instead use the patch from the pdf maintainer, which should be included with this email. If you have already made this change, then please disregard my email. Thanks, Martin Otte Begin forwarded message: > From: "Derek B. Noonburg" <derekn(a)foolabs.com> > Date: January 19, 2005 12:39:17 AM EST > To: karl(a)freefriends.org > Cc: Gerben.Wierda(a)rna.nl, frank(a)wizards.de, andrew(a)stone.com, > otte(a)duke.edu > Subject: Re: xpdf library bug? > Reply-To: "Derek B. Noonburg" <derekn(a)foolabs.com> > > On 12 Jan, Karl Berry wrote: >> Greetings, >> >> The tex-live list got this bug report regarding the xpdf library. >> You can get the attachments from >> http://tug.org/pipermail/tex-live/2005-January/007617.html >> >> Thanks, >> karl >> >> Subject: pdflatex segmentation fault and patch to fix >> From: "Martin Otte" <otte(a)duke.edu> >> Date: Tue, January 11, 2005 23:40 >> To: gerben.wierda(a)rna.nl >> >> Hi, >> >> Thanks for your excellent packaging of tex/latex for the mac. >> >> I am using the TeX Live 2004 and teTeX 3 distribution from the tex >> i-package released on 2004/12/01. >> >> With this i-package, pdflatex always seg-faults for me when I include >> pdf >> figures generated using the PStill postscript-to-pdf converter. These >> pdfs open fine with Acrobat and Preview. I downloaded the final TeX >> Live >> 2004 source package, compiled pdfetex, ran the executable under a >> debugger and found that pdflatex crashes in the xpdf library. I then >> verified that these pdf's also crash the xpdf viewer on my linux >> machine. >> >> The crash occurs in the file libs/xpdf/fofi/FoFiType1.cc. There is a >> string buffer size variable "n" that becomes negative and causes the >> program to crash. I attached a patch that can be used from the libs >> directory of the TeX Live distribution that prevents the buffer size >> from >> becoming negative. > > That's a known bug in Xpdf 3.00. I'm attaching a patch file which > should fix it. > > - Derek

1 0