> [Please *always* report such issues to the mailing list! I consider > it an important part of GSoC that the community stays informed, > possibly discussing the issue.]
Oh no, sorry about that! I'd initially wrote this as a reply to the previous thread but spun it off into a new mail, and had forgotten to copy over the Cc: field. I have to pay more attention to these things... > Thanks! Will check later. Thanks! I hope there isn't any problem with the rebase due to the removal of `OVERFLOW_' from the new macros. > This I don't know. Ideally, everything should be unified that can be > unified. The basic question is how much similarities in the code are > present, and how much unification makes actually sense. Yes. However, right now I don't yet fully understand the abstraction between the FreeType public API and the internal driver objects, such as how glyph data in the driver gets out to the API layer. I get that each driver handles its own objects, so using the same object for either Type 1 or CFF seems wrong as we have separate stuff for different formats, i.e. `T1_Builder_Funcs' and `CFF_Builder_Funcs', etc. In other words, since the `type1' driver outputs to `type1' objects and the `cff' driver outputs to `cff' objects, routing Type 1 data through the CFF interpreter without changing the way it connects with the API would cause the results to be output to `cff' objects instead, which isn't intended. Correct me if I'm wrong, but that might essentially meld the two drivers together (and `psaux' wouldn't really be auxiliary any more). Although, perhaps that is the direction you are aiming for? > My original, vague idea was to prepare Type 1 data (not thinking about > what `prepare' exactly means) so that it can be accepted by the CFF > interpreter, which in turn gets slightly extended where necessary to > handle Type 1 data. So, right now the interpreter takes in CFF charstring data and performs actions on the `cff' objects via the callbacks. If I now pass in Type 1 data (assuming it's already been extended), I should expect to perform actions on `type1' objects instead. My idea is to add two modes to the functions being called by `cf2_interpT2CharString', much like how it has two modes (soon three) itself, for either CFF or Type 1, and hence output to the right place without having to change the low-level APIs. An alternative idea is to make `cf2_interpT2CharString' call either `cff' functions or `type1' functions depending on the mode passed into it. This is just shifting the position of added code though. What do you think? Ewald. _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
