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.
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
Re: [ft-devel] Searching for an FT2 tester program
After that, there are other complicated details so that _init_foo_class is used appropriately, i.e. it must be called at module initialization time in the PIC case only, with a heap-allocated structure passed as a parameter. However, this can also be performed with macros. I'm preparing a patch to show how this can work on the existing code base. However this is going to take a long time, so I would prefer if we could first submit your changes, then slowly migrate to this new scheme (we can do this piece by piece, fortunately). There are also complications due to the fact that modules themselves are defined through a constant table (but again, we can work with this with macros), and the challenge of derived classes, but I believe we should be able to support these as well with the minimal impact on duplication. Regards Hi David, I did some of the initial work and design the PIC version of the FT2 module system (that was a while ago). I am not sure what the current state of the code is (working on another project), but IIRC what most of what you describe has already been implemented. At least if I understood correctly. To be more specific: The code to initialize the table of default modules is already defined automatically in the PIC version (see src/base/ftinit.c). It uses the macros in ft_module.h. That user-configurable part of FT2 has not changed. Modules defined in the h file (using the macros) have their module struct allocation and init functions called automatically, and are then added to FT2 using FT_Add_Module(). When FT2 is released, the default modules are also released via the appropriate call. As for users that don't want to use the default module list, and want to use FT_Add_Module themselves: The idea was that they should call FT_Create_Class_foo_class(), and then it's the user's responsibility to pass the pointer to FT_Add_Module(), and at the end to use FT_Destroy_Class_foo_class() to release it. Again, as I am not sure what the current state is, I can't say much more. Mickey ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Why my memory is not been freed?
Jun.Wang wrote: Thanks very much for your kindly and carefully reply. I runs my programe on windows, I modified the FT_Done_FreeType, so I can call it several times to report current memory. With you reply, I know without FT_Done_FreeType there will be some memory not be released. If there any way to know the max memory size will be allocated by FreeType2? I havn't enough heap, I have to allocated a block of memory for freetype to keep the heap enough for my others program. But without the max memory size, I don't to how many size will be allocated. I just want to know the max maximum memory footprint on my programe beginning There is the record in the finally memory report, but it doesn't help to me. Why not write a simple wrapper using FT_Memory that counts the memory allocated, and then calls malloc/free? You will have to initialize the faces and the library in a slightly different way, probably. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Another tricky font: DFKaiShu
Werner LEMBERG wrote: We have needed to add the string DFKaiShu to trick_names[] in tt_check_trickyness() in ttobjs.c for the attached TTF extracted from a PDF. Applied to the CVS. Thanks for the report. Werner Does FT2 uses the filename to detect the tricky font, or does it use some data from the contents of the file? Assuming it's a file name: 1) Is there a way to check this list from outside? Our library always loads fonts from a user-supplied memory buffer, and never from a file. 2) Is there a way to either pass this list to the user, or simply check a filename (FT_Check_Trickyness?) and then pass it to the Face init routine (FT_New_Memory_Face)? Mickey ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Position Independent Port of FreeType2
(I am out of office until Monday, so I might not be able to answer or fix
anything)
First of all, thank you for taking the time to look at the changes and
answer my questions.
I'll answer each point in turn (I hope this web based client doesn't mess
it up :)
Just a reminder, that our client needs to approve the PIC project if I am
to work on it, so don't expect additional patches from me just yet :)
-Original Message-
From: Werner LEMBERG w...@gnu.org
To: mic...@monfort.co.il
Cc: freetype-devel@nongnu.org
Date: Fri, 23 Jan 2009 09:56:00 +0100 (CET)
Subject: Re: [ft-devel] Position Independent Port of FreeType2
. Please stay in the 78 column width limit. At least one
C preprocessor doesn't like
#define FOO( bar, \
baz ) ...
but this is a bug in this program, so we don't care.
So I should stay in 78 columns even thought there is a buggy preprocessor
that does like it, right?
. I don't like having macros with parameters looking like a function
which can't be closed with a semicolon. This is error prone. I
always want this:
FT_FOO(bar);
So please add proper
while ( 0 ) do { macro body }
constructs where necessary.
I certainly don't mind, but it seems that the while trick would only work
with macros that are inside function bodies.
Most of the macros I made either define program level functions or structs.
While most of them look like a function, they definitely cannot be used as
functions.
When possible, I'll try to get the macros to behave as you want.
. If possible, prepare a set of patches, together with proper
ChangeLog entries, which builds up your modifications step by
step. This greatly simplifies understanding your changes. Note,
however, that I don't want to force you to artificially reduce the
size of the patches. The diffs should be rather logical than
small.
When (and if) our client approves this, I'll definitely submit the patches
in a much more orderly fashion.
This was more of a pilot test.
. Is it possible (and useful) to move the large code chunk which
modifies ftinit.c to ftpic.c?
BTW, somewhere in the diff there is a typo `defualt'...
Thank you. They always creep up on me :)
However, I can't figure out how to get there from the various
functions inside a module :( As you can see, autofit still stuffs
its own data into FT_LibraryRec, but this isn't very good. Help?
Not yet, sorry. I have a lot of other things to do.
Like I explained, no rush at all - this was a pilot/test case thing so
that you could see what I suggest, and so that I could tell our client how
much it would take.
We'll have time to figure it out when (and if) this project goes underway
from our side.
I feel that a general mechanism for this would be a boon, making it
possible for the various files comprising a module to store their data
directly, and the functions implementing them could access the module
easily. Possibly such infrastructure would also make other things easier.
in ftrend1.c there appears to be a hack that checks a pointer
directly (instead of having two different functions for two
different classes). I had to modify it to another hack (check the
number in the module's name.
Can you prepare a patch which fixes this issue? This seems to be
unrelated to your PIC changes.
In one sense this is related because the pic change made the original
pointers the hack uses unavailable.
The correct fix would be using different render functions for render1 and
render5, which would then do the relevant checks and then call the real
function. This would cost in one additional function call per glyph
rendering. My guess is that the original check was done to avoid this cost
(which is why even my PIC code uses a slightly different hack).
If the additional function call cost seems acceptable, I can submit such a
patch that separates to two different functions.
However this hack is really not very bad or hairy, as hacks go. It is easy
to figure out and not very likely to break. You could just as well leave
it there.
Which do you prefer?
3) So far I have converted the basic module/renderer/driver
interface,
and most of the autofit module.
I am not familiar with the insides of FT2, so can you sort of
guesstimate how much of the conversion work I already did? 1%? 2% ?
5%? 10%? 20%?
Even more, I think. Normally, the function tables which you have to
modify are located at the end of a FreeType source code file, so you
can look it up by yourself.
Indeed I had noticed that.
There is an area of FT2 that I am totally unfamiliar with, and that is the
make / jam based build system.
So far I've been building my own custom version with the instructions in
INSTALL.ANY.
Do you think the PIC change would need special care to be back ported
into the make files? (For example I saw some module related definitions in
various .mk
[ft-devel] Getting Module Pointer From a Module Function?
Is there a standard/good way to get the module pointer (not the module class, I am talking about FT_ModuleRec that contains the module's data). Case in point: I am working on af_face_globals_new() in autofit/afglobals.c which is part of the autofit module. Is there a way to get to the FT_AutofitterRec which is initialized during module init (AutoFitterRec is defined in autofit/afmodule.c) ? I could add the parameter explicitly, but is there a more standard way? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Position Independent Port of FreeType2
Werner LEMBERG wrote: I'm suspicious whether most FT2 maintainers find any worth to modify FT2 fitting to RVCT. Because, BREW is quite different from most FT2 developers are working for, and they cannot get free SDKs and emulators. Basically, I don't object. We are already using many, many macros :-) If few people decide to work for you, unfortunately, you have to modify FT2 code by yourself. The only thing FT2 maintainers can do is a review for your patch and comment if it's applied to CVS /or not. Yep. Provide a set of diffs together with proper ChangeLog entries, using the same formatting as the other parts of FreeType. To avoid extra work I suggest that you provide a first, simple case study how such macros should look like. Of course I will do the work. That's what I meant all along! I just want your help in designing/reviewing the proposed change before doing all the work, so that I can give our client a good estimate on how much work it would all entail (they ARE paying for this, after all...) I'll make a small case study as you suggested and send some diff files your way (should I just post the diff files as attachment to this list? or what?) Mickey ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Position Independent Port of FreeType2
The sample diffs are on the way (still tweaking), but in the meanwhile what about the following idea. Let's assume that: A) We are making a version of FT2 where const global data containing pointers is not allowed (PIC mode). B) All the various function tables, structs, etc. Must move into some structure that is allocated. Either an into an existing structure, or just a pointer inside an existing structure. C) The global data was previously easily accessible (it was just a symbol so every module could access it). Therefore the new location of this data must still be relatively easily accessible. D) Most of the code in FT2 (that contains global data that needs to be moved) resides inside a module (or a renderer/driver) and therefore there is a FT_Module_Class with an init function somewhere. E) A module's init function is called before any other work with the module or its global data is done. The module_done function is called after all work with the module is done. (Do these assumptions hold true? are they MOSTLY correct?) The idea: Each module can put its own const global data in its FT_Module_Class. The module's initialization/constructor function (module_init) is responsible for initialization of the global data that was moved. I assume that code in module X can easily get to the relevant FT_Module_Class for that class, via walking the pointer graph. Of course, the actual module table (as well as base code) still needs to be moved into SOMEWHERE. This somewhere can probably be in the LibraryRec. The module list (the table containing the various FT_Module_Class pointers, etc) will be initialized during FT_New_Library(). Same with other global data used by the base code. It seems to be that this method has the following advantages: a) modular. Module X doesn't need to know about Module Y's internal data. b) at least for modules (which are most of the code, see assumption D) there is a single, easy entry point to add initializations. No dependencies of the base code on the modules. C) again, for modules if some build of the library doesn't include module Z, then module Z's global data is not allocated. Please note that INSIDE each module, the solution would have to be tailored specifically for how the module uses the global data. I know this is kind of vague at this point without a working example, but still, any comments? Especially, am I assuming too much or missing something? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Position Independent Port of FreeType2
mpsuz...@hiroshima-u.ac.jp wrote:
Hi,
On Tue, 20 Jan 2009 15:31:59 +0200
Mickey Gabel mic...@monfort.co.il wrote:
const int x = 0; /* no problem */
const int* p = x; /* needs address fixup - can't be used in PIC */
char *list1[] = {zero, one, two}; /* pointers need fixup */
char list2[3][5] = {zero, one, two}; /* OK, no problem */
FT2 uses lots a lot of such constants, such as arrays of pointers to
structs and function tables. This is pervasive throughout all parts of FT2.
Hmm, in BREW development,
int x = 0;
int* p = x;
is bad, but
int x = 0;
int* p;
...
if ( FT_NEW( p ) );
goto Error;
else
p = x;
...
FT_FREE( p );
is acceptable? Using ft_malloc/ft_free for such purpose for
such purpose should be avoided?
Regards,
mpsuzuki
I must have explained this the wrong way.
The issue I am talking about (position independent code) is unrelated to
dynamic memory allocation (which is a different issue, more easily
solvable).
What I am talking about is that global/static data must be const, and
ALSO cannot contain ANY pointers, because those require relocations.
Let's take a real example from autofit/aflatin.c:
FT_CALLBACK_TABLE_DEF const AF_ScriptClassRec
af_latin_script_class =
{
AF_SCRIPT_LATIN,
af_latin_uniranges,
sizeof( AF_LatinMetricsRec ),
(AF_Script_InitMetricsFunc) af_latin_metrics_init,
(AF_Script_ScaleMetricsFunc)af_latin_metrics_scale,
(AF_Script_DoneMetricsFunc) NULL,
(AF_Script_InitHintsFunc) af_latin_hints_init,
(AF_Script_ApplyHintsFunc) af_latin_hints_apply
};
This is a global struct, which although const, contains many pointer,
that require relocations. This is impossible on BREW (and other systems
were the code must be position independent).
(global non-const variables are a big no as well).
Instead what can be done is something like:
1) Move the struct as a (non-const) member in another struct, for
example FT_LibraryRec_.
2) During initialization of autofit module (for example) you would call
this function which initializes all members:
void af_latin_script_class_init(AF_ScriptClassRec* ac)
{
ac-script = AF_SCRIPT_LATIN;
ac-script_uni_ranges = af_latin_uniranges;
...
ac-script_hints_apply = (AF_Script_ApplyHintsFunc)
af_latin_hints_apply;
}
3) Now in the code itself, instead of accessing af_latin_script_class
directly, it would get to the relevant member (in this example via the
library struct).
This of course gets a bit more complicated because there is ANOTHER
const table of pointers called af_script_classes which is again
forbidden, and needs to be moved to a struct somewhere.
in general, as a static/global variable:
int x = 0; /* not ok */
const int x = 0; /* ok */
const int *px = x; /* NOT ok */
const struct pnt1_t{ int x; int y; } point = {4,6}; /* probably ok? */
const struct pnt2_t { int x; int* px; } point = {4, x}; /*
definitely NOT ok */
Mickey
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
