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