[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] controlling FreeType modules

From: Werner LEMBERG
Subject: Re: [ft-devel] controlling FreeType modules
Date: Mon, 20 Aug 2012 07:36:06 +0200 (CEST)


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

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

The intended API looks like this now

  FT_Property_Set( FT_Library        library,
                   const FT_String*  module_name,
                   const FT_String*  property_name,
                   void*             value );

  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]