Re: [Devel] AAT/TrueTypeGX supports in Mac

[Masatake YAMATO]

> 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 :-)

Some part of AAT/TTGX supports will be done in FreeType internal part, I think.

> 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,

Thank you for your explanation. I read your mail with ftmm.c source. I think
I could understand the idea of service well.
At this time, it seems that I don't have to use any services directly from
our AAT/GX code. Instead what I have to use is its wrapper function.
e.g. I don't have to use name service directly, instead I use
FT_Get_Sfnt_Name_Count and FT_Get_Sfnt_Name. 

    FT_Error
    gx_get_name_from_id ( TT_Face  face,
                          FT_UShort name_id,
                          FT_SfntName  *aname )
    {
      FT_Int i;
      FT_UInt nnames = FT_Get_Sfnt_Name_Count ((FT_Face)face);
      FT_SfntName  bname;

      for ( i = 0; i < nnames; i++ )
        {
          if ( FT_Get_Sfnt_Name((FT_Face)face, i, &bname) )
            continue ;
          if ( bname.name_id == name_id )
            return FT_Get_Sfnt_Name((FT_Face)face, i, aname);
        }
      return FT_Err_Invalid_Argument;
    }

In other hand I think GX/AAT code should provide service like(just an idea):

>   - 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

- "text-layout-service"
- FT_SERVICE_ID_TEXT_LAYOUT_SERVICE
- FT_Service_TextLayoutService

- methods are
-- glyph substitution
-- glyph position adjusting
...

GX Layout and OT Layout may be the service instances.

One GX API design issue I'm facing is now how could I know whether a face 
supports layout or not. How do you think add 
#define FT_FACE_FLAG_LAYOUT   ( 1L << 11 )
to face_flags?

Masatake YAMATO