Re: [Devel] Re: CFF Cleanup

[David Turner]

Hi Tom,

> 
> Hi David,
> 
> Right.  The reason being is that CFF fonts need not be in StandardEncoding, so
> one has to use the char codes given in the seac-ified endchar to do a lookup 
> in
> StandardEncoding to get the glyph names, and then do a reverse look up in the
> CharSet table to get the glyph indices.  Or, that is how I was thinking of
> appraching it.  What is your take on this matter?
> 
It's _exactly_ what you're describing :-)

> 
> Well, FT parses the Encoding in a Type 1 font (MM fonts included), so why not 
> in
> a CFF font?  Moreover, there is already support for Adobe specific charmaps 
> for
> Open Type/CFF fonts and Type 1 fonts.  If anything, adding Encoding table
> parsing for the CFF driver will maintain consistency.

The reason the Encoding is parsed in Type 1 is that it's the only way to
synthetize a Unicode charmap and retrieve glyph names in this format.

On the other hand, CFF has the "Charset" table too, and it is much more
friendly to use for the same tasks in my opinion. We could parse the Encoding
array to support Adobe-specific charmaps. Other than that, I don't see a
real use for it.

I don't buy the "consistency" argument, I prefer practicality

> The only problem with the way the Encoding table is set up is that is a
> mish-mosh: one part is indexed by GID, and the value is the charcode/CID that
> is encoded, and the part (the supplemental data) is really index by chacode,
> and the value is the SID of the glyph that is encoded.  Blargh.
> 
Yes, I had noticed this utterly stupid thing too :-)

- David