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

[Werner LEMBERG]

Hello Ewald!


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

As you've correctly observed, this must not happen: Header files in
`src/cff/' are local to this subdirectory.  As a solution, either
create a new header file in `include/freetype/internal/' or create a
new service.

>  - 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? )

Actually, I would like to continue support for the old engine (until
Feb. 20th, it supported some features not provided in the new engine),
but this is not mandatory in case it provides large obstacles.

>  - It seems to be better to move the blend functions to the psaux
>    service (except cff_done_blend and cff_blend_doBlend)

What functions exactly do you mean?

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

Mhmm, this is indeed extreme and doesn't look very attractive to me.

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

This sounds OK, but...

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

... I agree with you that (c) sounds best.  FreeType is full of
function pointers, so there is no reason to not use them :-)

Actually, I suggest (c'): Both CFF and Type1 provide a service for
those function pointers, which would lead to the following structure
(please adapt the service names to your taste).

  CFF and Type1: provide `postscript-parse-funcs' service
  psaux:         provide `postscript-charstrings-parse' service

Both CFF and Type1 would call `postscript-charstrings-parse', which in
turn calls `postscript-parse-funcs' – the already existing service
management code would automatically use the stuff from the CFF or
Type1 version of `postscript-parse', depending on the module.

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

Honestly, this is a matter of taste, and maybe it makes sense to
follow the pseudo-C++ stuff already present in FreeType; see

  https://www.freetype.org/freetype2/docs/design/design-3.html


    Werner