[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Devel] Re: CFF Cleanup
From: |
Tom Kacvinsky |
Subject: |
[Devel] Re: CFF Cleanup |
Date: |
Fri, 1 Dec 2000 10:34:08 -0500 (EST) |
Hi David,
>
> Basically, it seems that reading the Charset table is important to
> synthetize a Unicode charmap for a pure CFF font, as well as to be
> able to support the "seac" trick that comes from Acrobat-produced
> CFF fonts.
>
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?
> I have no idea wether the "Encoding" table is going to be really useful
> if we don't intend to use it for Adobe-specific charmaps. Please let me
> know if you're still interested in it, as I'll forget about it otherwise..
>
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 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.
Regards,
Tom