Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

Hi,

A heads up that I've pushed a new branch ewaldhew-wip to savannah for
ongoing work. I'll keep it based on the clean branch, and that on
master.

Updates:
- The new interpreter now handles Type 1 commands.
- I added a Todo file. The notes inside mostly pertain to the changes
needed for the objects (decoder, builder) to pass through the
interpreter properly.
- It's not compiling as the objects have not been modified yet. This
is what I'm working on now.

I think we can merge both decoders and builders into single
definitions. I had realised that the Type 1 and CFF builders contain
practically the same data, and that the outline data would go to the
right place since the caller creates the objects. So I was confused
when I said..

> I get that each driver handles its own objects, so using the same
> object for either Type 1 or CFF seems wrong [...] results to
> be output to `cff' objects instead, which isn't intended.

..as each driver can just manage it's own instances of `PS_Decoder'
and `PS_Builder', and I now believe there is no problem as long as
these are correctly merged.

I also want to bring your attention to the notes regarding `seac' and
`callothersubr''s duplicated operations. (in Todo)

For the former, following the other, implied `seac' in `endchar' that
applies to Type 2 charstrings, i.e., retrieving charstring data and
making the recursive call in the interpreter itself, will avoid the
long chain of calls between the `psaux' and `type1' modules (which
also uses a bunch of new objects - possible performance hit). I'm not
sure if this is possible without first doing the objects change.

For the latter, those OtherSubrs are precisely the escaped operations
in CFF charstrings. I simply duplicated the code as I don't know if
gotos are worth it. However, they are in the same section of code so
perhaps it won't be too confusing. (Comments will be added to clarify)
What do you think?


Ewald