Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.

[Mickey Gabel]

Werner LEMBERG wrote:
> > 1) We have our own struct that contains both the ft library and an
> >    FT_Memory object.
> >
> > 2) We initialize the fields in the FT_Memory object so that our
> >    callbacks are called.
> >
> > 3) We call FT_New_Library and tell it to use our memory object.
> >    This is the first FT2 API call.
> >
> >        // Initialize freetype2
> >        lib->ft_memory.alloc    = sf_FTalloc;
> >        lib->ft_memory.free     = sf_FTfree;
> >        lib->ft_memory.realloc  = sf_FTrealloc;
> >        lib->ft_memory.user     = lib;
> >        ft_err = FT_New_Library( &lib->ft_memory, &lib->ft_lib );
>
> I wonder whether this code from FT_Init_FreeType
>
>   (*alibrary)->version_major = FREETYPE_MAJOR;
>   (*alibrary)->version_minor = FREETYPE_MINOR;
>   (*alibrary)->version_patch = FREETYPE_PATCH;
>
> should be moved to FT_New_Library to make FT_Library_Version more
> generic.
>
> I suppose that you don't call FT_Init_FreeType at all if using
> FT_New_Library, right?  Do you use FT_Add_Default_Modules to register
> all modules or do you specify them directly with FT_Add_Modules?
>
>
>     Werner


Yes, we use FT_New_Library followed by FT_Add_Default_Modules.
The original plan was actually to add modules manually, but why do more 
work :D
However, we have a custom build: our list of default modules is smaller 
than the regular one, and also we put our compiled objects and ft2 
objects into the same static library. Therefore we may not encounter 
some of the issues other people do. For example, we don't care about 
freetype version, as we statically know what we are compiling.