Re: [ft] Handling an embedded CID font using Freetype

[Chris Liddell]

On 22/03/17 14:08, tony smith wrote:
> Hello
>
> I'm using Freetype to display fonts embedded in pdf data.
>
> My problem seems to be with an embedded CCF file, where the CID mappings is
> only defined in the pdf data.
> I load a Compact File Format (CFF) stream into memory.
> But when I try to select a character map, using FT_Select_CharMap, I get
> error 0x26, Invalid_CharMap_Handle.
> I've attached the CFF, font.cff, and a simple c++ program, cff.c, which
> highlights the problem.
>
> From the pdf file I know that the font is a CID one.
> So you can work out the mapping from the PDF strings to Unicode strings.
> But this information doesn't seem to be available in the CFF stream.
> So my question is how do I handle this situation?
> I can't see any way in Freetype to add the missing character encoding.
> Do I have to decompress the CFF stream, which should be a type1 font and
> then explicitly add the missing character encoding information?

CFF != compressed type 1. Although the imaging models, and many concepts 
are shared, they are not the same.

CFF CIDFonts don't contain any encoding information, and there is no set 
glyph ordering, and there is no built-in character ID to glyph index 
mapping (like, for example, a TTF/OTF cmap table).

To actually use a CIDFont you need to use the CMap (NOTE: not "cmap", 
but "CMap") specified by the PDF - that can either be custom, embedded 
in the PDF, or a named reference to a standard CMap (available from 
Adobe, but I can't remember right now where).

Parsing the CMap table will give you a mapping from character code to 
CID, which you can then use to pull the glyph from the font. (In 
Postscript terms you "compose" the CIDFont with the CMap to create a 
usable instance of the CIDFont).

CMaps are defined in a highly restricted variant of Postscript, so 
should be fairly easy to parse.

Chris