RE: [Devel] AAT/TrueTypeGX supports in Mac

[Turner David]

Hello,

> > > To support AAT/TrueTypeGX in FreeType2 or in a library stacked on
> > > FreeType2, I'd like to use `extra' field in TT_FaceRec:
> > 
> > Sounds like a good idea.  David?
> 
Only if he hacks the library's internals :-)

> Thank you. 
> 
> I've found one more question. These days, `service' mechanisms are
> introduced to FreeType2 codes. I have not understood the mechanisms
> well yet. I wonder AAT/TrueTypeGX support code should confirm to the 
> mechanisms or not. The `service' mechanisms is for the external 
> applications or libraries? If so, I think AAT/TrueTypeGX support 
> code should provide its functions in the `service' mechanisms style.
> In other hand, the `service' mechanisms is for the internal modules in
> FreeType2.  If so, I think AAT/TrueTypeGX support code should just use
> the services in FreeType2; and provide its functions in simple C
> language functions and types.
> 
> > > Give me hits.
> > 

OK, the "services" introduced recently is simply a way to make many
things more coherent and understandable within FreeType.

Basically, the engine's optional features are accessed at runtime
by querying "interfaces" or "classes". These are really pointers to
structures containing (mostly) function pointers, corresponding to
the implementation of a given "feature" or "API".

In FreeType 2.1.5, and before that, there are no less than three distinct
ways to declare and query such interfaces within the engine, which are:

  - each "module" can have a "requester" function that must be capable
    of mapping a given name to an "interface" pointer (or return NULL
    when the module doesn't provide the corresponding interface).

    this is the "get_interface" field of 'FT_Module_Class' which is
    invoked in code like the following:


    

  - additionally, each module has a "main module interface" pointer,
    which really is an interface pointer specific to the module.

    it corresponds to the "module_interface" pointer of 'FT_Module_Class',
    and you can retrieve it via FT_Get_Module_Interface( library, "modulename" 
);


  - finally, certain modules provide an augmented class structure that
    contains additionnal function pointers to perform certain features. Thus:

       'FT_Driver_Class'   extends 'FT_Module_Class' with font-loading methods
       'FT_Renderer_Class' extends 'FT_Module_Class' with glyph-rendering 
methods


These three distinct schemes are certainly confusing for new people trying to
hack the library internals. The "services" recently introduced are simply a
way to merge these three distinct schemes into a _single_ one. Basically,
only the "get_interface" method should be used in the future to access
optional interfaces or derived classes.

Each "service" is thus:

  - identified by a simple text string, like "the-service"

  - named with a macro whose name starts with 'FT_SERVICE_ID_', like
    FT_SERVICE_ID_THE_SERVICE

  - corresponds, with one exception, to a structure whose name starts
    with 'FT_Service_', like FT_Service_TheService

    the exception being FT_SERVICE_ID_XF86_NAME, where the service points
    simply to a text string describing the font format according to the
    XFree86 naming convention

It is planned that font driver and renderer methods be grouped into services
themselves, and that the "module_interface" will simply disappear (it was a
stupid optimization anyway).

all services should be declared in "internal/services", which should separate
them clearly from the content of "internal" which really describe another part
of the library's internals...

I hope that this should make certain things much easier to understand within
the library.

Since it's becoming quite clear that I won't have much time in the future to 
hack
on the library, I'd better improve its maintainability to allow more people to
keep hacking on it without blocking on artificial complexities that were never
cleaned up before...

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)

--
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender.
Any use not in accordance with its purpose, any dissemination or disclosure,
either whole or partial, is prohibited except formal approval.
The E-Mail transmission can not guarantee the integrity of this message.
CANAL+TECHNOLOGIES will not therefore be liable for the message if modified.