Folks,
it's embarassing, but I've screwed up my property proposal. The reason is quite simple: While designing and discussing the interface, I haven't looked closely enough at the source code, and only now I have discovered the discrepancy between my faulty memory and the reality... However, not everything is wrong. This one > Property service > ---------------- > > Properties get accessed with FreeType services. For example, to > make the module `foo' listen to property changes, add a > `foo-properties' service to the module, with two functions to get > and set values. stays the same, while this > Default properties > ------------------ > > Internally, we use an `FT_Property' structure to collect all > properties in a linked list: [...] doesn't work. Fact is that modules can only be controlled at the FT_Library level; FT_Face objects simply use pointers into an FT_Library's module list. This has two consequences: (1) The suggested API is much simpler. (2) Changes to modules have an immediate effect to *all* FT_Face objects, including the ones already created. If you want to have FT_Face objects with different module settings, simply use another FT_Library object. If memory is a concern it is possible to only load selected modules into this new FT_Library object instead of the default ones, as discussed in the FreeType documentation. The intended API looks like this now FT_Error FT_Property_Set( FT_Library library, const FT_String* module_name, const FT_String* property_name, void* value ); FT_Error FT_Property_Get( FT_Library library, const FT_String* module_name, const FT_String* property_name, void* *avalue ); which I'm going to implement the next few days. Werner _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel