Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
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 Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
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 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 Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
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 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 :-) The changes I made, make the FT_Memory struct work at all times, not just after initialization, even in a DLL build What you propose doesn't fix FT_Memory, but will fix my problem if I implement it in a way that adds a dependency on the system I have for allocating memory, which is an undesirable dependency, or if I just strip those methods from freetype, and implement them locally and have the linker sort it out.. (in which case a DLL build won't work anymore). both methods seem architectural wrong to me... but I guess I'm alone in that... I don't think so. Your arguments sound convincing -- let's see what David says. Anyway, again I really just wanted to 'notify' you of this, if you don't believe the changes make sense then don't take it, I'm perfectly fine integrating my changes over top every time I upgrade, which I hardly do anyway I just ran into this again when I took the 2.3.9 upgrade, and though I might as well be decent and contribute back... Thanks for that! Please always reply to the list too (even if you aren't subscribed). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] improved incremental interface for metrics
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 *after* scaling, not before.
Handling item 1 is straightforward, however, item 2 needs a change in
the incremental interface for glyph metrics, I believe. Currently
there is code like this (for example, in function
`T1_Parse_Glyph_And_Get_Char_String', file `t1gload.c'):
/* Incremental fonts can optionally override the metrics. */
if ( !error inc inc-funcs-get_glyph_metrics )
{
FT_Incremental_MetricsRec metrics;
metrics.bearing_x = FIXED_TO_INT( decoder-builder.left_bearing.x );
metrics.bearing_y = FIXED_TO_INT( decoder-builder.left_bearing.y );
metrics.advance = FIXED_TO_INT( decoder-builder.advance.x );
error = inc-funcs-get_glyph_metrics( inc-object,
glyph_index, FALSE, metrics );
decoder-builder.left_bearing.x = INT_TO_FIXED( metrics.bearing_x );
decoder-builder.left_bearing.y = INT_TO_FIXED( metrics.bearing_y );
decoder-builder.advance.x = INT_TO_FIXED( metrics.advance );
decoder-builder.advance.y = 0;
}
The `FT_Incremental_MetricsRec' expects integer values. My suggestion
is to introduce a new function `get_fractional_glyph_metrics'; if this
function is defined, use it, otherwise use `get_glyph_metrics'.
Objections?
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
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 Anyway, I guess you're right though, this simple yet elegant solution had simply not occurred to me, which is retarded The solution below seems to be exactly what I need and want to do, and I'm sorry for even asking the other thing. Tom. 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 Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
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 spelling error ;) I like it OMG! Sorry, man :) I totally didn't see that 'j' even after you pointed it out. Time to get new glasses... ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] commit 41821f8a8ae9961036101c6664ddb543eb3eaff5
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 on the stack. Perhaps you were thinking „large1 large2 num div div“? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
