Re: [ft-devel] controlling FreeType modules

[Werner LEMBERG]

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