> From what I understand, we can rewrite > 't1_decoder_parse_charstrings' to do the same as > 'cf2_interpT2CharString' for calling outline builder functions, > which does not increase duplicated code over what is already > present. Then, for hinting, I believe we can do the same i.e. get > the t1 decoder to use the new hinter over 'pshinter', except I am > having some trouble figuring out how the CF2 hinter works... > (specifically, how are the hinter functions actually called). This > approach merges processing for type1/cff fonts only after the > decoding stage, i.e. one type of charstring to one decoder. This > sort of ties in with the second method I mentioned in my opening > post.
I think that... > The alternative below merges before the decoding stage, i.e. use the > same decoder for all three types of charstrings, which I understand > more readily and am leaning towards. ... this is the solution to go, yes. >> What do you think? The first step would then be to split off the >> CFF charstring and hinting stuff from the `cff' module into a new >> module `new_psaux' (please find a better name :-). > > However, I don't quite understand the "modularity" part. I imagined > extending 'cf2intrp' with an additional T1 mode, and adapting the T1 > data structures (e.g. the Font and Decoder records) to work with > this change. My guess is that enough functionality is added that > the new type1/cff joint interpreter should be viewed as a separate > module, but I am not sure what the benefits are, as I have never > dealt with such a large-scale project and am not used to best > practices. Regarding modularity, the constraint is rather simple: Assume we are in directory `src/foo' (which normally corresponds to module `foo'). What I don't want is to have #include ../bar/bar.h or something similar to access stuff from the `src/bar' directory (i.e., from the `bar' module). In other words, if you want to have the `type1' and `cff' module share something, you either need to provide a FreeType service (cf. `svgxval.h' for the OpenType variation font support, which gets shared between the `truetype' and `cff' modules; the corresponding header file goes to `include/freetype/internal/services'), or you create a separate module (i.e., a separate directory), with a header file in `include/freetype/internal'. Since we already have the `psaux' module, I prefer the latter. [Note that Type 1 support is not only the interpreter, it also means parsing of AFM (or PFM) files; this stuff is also in the `psaux' module. Similarly, it would be nice to have a CID CMap parser for better CID font support; this could would also go into `psaux'.] What I want is to move the (extended) CFF parser and hinter from the `cff' module to the `psaux' module, thus replacing the Type 1 parser and hinter. Later on, the `cid' module must also be adapted to use the (extended) CFF parser and hinter. > Also, here is a rough proposal draft that includes the tasks > identified thus far. https://goo.gl/rINYUZ Thanks, looks promising! Please transfer this to a proper, registered GSoC draft proposal as soon as possible. After the transfer, please allow comments for the corresponding google doc so that I can write something. Werner PS: Please also use proper 漢子 for your name. It always hurts me to see that many people from Asia voluntarily cripple his or her own name... _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
