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

[Werner LEMBERG]

>>>  - 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'm referring to these:
>   cff_blend_check_vector
>   cff_blend_build_vector
>   cff_blend_clear

These three look ok, however...

>   cff_get_var_blend

... this is definitely bound to the cff module, since it is part of
the multiple master service.  The function's code can be easily
duplicated if necessary.

>> 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.
>
> I'm not sure I understand fully... What I get is to provide the
> `parse_charstrings' function from psaux, which is already being done
> (decoder functions in the psaux module interface).

Oops, yes.  I was confused :-)

> [...] for `cff', instead of passing the relevant functions from
> `cffload' as parameters to the init function, I should just create a
> CFF module service in the same way as psaux is (placing cffmod.h in
> include/freetype/internal/).  Am I right?

Yes, this is what I think is the right solution.

> What justifies creating a new service which will only be used by one
> other module, as opposed to passing in a table of function pointers
> as callbacks during init?  Is this a matter of best practices /
> design philosophy?

It's a design philosophy.  The inter-module communication is done best
IMHO with services.  Whether it is the best solution in general I
can't tell yet.

>>   https://www.freetype.org/freetype2/docs/design/design-3.html
>
> Hmm, following this design I would do something like:
>
> struct PS_DecoderRec {
>   FT_Bool  isCFF;
>
>   PS_Decoder_Zone*  zone;
> // CFF_Decoder_Zone and T1_Decoder_Zone have the same fields, only
> difference is the values of MAX_SUBRS_CALLS
>
>   FT_Int             flex_state;
>   FT_Int             num_flex_vectors;
>   FT_Vector          flex_vectors[7];
>
>   FT_Render_Mode     hint_mode;
>
>   FT_Bool            seac;
> }
> struct CFF_DecoderRec {
>   PS_DecoderRec  root;
>
>   /* All the other fields
>    *   ...
>    */
> }
> struct T1_DecoderRec {
>   PS_DecoderRec  root;
>
>   /* All the other fields
>    *   ...
>    */
> }
>
> which sort of strikes a middle ground between the two strategies.
> Then we would first pass a PS_Decoder to
> cf2_decoder_parse_charstrings, check its isCFF flag, and cast it to
> either CFF or T1.

My advice was misleading, sorry.  Within the cff module there could be
a CFF_DecoderRec object containing a `root' structure.  Similarly,
T1_DecoderRec would be part of the type1 module.  Within psaux,
however, this doesn't make much sense since such a structural overhead
is unjustified.  Given that you probably want to have a single
function for parsing charstrings, having a PS_Decoder structure looks
promising.

> Also, I just pushed the changes I have tried making thus far to
> savannah, in branch ewaldhew-refactor-cf2 (not cleaned).  If
> possible, please give it a quick look to see if I am going in the
> right direction. (Most of the changes are cut-and-paste)

Will do so tomorrow.  Thanks for the code!


    Werner