Bug 693711

Summary: pdfwrite segfault
Product: Ghostscript Reporter: Marc Lasson <marc.lasson+bugghostscript>
Component: PDF WriterAssignee: Ken Sharp <ken.sharp>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P4    
Version: 9.07   
Hardware: PC   
OS: Linux   
See Also: http://bugs.ghostscript.com/show_bug.cgi?id=694319
Customer: Word Size: ---
Attachments: a pdf file needed to reproduce the bug

Description Marc Lasson 2013-03-18 01:14:12 UTC 
Created attachment 9358 [details]
a pdf file needed to reproduce the bug

Hello, 

The following pdf 
    ftp://ftp.daimi.au.dk/BRICS/RS/94/7/BRICS-RS-94-7.pdf
makes ghostscript using pdfwrite segfault (on a page number depending on the version of ghostscript :)). 

I have tried on version 8.71, 9.04 and 9.07 on two different linux machine. 
To reproduce the bug, just execute : 
   gs -sDEVICE=pdfwrite -o test.pdf BRICS-RS-94-7.pdf 
and it will output : 
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.
Processing pages 1 through 45.
Page 1
Loading NimbusRomNo9L-Medi font from /usr/share/fonts/type1/gsfonts/n021004l.pfb... 4242320 2519135 3347784 1977253 3 done.
Loading NimbusRomNo9L-Regu font from /usr/share/fonts/type1/gsfonts/n021003l.pfb... 4288832 2653439 3347784 1992578 3 done.
Page 2
Substituting font Helvetica for CMTT10.
Loading NimbusSanL-Regu font from /usr/share/fonts/type1/gsfonts/n019003l.pfb... 4331568 2770354 4333368 3021180 3 done.
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Segmentation fault

Hope it will help you. 
Good luck, 
Marc.
Comment 1 Ken Sharp 2013-03-18 08:05:05 UTC 
The problem occurs on page 10 and appears to be a broken type 1 font. Adobe Acrobat also complains 'Cannot extract the embedded font XYATIP10' so there's obviously something wrong. Nevertheless Ghostscript shouldn't seg fault.
Comment 2 Ken Sharp 2013-03-18 11:02:43 UTC 
The problem is that the fonts XYATIP10 and XYBTIP10 are totally broken. I have improved the robustness of the pdfwrite code in the face of fonts broken in this way, and the file now runs to completion.

Rather than signalling an error on the broken fonts I've chosen to not embed them
in the output, but to leave the font call in place. This means that systems which have the fonts available will be able to substitute these and display the PDF as intended. Systems that don't will display some kind of substitute, which will of course be incorrect, but its no worse than the situation with the existing file.

Fixed in commit ec0a5d96d02576c53cef22fe3e9bde5547c2f4ee