Re: internal header files

[David Turner]

Hi Werner,

Werner LEMBERG a écrit :
> 
> Using FT_Get_Module_Interface(), I can give the client application
> access to virtually all data in a font.  For example, I could access
> any TT table using the TT_Load_Any_Func function in SFNT_Interface.
> Currently, the necessary header files are split between `freetype' and
> `freetype/internal', which is not optimal IMHO.
> 
> Wouldn't it be better to
> 
>   a) make FT_Get_Module_Interface() local again (i.e. using BASE_DEF
>      instead of FT_EXPORT_DEF).
> 
> or
> 
>   b) make all headers which describe font tables (e.g. sfnt.h)
>      `public' (i.e, moving it from `freetype/internal' to `freetype')?
> 
> Doing a) would mean that an add-on module must be written first to
> properly access the data.  I think a) is better than b).
> 
> Comments?
> 

I'd rather prefer providing a procedure-based interface to access specific
module and format features.

The "module interface" is a pointer provided in a module object to
directly link to a table of functions (or even variables) that describe
the module's "normal" interface. The layout of this table is specific
to each module, and it could vary between releases of the library.

Note that each module has a "get_interface"  method which can be used
to query one function at a time too..

Thus, the "module_interface" field is really a shortcut to avoid
calling two many functions.. It's purely internal and should never be
used by client applications..

I suggest moving the declaration of FT_Get_Module_Interface to
<freetype/internal/ftobjs.h>, and to make it FT_BASE_DEF.

If you want to give access to any table in a TrueType file, simply
add a function like FT_Load_SFNT_Table( ... ) to the high-level API
and implement it through a simple call to the module's interface.
If the layout of the table changes, for some reason or another, you
will only need to change the implementation of your function without
breaking existing applications..

Best,

- David