Re: [ft-devel] Migrating layout table validation code to a new CVSmodule

[Werner LEMBERG]

> >There is no need for dlopen() or equivalent. We have FT_Add_Module
> >which can be called just after FT_Init_FreeType to add modules to
> >the font engine.
> >
> >That's what I use on my company's embedded software, to register
> >custom font drivers for some proprietary bitmap formats we need
> >to support. All is done statically.
> 
> Excuse me, I'm unfamiliar with FT_Add_Module().  I think,
> FT_Add_Modules() is capable to use functions that are available in
> linking time.

I think so too.

> I'm not sure if it can add modules derived from dlopen()-ed objects,
> but, at least, on no-dlopen() systems, we have to link both of
> libfreetype.a and libftvalid.a, to retain the possibility to use
> otvalid/gxvalid module.  Therefore, I think, the situation is same
> with the case that otvalid /gxvalid are included but
> disabled-by-default in libfreetype.a itself.

David, let's assume we have two DLLs, libfreetype and libftvalid, how
shall then FT_Add_Module work without some new code to call dlopen()?

> >- [otvalid stuff] is not really part of the font engine's work,
> >  since we don't provide APIs to process the tables.
> 
> Indeed, but still I want the validation functions are included to
> check the available feature before real font file loading procedure.
> Werner, how do you think of this issue?

As mentioned earlier, the short-term goal is to disable gxvalid and
ftvalid in the default build, and the long-term solution is to provide
a separate library which can be easily registered in FreeType.


    Werner