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 _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
