Re: [ft-devel] [GSoC] Updates and quick question

[Werner LEMBERG]

> Thanks! I hope there isn't any problem with the rebase due to the
> removal of `OVERFLOW_' from the new macros.

I did a simple

  s/OVERFLOW_//g

plus some reformatting...

> I get that each driver handles its own objects, so using the same
> object for either Type 1 or CFF seems wrong as we have separate
> stuff for different formats, i.e. `T1_Builder_Funcs' and
> `CFF_Builder_Funcs', etc.  In other words, since the `type1' driver
> outputs to `type1' objects and the `cff' driver outputs to `cff'
> objects, routing Type 1 data through the CFF interpreter without
> changing the way it connects with the API would cause the results to
> be output to `cff' objects instead, which isn't intended.

Seems so, yes.

> Correct me if I'm wrong, but that might essentially meld the two
> drivers together (and `psaux' wouldn't really be auxiliary any
> more).  Although, perhaps that is the direction you are aiming for?

Not really.  However, if this turns out to be the easiest route (which
I doubt), I wouldn't object.

> My idea is to add two modes to the functions being called by
> `cf2_interpT2CharString', much like how it has two modes (soon
> three) itself, for either CFF or Type 1, and hence output to the
> right place without having to change the low-level APIs.

This...

> An alternative idea is to make `cf2_interpT2CharString' call either
> `cff' functions or `type1' functions depending on the mode passed
> into it.  This is just shifting the position of added code though.

... and that sound like very sensible ideas.  Please proceed as you
like; I don't have a preference.


    Werner