Summary: | enhancement to CIDFont emulation with TrueType fonts | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Ken Sharp <ken.sharp> |
Component: | Font API | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | chris.liddell, christinedelight.top85, shailesh.mistry |
Priority: | P4 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Windows NT | ||
Customer: | Word Size: | --- |
Description
Ken Sharp
2009-03-19 08:21:23 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. 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 |