> 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 Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel