[Devel] Re: Distiller produced CFF fonts

[Tom Kacvinsky]

I just merged Wes's patchesinto my copy of the code.  It works, but...

1.  Currently, the setup sis like: codes[gid] = charcode, whereas I was
expecting codes[char_code] = gid.  The latter format will support supp.
encoding data much easier.

2. supp. encodings are not parsed (I am working on this).  The problem is
that one has to have the CharSet parsed first.  From that, one can use the
SID in the supp. data to get a GID (from the charset table), and then add
the GID to the codes table at an index gleaned from the supp. encoding's
char code field.

3.  An encoding offset of 0 means use Standard Encoding, not that there is
no encoding table.  The problem is that the CFF spec. states that if the
font uses StandardEncoding, there is no need to place a encoding offset in
the top dictionary for the font (since 0 is used for StandardEncoding, and 0
is a default entry).  What I propose is the following: init the encoding offset
to -1.  Pasrse the top dict. If there is no encoding offest entry in the
top dict., set the encoding offest to 0, with the provision that this means
the font uses SE.  If there is a encoding offest in the top dict, use that
instead.

4.  The discussion in 3 also applies to the char set table.

How does this affect what you are working on?

Tom

P.S. I have some more Distiller produced CFF fonts that are causing display
problems.  I wonder if it is an advanced width problem, not a side bearing
problem...


> 
> Yeah, I knew about the CharSet and Encoding tables. I have 
> been using Wes White's code to load those tables. I think 
> you had offered to pick up where he left. Actually, I am 
> on the same project that Wes was on before he was assigned 
> to a new one (which doesn't happen to use FreeType). If the
> information helps, I've been using his code since it was 
> implemented and in my experience so far it works as advertised.
>