Created attachment 6329 [details] first sample I have two PDF files that have small square in top-left corner. When converting either one of these PDFs to TIF (or jpg) I get empty page - squares are missing. Here is the command line I used: gswin32c -q -sDEVICE=tiffg4 -sOutputFile=res2.tif -dBATCH -dNOPAUSE nonempty2.pdf
Created attachment 6330 [details] second sample
This appears to be an issue with a missing glyph. Older versions of Ghostscript (e.g. 9.63) output a file similar to acrobat, but I believe that the blank 8.71 output is preferable (I'm searching for the applicable rev now and will post the log message). However, current head produces an error when reading this file, presumably because of FreeType: marcos@macbookpro:[6]% gsheadtiff ./nonempty1.pdf GPL Ghostscript SVN PRE-RELEASE 8.72 (2010-02-11) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 Error: /rangecheck in --run-- Operand stack: --dict:7/16(L)-- R8 9.96 FontObject --dict:9/18(L)-- --dict:9/18(L)-- 173 --dict:9/18(L)-- --nostringval-- (\000\004\000 \000\000\000\004\000\004\000\001\000\000\357\377\377\377\000\000\360\000\377\377\000\000\000\001\000\004\000\000) 32 2 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1894 1 3 %oparray_pop 1893 1 3 %oparray_pop 1877 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 1 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- 2 2 1 --nostringval-- %for_pos_int_continue 1 1 0 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- Dictionary stack: --dict:1153/1684(ro)(G)-- --dict:1/20(G)-- --dict:82/200(L)-- --dict:82/200(L)-- --dict:108/127(ro)(G)-- --dict:292/300(ro)(G)-- --dict:22/25(L)-- --dict:6/8(L)-- --dict:21/40(L)-- --dict:5/5(L)-- --dict:8/15(L)-- --dict:40/50(ro)(G)-- --dict:42/80(L)-- Current allocation mode is local Last OS error: 2 GPL Ghostscript SVN PRE-RELEASE 8.72: Unrecoverable error, exit code 1 Exit 1 marcos@macbookpro:[7]%
The applicable revision is r8631. You can revert to the old behaviour, which will print small squares by adding -dRENDERTTNOTDEF to the command line. For reference here is the entire log message, justifying the change: r8631 | ken | 2008-04-09 08:28:45 -0700 (Wed, 09 Apr 2008) | 58 lines Fix (PDF interpreter): Optionally omit rendering of /.notdef glyphs from TrueType fonts. Details: Bug #689757 "Extra square characters rendering PDF file". When rendering glyphs in a TrueType font, and the glyph is not present in the font, GS (correctly) draws the /.notdef glyph (or glyph ID 0) instead. Under some conditions, however, Acrobat does not do so, but does leave a 'gap' apparently corresponding to the width of the original glyph (if a /Widths array is present), or the width of the /.notdef glyph. Exactly what causes Acrobat to do this is unclear. In the thread for bug 687929 it was suggested that Acrobat was substituting a standard font with a /.notdef defined as an empty glyph. However changing the font name had no effect. Using a pdfwrite-produced PDF file, if I remove the symbolic flag from the font, and any direct reference to /.notdef in the Encoding /Differences array, then Acrobat does not display the /.notdef glyph. However, starting with a Distiller-produced PDF file, and either altering the font to symbolic, or adding a direct /.notdef to the Encoding, or both, makes no difference, Acrobat still does not render the /.notdef glyph. The behaviour of Acrobat is probably technically incorrect, but we need to attempt to render files similarly, if at all possible. However, since the appearance of a /.notdef is usually indicative of an error, this has been made optional. We can't substitute a space glyph for the /.notdef as has been suggested, because we can't guarantee the existence of a space glyph (eg Arabic, which has no space) and can't guarantee that the space makes no marks even if present. However, we still want to apply the Width of the glyph, so that spacing works out correctly, if we simply skip the /.notdef glyph then words may collide, as in the case of the file for this bug. This means we must run the glyph through the text routines, as the width is applied there. A new user parameter '/RenderTTNotdef' controls whether glyphs named /.notdef in a TrueType font should be rendered or not. This is also controlled by a systemdict parameter /RENDERTTNOTDEF. The PDF interpreter will set the user parameter to the same value as the systemdict parameter, allowing this to be controlled from the GS command line. The user parameter defaults to 'true' which renders TrueType /.notdef glyphs (so that these are properly rendered in PostScript), the RENDERTTNOTDEF systemdict parameter defaults to 'false', which is used by the PDF interpreter to set the user parameter, and therefore disables rendering of TT /.notdef glyphs in PDF files.
I'm changing the bug summary to better reflect the real problem with the sample files, that the current head generates an error but gs8.71 does not.
(In reply to comment #3) > The applicable revision is r8631. You can revert to the old behaviour, which > will print small squares by adding -dRENDERTTNOTDEF to the command line. > Thanks - -dRENDERTTNOTDEF works great!
re-assigning to Chris.
Actually, this fails even if you set DisableFAPI to true, so I think this is actually a PDF interpreter problem and I'm CC'ing Alex. The stack trace at the time looks more like a PDF itnerpreter problem too.
Created attachment 6360 [details] possible patch This is caused the fix for Bug 691326 ( http://bugs.ghostscript.com/show_bug.cgi?id=691326 ) which results in attempting to read index 32 from a string of length 32. By digging through what the original code did, and the revised code, it *looks* like the attached patch (gs_ttf.ps.patch) solves this issue, and allows the original 691326 job to complete, too.
*** Bug 691508 has been marked as a duplicate of this bug. ***
fixed in r11617