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

[Werner LEMBERG]

> However, for general-purpose systems like Unix, where the user is
> free to update its version of FreeType, or FTValid, it leads to the
> same problems that we encountered with Pango, fontconfig, etc....

Well, libtool's versioning scheme should prevent chaos.

> > 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.
>
> I fully agree.

Fine.

> > 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()?
>
> libftvalid.h would provide something like:
>
>    FTV_Error  FTV_Init( FT_Library  library );
>
> which would look like:
>
>   FTV_Error  FTV_Init( FT_Library  library )
>   {
>     return FT_Add_Modules( library, &ftvalid_module_info );
>   }
>
> where 'ftvalid_module_info' is defined within ftvalid.dll
>
> the FTV_Init() function should be called before anything else.

Aah, I always thought the opposite, namely that FreeType itself
registers libftvalid if it is available so that the existing
FT_OpenType_Validate function can work.  With other words, I still
consider ftvalid part of FreeType, but as an optional component.

> but it would be a bad idea anyway. Really, the code in ftvalid doesn't
> depend on FreeType anymore, I don't see why you'd want to introduce
> potential versioning problems on Unix by getting this dependency
> back.

Code sharing.

> What's so wrong with distinct libraries, really ?

Nothing, but I would like to understand all implications since I've
never done such a thing before.  Sorry for being obtrusive.


    Werner