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

[Ewald Hew]

>
>>  - 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
  cff_get_var_blend
  (and by extension cff_load_private_dict)
which are being called from the cf2 side. These support the CFF2 blend
operator, and could be moved to psaux as with the other charstring
parsing stuff, i.e. builder functions. Correct me if I'm wrong.

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

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). I'm not sure what
is in `type1' that still needs to be used in psaux (save the single
function stored as parse_callback in T1_DecoderRec), but 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?

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?

> 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

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.

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)


Ewald