The customer reports and I've verified that the attached generates a /typecheck in --.execform1-- error with Ghostscript (I tested with head (r8237) and 8.54, 8.57, and 8.60 and all of them fail, albeit with different error messages). The customer didn't report which version they are using. The command line I used for testing: bin/gs -sDEVICE=ppmraw -sOutputFile=test.ppm ./TestKrog.pdf Acrobat Reader and evince both open the file without problem.
Created attachment 3365 [details] TestKrog.pdf
The PDF file is incorrect. It has the following resource declaration /Font << /Helv / >> When the malformed resource declaration is removed, other problems show up: - /Helv resource is not inherited - Some frames around annotations are missing
The customer reports: "Our customer uses the Neevia doccreator product to generate the PDF. We then got this analysis from Neevia which uses ghostscript internally in their products: "The PDF files you sent us are fine (run Adobe Preflight and you will see that) - this is a GhostScript problem. It looks like ghostscript doesn't support several keys from /AP (form appearance dictionary) ."
Adobe Reader 7 doesn't complain about the file, but it does say that it is using ArialMT for Helvetica. If Ghostscript were to assume the << /Helv / >> is supposed to map to the /Helv standard font, then we can process this OK without the warning: **** Warning: Tf refers to an unknown resource name: Helv Assuming it's a font name.
Ray's suggestion works indeed, but I don't think that it's how Acrobat Reader handles this file. I need to make a few experiments with AR and make a conforming implementation. Perhaps, we have a problem in the resource look-up order.
Tried with r9935. Still fails with /typecheck in --.execform1--.
Bug still reproducible in Ghostscript 9.03
Created attachment 7961 [details] font fallback patch First point, Acrobat 9 Pro (at least) clearly does consider this a broken file - when closing the file, it pops up a dialogue asking whether to save the changes to the file. Running the Acrobat repaired file through GS works fine. Second, the original file is clearly broken, and I don't consider it incumbent on us to mimic Acrobat's behavior with broken files (if you want to be sure of consistent output, create your PDFs correctly!). So doing "something sensible" seems a reasonable approach, even if it doesn't exactly match Acrobat. Third, a similar test with *only* the annotations results in Acrobat PreFlight throwing "missing font Helv" errors, so Acrobat doesn't seem to be doing something unconscionable with the abbreviated font name. My feeling is we should treat this breakage the same as a missing resource, with the warning that goes with that. Attached patch does that. Anyone have objections or other thoughts on this? If no one does, I'll commit the change.
Created attachment 7962 [details] hacked up test with only annotations Acrobat displays this fine, but pre-flight show missing font errors. I take that to mean that it is using the last ditch fallback font.
Created attachment 7963 [details] hacked up test with only AcroForm Acrobat displays this blank, and shows no objects at all in preflight.
Just an additional thought: as an alternative, I could change the patch to check for the correct object type (dictionary) before calling resourcefont, instead of using a stopped context. That would only catch the one error case, so might have fewer potential side effects, and may be a little faster. Personally, I prefer the stopped context, but I thought I'd mentioned the alternative.
My vote is for the checking of the object type because - we already do similar checks elsewhere - the explicit check avoids hard-to-understand bug reports about partly rendered pages. - the stopped path is incomplete: no attempts are made to restore dictionary and operand stack to the original state if the failing procedure leaves some random junk. - the stopped path doesn't provide a debug option to disable the error trapping.
Created attachment 7965 [details] Patch based on feedback from Alex Revised patch based on Alex's feedback. This uses the object type checking approach, honors PDFSTOPONERROR, includes a more meaningful warning messages, and finally (as I was in there) tweaks the change for Bug 689037 to also honor PDFSTOPONERROR. Unless Alex has an objection, I'll this some time soon.
Patch applied in: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d670fb The file is genuinely broken (as Alex points out in comment #2), and further, despite the customer's claim, Acrobat 9.x Pro recognizes it as such. This is indicated by opening the file in Acrobat, and closing it - Acrobat (Pro?) will prompt the user to save the changes to the file, even though the user has not edited the file. There are several reasons that Acrobat's PreFlight may be failing to find the breakage - it may be that this is simply one of the *many* holes in this feature, or it may be that it is not checking (as diligently?) AcroForm appearance streams and/or annotation appearance streams, *or* it may be that Acrobat is mistakenly passing the repaired version of the file to its PreFlight, which is a valid file. Given the very clearly broken nature of the file, the patch takes a "sensible fallback" approach to output *something* sane if we can - it treats the broken font resource entry as if it were a missing entry. This *may* what Acrobat is doing (experimental results are inconclusive) but, frankly, if you want to sure of accurate reproduction, don't create broken PDFs!