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

[Werner LEMBERG]

>> What about a third solution, namely to extend (Adobe's) CFF driver
>> to understand Type 1 charstrings also?  I believe that this
>> solution would need the least work.  You might have a look how CFF2
>> support was added.
>
> This is a great idea and I am pursuing it.  Thanks for the
> suggestion!  Somehow I didn't think of modifying the CFF side of
> things.

:-)

> This brings up a couple of questions though.
> 
> Firstly, I noticed that the CFF Type 2 charstring parser already
> sort of deals with "invalid", Type 1 commands.  I am exploring the
> feasibility of keeping stuff together, by fully implementing these
> unsupported operations hence allowing the interpreter to read both
> Type 1 and 2 charstrings.

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

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

> The second question might be a minor one, but I was wondering if
> this move will obsolete the type1 driver?

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

  font format    module(s)
  ---------------------------------------
  CFF, CFF2      sfnt + cff
  CID            cid + psaux + pshinter
  Type 1         type1 + psaux + pshinter

to

  font format    module(s)
  -------------------------------------
  CFF, CFF2      sfnt + cff + new_psaux
  CID            cid + new_psaux
  Type 1         type1 + new_psaux

So the `psaux' and `pshinter' modules would become obsolete (but
probably retained some time, similar to the old `CFF' driver, and
selectable with a configuration option so that `ftview' compiled in
developer mode can switch between the old and new parsing and hinting
modes for comparison purposes).

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

> I am excited to work with FreeType, and it is just impressive how
> much work goes into font rendering (and by extension text-only
> interfaces, which are often viewed as the simplest).

Indeed.  It's a never-ending story.


    Werner