Re: [ft-devel] GSoC 2017 - CFF for Type 1

[Ewald Hew]

On Sun, Mar 26, 2017 at 1:52 AM, Werner LEMBERG <address@hidden> wrote:

> I need some time to cross-reference the specifications to decide if
> this is possible.  The alternative is, as how CFF2 support was
> added, to write a separate interpreter for Type 1 charstrings and
> glue it to the CFFBuilder using callbacks (I am still trying to
> understand the CF2 side, would appreciate clarification if this is
> not how it works).

I think this would lead to a lot of code duplication, buy maybe this
is a cleaner solution.  Something to investigate...

From what I understand, we can rewrite 't1_decoder_parse_charstrings' to do the same as 'cf2_interpT2CharString' for calling outline builder functions, which does not increase duplicated code over what is already present. Then, for hinting, I believe we can do the same i.e. get the t1 decoder to use the new hinter over 'pshinter', except I am having some trouble figuring out how the CF2 hinter works...(specifically, how are the hinter functions actually called). This approach merges processing for type1/cff fonts only after the decoding stage, i.e. one type of charstring to one decoder. This sort of ties in with the second method I mentioned in my opening post.

The alternative below merges before the decoding stage, i.e. use the same decoder for all three types of charstrings, which I understand more readily and am leaning towards.

Yes, the interpreter should understand Type 1, Type 2, and CFF2
charstrings – in three different modes.  In other words, you would
have to add a third mode to `cf2_interpT2CharString'.

 

Mhmm.  I would like to retain the modularity of FreeType, so it might
be better to change

[...]
 

What do you think?  The first step would then be to split off the CFF
charstring and hinting stuff from the `cff' module into a new module
`new_psaux' (please find a better name :-).

However, I don't quite understand the "modularity" part. I imagined extending 'cf2intrp' with an additional T1 mode, and adapting the T1 data structures (e.g. the Font and Decoder records) to work with this change. My guess is that enough functionality is added that the new type1/cff joint interpreter should be viewed as a separate module, but I am not sure what the benefits are, as I have never dealt with such a large-scale project and am not used to best practices.

Also, here is a rough proposal draft that includes the tasks identified thus far. https://goo.gl/rINYUZ

Regards,

Ewald