Re: [ft-devel] CID keyed fonts in sfnt wrappers in 2.3.8

[mpsuzuki]

Dear Michael,

I wish if my implementation for sfnt-wrapped PS Type1 & CID-
keyed fonts didn't bother you. Now I don't have sufficient
time to finish anything before 2.3.9 release...

Hmm, I guess, what you call as "CID keyed fonts in sfnt
wrappers" is a CFF OpenType including CID-keyed CFF font
(CFF OpenType for CJK scripts, usually), which is different 
from sfnt-wrapped CID-keyed fonts. If I'm misunderstanding,
please correct.

On Tue, 10 Mar 2009 10:46:22 +0100
Michael Toftdal <address@hidden> wrote:

>I am working on a piece of software that is (/was) dependent on the
>FT_FACE_FLAG_CID_KEYED flag and the 2.3.7 fact, that glyph index ==
>CID for CID keyed fonts (also those in sfnt wrappers). After upgrading
>to 2.3.8, I obviously got a small problem.
>I need the CIDs for outputting PostScript, where I unwrap OpenType
>(CFF) CID keyed fonts and refer to glyphs via the Identity CMaps.
>After the upgrade to 2.3.8, I could of course look up the CID flag and
>the Unicode to CID mapping in the font file itself (eg. as part of the
>unwrapping where I have the information anyway).

I understand your request as following, if I'm wrong, please
correct.

* When you load a CID-keyed CFF OpenType by FreeType 2.3.7,
  you can use it as simple CID-keyed font. The "cmap" table
  in CFF OpenType is ignored, and you can specify a glyph
  for CID by putting 16-bit CID to FT_Long-typed codepoint in
  FreeType API.

* When you load a CID-keyed CFF OpenType by FreeType2 2.3.8,
  you cannot ignore "cmap" table. To specify a glyph for CID,
  you have to translate a CID to Unicode codepoint, and put
  it to FT_Long-typed codepoint in FreeType API. Thus, you
  have to distinguish CID-keyed CFF OpenType and simple CID-
  keyed font.

* So, now you want a simple method to handle CID-keyed CFF
  OpenType as simple CID-keyed font.

I suppose the change was introduced on 2008-07-16.

2008-07-16  Werner Lemberg  <address@hidden>

        Handle CID-keyed fonts wrapped in an SFNT (with cmaps) correctly.

        * src/cff/cffload.c (cff_font_load): Pass `pure_cff'.
        Invert sids table only if `pure_cff' is set.
        * src/cff/cffload.h: Udpated.

        * src/cff/cffobjs.c (cff_face_init): Updated.
        Set FT_FACE_FLAG_CID_KEYED only if pure_cff is set.

Could you check if FreeType2 on CVS at 2008-07-17 shows
"changed" behaviour?

>                                                 But I would like to
>keep the unwrapping out of output process, as it happens another place
>in the software and in principle, unwrapping could just be extraction
>of the CFF table of the otf file.

I can understand your request - it might be popular requests
for the people working for existing PostScript systems.

>For my own purpose, I solved the problem by implementing two new
>functions in the CID service in FreeType. One to get the "internal"
>CID flag of the font (result is equal to asking for the CID flag in
>2.3.7 -- can by the way be mimicked for (most?) practical purposes by
>asking for the ROS and checking the return value). The other function
>gives me access to the glyph index to CID mapping that is stored in
>the cff->charset.sids array (which I have to suspend the free'ing
>of...).

Hmm. If I'm asked to implement the compatibility feature to
ignore "cmap" in CFF OpenType, I will modify cffobjs.c:cff_face_init(), 
and insert a hook to skip calling sfnt->load_cmap(). 
I can pass some parameters to cff_face_init() by num_params
and params[], so I should discuss the introduction of new
tag name to ignore "cmap" in CFF OpenType, something like
FT_PARAM_TAG_IGNORE_SFNT_CMAP.

Regards,
mpsuzuki



BTW, I've ever written a proof-of-idea implementation of
"partial stream", which can handle a part of a stream
as an individual stream (so, I can make a FT_Stream object
including CFF table only, from a FT_Stream including whole
of CFF OpenType). If I have sufficient time to finish it
and I can ignore its downgradable compatibility, I want to
use it.

http://lists.nongnu.org/archive/html/freetype-devel/2009-01/msg00044.html