freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ft-devel] Migrating layout table validation code to a new CVSmodule


From: Turner, David
Subject: RE: [ft-devel] Migrating layout table validation code to a new CVSmodule
Date: Tue, 22 Nov 2005 13:39:48 +0100

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 address@hidden and destroy the original 
message.
***********************************************************************************





reply via email to

[Prev in Thread] Current Thread [Next in Thread]