Bug 690340 - enhancement to CIDFont emulation with TrueType fonts
Summary: enhancement to CIDFont emulation with TrueType fonts
Status: CONFIRMED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Font API (show other bugs)
Version: master
Hardware: PC Windows NT
: P4 enhancement
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
: 690341 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-03-19 08:21 UTC by Ken Sharp
Modified: 2011-08-04 21:11 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Sharp 2009-03-19 08:21:23 UTC
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.
Comment 1 Ray Johnston 2009-03-19 08:28:56 UTC
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.
Comment 2 Ken Sharp 2009-03-19 08:36:03 UTC
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 ?
Comment 3 Ken Sharp 2009-03-19 13:26:26 UTC
*** Bug 690341 has been marked as a duplicate of this bug. ***
Comment 4 Henry Stiles 2009-06-18 11:05:46 UTC
reassign from support to an engineer, not sure of the current status of this one.
Comment 5 Shailesh Mistry 2011-08-04 21:11:32 UTC
Enhancement still missing in Ghostscript 9.03