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

[Werner LEMBERG]

> 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.

I think that...

> 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.

... this is the solution to go, yes.

>> 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.

Regarding modularity, the constraint is rather simple: Assume we are
in directory `src/foo' (which normally corresponds to module `foo').
What I don't want is to have

  #include ../bar/bar.h

or something similar to access stuff from the `src/bar' directory
(i.e., from the `bar' module).  In other words, if you want to have
the `type1' and `cff' module share something, you either need to
provide a FreeType service (cf. `svgxval.h' for the OpenType variation
font support, which gets shared between the `truetype' and `cff'
modules; the corresponding header file goes to
`include/freetype/internal/services'), or you create a separate module
(i.e., a separate directory), with a header file in
`include/freetype/internal'.  Since we already have the `psaux'
module, I prefer the latter.

[Note that Type 1 support is not only the interpreter, it also means
 parsing of AFM (or PFM) files; this stuff is also in the `psaux'
 module.  Similarly, it would be nice to have a CID CMap parser for
 better CID font support; this could would also go into `psaux'.]

What I want is to move the (extended) CFF parser and hinter from the
`cff' module to the `psaux' module, thus replacing the Type 1 parser
and hinter.  Later on, the `cid' module must also be adapted to use
the (extended) CFF parser and hinter.

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

Thanks, looks promising!  Please transfer this to a proper, registered
GSoC draft proposal as soon as possible.  After the transfer, please
allow comments for the corresponding google doc so that I can write
something.


    Werner


PS: Please also use proper 漢子 for your name.  It always hurts me to
    see that many people from Asia voluntarily cripple his or her own
    name...