[Top][All Lists]

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

Re: [Devel] AAT/TrueTypeGX supports in Mac

From: Werner LEMBERG
Subject: Re: [Devel] AAT/TrueTypeGX supports in Mac
Date: Thu, 23 Oct 2003 06:53:03 +0200 (CEST)

> These days, `service' mechanisms are introduced to FreeType2 codes.
> I have not understood the mechanisms well yet.

The idea is to make a given functionality (i.e., service) which is not
restricted to a single module available to all modules in a consistent
way.  It is somewhat similar to the concept of `derived classes' from
C++.  Look at this example from t42drivr.c:

  static const FT_ServiceDescRec  t42_services[] =
    { FT_SERVICE_ID_GLYPH_DICT,           &t42_service_glyph_dict },
    { FT_SERVICE_ID_POSTSCRIPT_FONT_NAME, &t42_service_ps_font_name },
    { FT_SERVICE_ID_XF86_NAME,            FT_XF86_FORMAT_TYPE_42 },
    { NULL, NULL }

All three services (GLYPH_DICT, POSTSCRIPT_FONT_NAME, and XF86_NAME)
are `extended' to provide routines specific to the Type 42 format.

> I wonder [whether] 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.

Hmm, AAT is specific to TrueType fonts, right?  AFAIK, it isn't needed
by other drivers.  If so, I think a simple module similar to psaux is
the right solution, without using the `services' mechanism.  David,
please correct me if I'm wrong.


reply via email to

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