Werner LEMBERG wrote:
both FT_New_Memory, and FT_New_Library (functions called within
FT_Init_FreeType) are allocating memory, before I have a chance
of setting the function pointers in FT_Memory.. To get around
that I added an extra argument to the FT_Init_FreeType, which
allows me to provide an FT_Memory structure, before any other
freetype code is running.
The `canonical' way is to replace ftsystem.c with something more
appropriate for your target platform. For example, you can copy
the whole file, only replacing `FT_New_Memory' to fit your needs.
I don't see an immediate need to add new API functions -- you have
to convince me that the just outlined method doesn't work :-)
Sure I could do that... but then what is the point of having the
FT_Memory struct...it doesn't work as advertised, and in order to
fix it you advise me to replace a file where I need to implement my
own ft_alloc methods?
Well, advise... What I do is rather like taking a stab in the dark
based on previous information :-)
We have had no problem using FT2 with our own allocators (we work on
systems were malloc() and free(), and possibly dynamic allocation
entirely, are not present)
So either I am doing it wrong, or Tom van Dick is doing it wrong.
Here's what I do:
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've always felt that this is the way it's meant to be used! It
doesn't look like a hack, and everything is documented. Also it works :)
Basically, if I understand correctly, what Tom asked is already there.
There's no need to modify ft_system.c, or invent new API calls.
_______________________________________________
Freetype-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/freetype-devel