Bug 690798

Summary:	Files with Identity-H encoding produce error
Product:	Ghostscript	Reporter:	Marcos H. Woehrmann <marcos.woehrmann>
Component:	Text	Assignee:	Default assignee <ghostpdl-bugs>
Status:	NOTIFIED DUPLICATE
Severity:	normal	CC:	jackie.rosen
Priority:	P2
Version:	master
Hardware:	Macintosh
OS:	MacOS X
Customer:	580	Word Size:	---

Description Marcos H. Woehrmann 2009-10-01 13:19:06 UTC

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.

Comment 1 Marcos H. Woehrmann 2009-10-01 13:19:35 UTC

Created attachment 5433 [details]
thrane.pdf

Comment 2 Marcos H. Woehrmann 2009-10-01 13:21:35 UTC

Created attachment 5434 [details]
axaptareport.pdf

Comment 3 Marcos H. Woehrmann 2009-10-01 13:22:04 UTC

Created attachment 5435 [details]
axaptareport0.pdf

Comment 4 Ken Sharp 2009-10-02 00:39:01 UTC

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 ***

Comment 5 Marcos H. Woehrmann 2011-09-18 21:46:01 UTC

Changing customer bugs that have been resolved more than a year ago to closed.