The current CIDFont emulation using native TrueType fonts is less than optimal with respect to CMAP tables. The problem is that the character code is mapped by the PostScript CMap to a CID, but this has no meaning in TrueType. We tackle this by converting the CID to a Unicode code point (via the UCS2 CMaps ?) which we then pass through the Font's own Unicode CMAP tbale to produce a glyph ID. At present we create a dictionary called TT_cmap from the TrueType font's CMAP table (preferring a 3,0 Unicode subtable). We then use this in a call to .fillCIDMap in order to build a 'GIDmap'. which we use to convert CIDs via Unicode code points to a TrueType GID (glyph ID). We try to use similar code in the FAPI module to perform the same task, but because the font client is handling the font, we haven't copied the CMAP table and so the code fails (see issue #689826). I'm in the process of adding work-around code to the FAPI to handle this for FreeType, but in the long run it would be nice to do away with holding the TT_cmap dictionary altogether. If we could rationalise the code so that it works with the FAPI clients and our own code at the same time that would be ideal.
I haven't looked into this much, but if the request to the font scaler to render a Unicode point fails because the font doesn't have that glyph, can it return a code to indicate that failure? Then we could retry with the next Unicode in the list. At the end of the list, if we still have a failure, then we render the .notdef glyph (which may or may not be a visible glyph). This relies on the font scaler (AFS, FT, UFST) to not render the .notdef directly (in case it is visible) and for the font scaler to return a recognizable code for the failure. I apologize in advance if this is totally off base.
Ray what you say is (essentially) what I'm doing, but the problem is that the decoding is done in zcid.c, which doesn't know about the FAPI. By the time we find out the glyph is missing we don't have any way to use another one. This has meant copying some of the code from zcid.c into zfapi.c so that we can determine the encoding in a place where we can also detect the missing glyph. This is just a hack really :-( When not using FAPI we carry the CMAP subtable around with the font, which is wasteful of memory because we never use it again. NB do you know if the Unicode code points in the 'Decoding' list are multiple possible equivalents, or composites ?
*** Bug 690341 has been marked as a duplicate of this bug. ***
reassign from support to an engineer, not sure of the current status of this one.
Enhancement still missing in Ghostscript 9.03