Created attachment 6670 [details] EPS file as input to pdfwrite Some EPS files are failing to convert to PDF using pdfwrite. This problem first appears in gs8.56 and remains in gs8.71. I attach an example EPS file to reproduce, made with GraphPad Prism. "C:\Program Files\gs\gs8.71\bin\gswin32c.exe" -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile="out.pdf" -- "in.eps" -c quit GPL Ghostscript 8.71 (2010-02-10) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. **** Warning: Some of the BoundingBox for the EPS file will be clipped. Use -dEPSCrop or -dEPSFitPage to avoid clipping. Error: /invalidfont in --xshow-- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval- - 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- fa lse 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_ pop --nostringval-- 1861 1 3 %oparray_pop 1755 1 3 %oparray_po p --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringv al-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- Dictionary stack: --dict:1157/1684(ro)(G)-- --dict:0/20(G)-- --dict:76/200(L)-- --dict:45 /80(L)-- Current allocation mode is local Current file position is 132813 GPL Ghostscript 8.71: Unrecoverable error, exit code 1
The problem is that the font really is invalid, for the purposes of copying, but not for the purposes of rendering. When copying the embedded type 42 (TrueType, nearly) fonts, pdfwrite starts by copying the /.notdef glyph, which is required for all fonts. It does this by finding the glyph ID (GID). To do that, it searches the CharStrings dictionary, in a type 42 font there should be a unique mapping between the glyph name and the GID. Each glyph should be stored by name in the CharStrings dictionary and the associated value should be the GID of that glyph. The PostScript code contains this: /CharStrings 256 dict dup begin 0 1 255{/.notdef exch def}for That treats the CharStrings dictionary as if it were an array (like the Encoding) and puts the glyph name /.notdef in the CharStrings dictionary 256 times, with the values 0 to 255. *HOWEVER* because dictionary entries are indexed by name, only the last entry actually has any effect, which stores the value 255 for the name /.notdef. This is technically invalid, since TrueType fonts have the /.notdef at GID 0. However, what's worse is that the font's sfnts array doesn't contain an entry for GID 255, so we are unable to copy that glyph when we try to copy the /.notdef entry, and so we emit an invalidfont error. This doesn't occur when rendering, because the /.notdef glyph is only used (as the name implies) when an error would otherwise occur because a glyph is not defined. Since all the glyphs used are defined in the font, the /.notdef is not used, and so no error occurs. Its trivial to show that if a glyph is used which is not present in the font, that an invalidfont also occurs when rendering. So fundamentally the problem is that the embedded fonts are invalid, which is why we generate an invalid font error. However Adobe Acrobat Distiller will create a PDF file from this input. In an attempt to duplicate this behaviour I have modified the font copying code so that if we fail to copy a glyph, and the glyph name is /.notdef and the GID is non-zero, we attempt to copy the glyph with GID 0 instead. If that fails we still error out. This works with the supplied file, but is not guaranteed to work under all conditions. However, since the font genuinely *is* faulty this is probably as good as we can get. David, given the content of the EPS file, and your address at 'biomedcentral' I assume you are registered users of the GraphPad Prism software which was used to create this file. I would very much appreciate it if you would raise this issue with technical support at GraphPad Software. If someone at GraphPad would like more details than are in this thread then I would be happy to discuss the issue further with them. It is possible that 5.03 of the software does fix this problem of course. Fixed in revision 11652, patch here: http://ghostscript.com/pipermail/gs-cvs/2010-August/011666.html