[ft-devel] [GSoC] Moving CFF stuff into psaux module

[Ewald Hew]

Werner and Alexei,

Apologies for my somewhat long period of silence. I have been studying
the code and needed time to organise my findings and thoughts. To
start off, I have a couple of questions.

I have started pulling out the code for cff charstring processing into
the psaux module, and most of it separates quite cleanly - with the
exception of cff/cffload. Here are my considerations:

 - The cff code moved to psaux still uses functions defined in
cff/cffload.h. However, some cff code not moved is also sharing some
of these.
 - Notably, some of the cff/cffload functions are used in
cff/cffparse, and vice versa. ( cff_parser_run also makes a call to
cff_decoder_parse_charstrings (now inside psaux) if
CFF_CONFIG_OPTION_OLD_ENGINE is defined, but I'm guessing we don't
have to continue supporting this? )
 - It seems to be better to move the blend functions to the psaux
service (except cff_done_blend and cff_blend_doBlend)

I have considered doing the following:

 a. Move cffload and cffparse into psaux as well - providing the
functions cff module needs via the psaux service interface. Perhaps
the more extreme option, although simple in concept.

 b. Only move the parts of cffload that are used in psaux (after
splitting) there (blend functions, cff_random, etc.) which can be
provided to cff module via the service interface. Leave cffparse in
cff and pass relevant functions in as callbacks. However, this might
not be possible without also ensuring psaux/new_cffload has access to
the Parser struct definitions too (move into internal/cfftypes.h or
something).

 c. Pass all relevant functions from cff into psaux as callbacks
during initialisation. From what I see, this seems to be doable by
storing the functions in either decoder->cff or
decoder->cff->cf2_instance.data, during initialisation in
cff_slot_load.

So (c) seems to be the option, although it does involve throwing about
another whole bunch of function pointers. What do you think? Is there
a more conservative approach?

The next question concerns the merging of the two code paths of type1
and cff glyph loading. For now, the most obvious difference is in the
respective decoder objects, and cf2_decoder_parse_charstrings should
be able to accept either. I cannot be convinced as to which of the two
below is the better strategy, although I am leaning towards the
former.

Pass them in as void* so as to cast them to either T1_Decoder* or
CFF_Decoder* depending on a isCFF flag.
OR
Create a new structure PS_Decoder combining the two (perhaps have
nested structs with the format-specific fields, which is most part of
the decoders). Again, an isCFF flag will determine which fields are
being used.

The former is simple but perhaps less safe, but there are a few ways
to implement the latter. Which is better?

I would appreciate your input on these.

Regards,

Ewald