On Mon, 21 Nov 2005 10:39:32 +0100 "Turner, David" <[EMAIL PROTECTED]> wrote: >> About plugin, it is good idea (although I'm afraid >> that FreeType is very very widely used on platforms >> without dlopen etc), but it will be long way work. >> It should be FreeType3, even if the binary compatibility >> is kept. >> >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'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. I'm afraid the difference is just in the viewpoint of FreeType maintainer: the separate update of libftvalid.a is enabled. My understanding is right? >>If I rewrite gxvalid to smaller and limited validation >>(e.g. memory alignment, number of members etc) by >>default, it's acceptable to include? > >I think that wouldn't solve the issue: > >- it's 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? >- it ties the releases of the validation and FT2 code, > when these could be independent. I think, the feature of otvalid is almost fixed and won't cause "urgent update to fix severe bug in otvalid". And, my propose is the simplification gxvalid for such level. Regards, mpsuzuki _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
