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

[Ewald Hew]

> [Please *always* report such issues to the mailing list!  I consider
>  it an important part of GSoC that the community stays informed,
>  possibly discussing the issue.]

Oh no, sorry about that! I'd initially wrote this as a reply to the
previous thread but spun it off into a new mail, and had forgotten to
copy over the Cc: field. I have to pay more attention to these
things...

> Thanks!  Will check later.

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

> This I don't know.  Ideally, everything should be unified that can be
> unified.  The basic question is how much similarities in the code are
> present, and how much unification makes actually sense.

Yes. However, right now I don't yet fully understand the abstraction
between the FreeType public API and the internal driver objects, such
as how glyph data in the driver gets out to the API layer.

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.

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?

> My original, vague idea was to prepare Type 1 data (not thinking about
> what `prepare' exactly means) so that it can be accepted by the CFF
> interpreter, which in turn gets slightly extended where necessary to
> handle Type 1 data.

So, right now the interpreter takes in CFF charstring data and
performs actions on the `cff' objects via the callbacks. If I now pass
in Type 1 data (assuming it's already been extended), I should expect
to perform actions on `type1' objects instead.

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

What do you think?

Ewald.