The customer reports and I've confirmed that the attached files generate the following error when read by Ghostscript: Can't find CID font "Arial". Substituting CID font /Adobe-Identity for /Arial, see doc/Use.htm#CIDFontSubstitution. The substitute CID font "Adobe-Identity" is not provided either. Will exit with error. The command line I'm using for testing: bin/gs -sDEVICE=tiff24nc -o test.tif ./thrane.pdf This bug will probably end up being closed as 'won't fix' since the files violate the "CID Fonts must be embedded" rule, but a quick web search shows this is a very common situation and one that we should address (apparently Adobe InDesign routinely uses Identity-H encoding). Both Acrobat 9 and Apple Preview open the files without error.
Created attachment 5433 [details] thrane.pdf
Created attachment 5434 [details] axaptareport.pdf
Created attachment 5435 [details] axaptareport0.pdf
I don't believe there is any problem with Identity-H encoding, the problem is with missing CIDFonts. The spec says you may not do this, so the file is as you say technically incorrect. If you supply a CIDFont definition for Arial in cidfmap then these jobs work correctly. Eg /Arial << /CSI [(Identity) 0] /Path (c:/windows/fonts/arial.ttf) /SubfontID 0 /FileType /TrueType >> ; The documented substitution mechanism that you describe also works, Eg: /Adobe-Identity << /CSI [(Identity) 0] /Path (c:/windows/fonts/arial.ttf) /SubfontID 0 /FileType /TrueType >> ; Ghostscript needs to follow the PostScript reference manual, and so when a CIDFont is missing it does not attempt to substitute with a different font (as per Font resources). Not least because the likelihood of finding a suitable alternative font was small when this system was originally developed, since CIDFonts were intended for Far Eastern fonts. Acrobat clearly is able to substitute a font for a CIDFont, but that is an application level feature, not part of the specification for either PostScript or PDF. Bear in mind that printing a job with the wrong font can be an expensive mistake, and some users request that even normal font substitution is replaced with an error to prevent this happening. So I don't think we should be changing the behaviour of the PostScript interpreter in this case. This is basically a duplicate of #690779, but in that case Acrobat exhibits the problem I describe above, it is unable to substitute with a reasonable font, so the glyphs are all displayed as /.notdef, in that particular case a bullet. I suggest that we stick with the same approach as 690779, we allow the PDF interpreter to detect missing CIDFonts and substitute with a defined default substitute CIDFont. This will not affect the PostScript interpreter's behaviour, but will allow the requested Acrobat-like result. Closing as a duplicate. *** This bug has been marked as a duplicate of 690779 ***
Changing customer bugs that have been resolved more than a year ago to closed.