> 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
_______________________________________________
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel
