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
I agree - I also have had no problem using custom allocators with
FreeType 2. I have successfully used DlMalloc, and currently use a
hybrid system comprising a fast-access pool of small blocks and a
fallback to standard malloc and free.
Graham Asher
CartoType
Mickey Gabel wrote:
Werner
As noted by other posters, FT_Init_Library is a convenience function. You
may want to use FT_New_Library instead to provide your own custom allocator.
2009/6/22 Werner LEMBERG w...@gnu.org
both FT_New_Memory, and FT_New_Library (functions called within
FT_Init_FreeType) are allocating
I've just changed the parsing routines of Type 1 charstrings to use
16.16 format internally, and I'm going to fix both Type 1 and Type 2
handling to use 16.16 format externally too:
1. Add a new load flag so that outlines can be returned in 16.16
font units.
2. Round the coordinates
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.
a totally unintentional spelling error ;) I like it
Tom van Dijck wrote:
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.
a totally unintentional
In the comment, you write:
,
| Additionally, we don't handle stuff like `large1 large2 num div
| num div' or large1 num large2 num div div'. This is probably
| not allowed anyway.
`
I suspect that „large1 num large2 num div div“ is not what you
meant, since it leaves large1 unmolested
