OK, I'll try an explanation:
FT_Add_Modules was designed to be able to register a new module
after the library initialization on _embedded_ systems, you should
typically do something like the following in the code that *uses*
FT2:
FT_Init_FreeType( library );
FT_Add_Modules( library, my_module_info_struct );
where 'my_module_info_struct' can be obtained statically, or
dynamically before the call, this isn't important to the font
engine itself.
To make this work, the extra module must be compiled for a specific
revision of the FreeType sources, and should only call the functions
that are tagged FT_BASE in the sources.
This means that:
- when compiling FreeType 2, you must ensure that FT_BASE(x)
translates to extern x, which is not the default
- the module source code must be capable of including the
internal headers, and depends on the function provided there.
if some internals change, the module code may need to be
recompiled or even updated, or problems will abound.
This is not too much of a problem in embedded systems, where you
control exactly what goes in the system, and how you compile things.
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
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.
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.
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.
What's so wrong with distinct libraries, really ?
Regards,
- David
***
Information contained in this email message is confidential and may be
privileged, and is intended only for use of the individual or entity named
above. If the reader of this message is not the intended recipient, or the
employee or agent responsible to deliver it to the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this communication
in error, please immediately notify the [EMAIL PROTECTED] and destroy the
original message.
***
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
