The customer reports that Ghostscript generates an "Error: /undefined in findresource" error when reading the attached file. Adobe Acrobat displays a warning, "Cannot find or create the font 'ArialMT'. Some characters may not display or print correctly.", but then processes the file; the customer would prefer this behavior. The command line I'm using for testing: bin/gs -sDEVICE=tiff24nc -o test.tif ./dogville_2-layout1.pdf Note that if I add an entry to the cidfmap file: /ArialMT << /FileType /TrueType /Path (./arial.ttf) /SubfontID 0 /CSI [(Unicode) 0] >> ; Ghostscript will read the file, but substitutes the wrong characters for the missing font (Acrobat replaces the characters with bullets).
Created attachment 5396 [details] dogville_2-layout1.pdf
The font in question is not a /Font its a /CIDFont (the file also, ridiculously, uses a regular font called ArialMT), the PDF specification says that CIDFonts *must* be embedded, so the file is invalid according to the spec. Unfortunately we can't currently arbitrarily substitute CIDFont resources the way we do fonts, and even if we did the results would be incorrect anyway. The reason we can't substitute an arbitrary font is because of the likely diversity of glyphs in a CIDFont. There is a fallback substitution mechanism available for CIDFonts which relies on the CIDSystemInfo. This information describes the Registry and Ordering of a font, two fonts with the same Registry and Ordering will contain the same glyphs, so it is possible to substitute (eg) a Chinese font with a different Chinese font. This mechanism is described in /gs/doc/Use.htm "Section 8.4 CID font substituion", especially the last 4 or 5 paragraphs. Note that if you want bullets, create a font which only contains a single /.notdef, design a bullet shape for it, and use that font as the substitute.
> Note that if you want bullets, create a font which only contains a single > /.notdef, design a bullet shape for it, and use that font as the substitute Can we discuss an enhancement of supplying such a font and substituting it for missing CIDFonts with a warning, emulating Acrobat? Whether or not CIDFonts are required to be embedded there are many PDF files in the wild that violate this spec. and all the other PDF interpreters I tried, Adobe Acrobat, Apple Preview, evince, and muPDF, all behave this way (Apple Preview appears to be the only one that correctly renders the characters in the missing font).
We could manufacture such a font I guess, but it wouldn't prevent the problem completely. Each combination of Registry and Ordering would need to be added to cidfmap so that the font would be substituted with our replacement. If we replaced any missing CIDFont (as Acrobat does) by altering the font machinery, then we would break compatibility with the PostScript interpreter which raises an error for missing CIDFonts (as it is supposed to do). A possibly better enhancement would be for the PDF interpreter to catch errors when a CIDFont is missing and select a default substitute CIDfont (ie one which only has a bullet for the .notedf) This would emulate the Acrobat behaviour and wouldn't break PostScript compatibility which would still flag an error. It would also be more work of course...
I'm reopening this bug as an enhancement request that we modify Ghostscript to a behave like Adobe Acrobat, Apple Preview, evince, and muPDF and treat a missing /CIDFont as a warning and not as an error.
*** Bug 690798 has been marked as a duplicate of this bug. ***
*** Bug 692583 has been marked as a duplicate of this bug. ***
This has been implemented in: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=405d67e6 and http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3875e5 Apologies for the two commits, my initial implementation didn't play nicely with pdfwrite.