Hi Werner
Thanks alot for the reply. I have looked at your suggestion and tried to
understand how it works.
I have one question regarding this. I understand that after we set env
variable FT2_ALLOC_COUNT_MAX and FT2_DEBUG_MEMORY on runtime, the value for
FT2_ALLOC_COUNT_MAX will be assigned to ta
On Mon, 15 Mar 2010 14:44:29 +0900
mpsuz...@hiroshima-u.ac.jp wrote:
>I will post about the code size evaluation.
Here is the result by Linux/i386 gcc-4.4.2.
My patch increases the code size about 1% - 2%.
I think enable-by-default won't blow out most
systems using FreeType2 under default config.
> Here is the result by Linux/i386 gcc-4.4.2.
> My patch increases the code size about 1% - 2%.
This is more than I have expected.
> I think enable-by-default won't blow out most systems using
> FreeType2 under default config.
OK. However, it would be nice if it is surrounded by
FT_CONFIG_...
> Does the above check aim to bound memory allocation to up to
> table->alloc_total_max? If that is the case, should the check be the
> following instead:
>
> if ( table->bound_total &&
> table->alloc_total_max - table->alloc_current < (FT_ULong
Werner,
Now I'm reworking my patch to provide a single generic
interface like this:
/*/
/* */
/*
On 03/15/2010 01:44 AM, mpsuz...@hiroshima-u.ac.jp wrote:
> On Sun, 14 Mar 2010 21:19:44 -0400
> Behdad Esfahbod wrote:
>
>> On 03/11/2010 02:47 AM, mpsuz...@hiroshima-u.ac.jp wrote:
>>> Attached (get-stream-info.diff) is a revised patch with
>>> a feature to get the info about the origin of the
On 03/15/2010 08:36 AM, mpsuz...@hiroshima-u.ac.jp wrote:
>
> FT_EXPORT( FT_Error )
> FT_Object_Get_Property( FT_Librarylibrary,
> FT_Pointerobject,
> const char* object_type,
> const char* property
On Mon, 15 Mar 2010 22:55:52 -0400
Behdad Esfahbod wrote:
>In another note, since you seem to be writing a lot of FreeType patches
>recently, it doesn't hurt to ask: have you ever considered implementing
>reference counts for FreeType?
I remember you had ever mentioned the lack of some features
i
On 03/15/2010 11:43 PM, mpsuz...@hiroshima-u.ac.jp wrote:
> However, yet I've not figured out the detailed usecase for
> reference counter of FreeType2 (so I cannot write short testing
> code), thus I cannot start working just now. If you know any
> softwares showing the problem caused by the lack
>> FT_EXPORT( FT_Error )
>> FT_Object_Get_Property( FT_Librarylibrary,
>> FT_Pointerobject,
>> const char* object_type,
>> const char* property_name,
>> FT_Pointer* proper
>> # One of my concern (except of the code size) is that APIs like
>> # FT_Get_Path_From_Stream() is a bad idea from the viewpoint of
>> # software design, and it can encourage badly- designed FT2
>> # clients. FT_Get_MemInfo_From_Stream() might not be so bad, but it
>> # could conflict with the ph
> # Werner, if the inexistence of reference counter was designed,
> # please let me know.
Not that I'm aware of. David was probably thinking more in `embedded
mode' where other issues are of greater importance.
Werner
___
Freetype-devel mailin
> Use case is very simple: with the FreeType stack, all of hb_face_t,
> PangoFont, and cairo_scaled_font_t all can use keeping a pointer to
> an FT_Face. But alas, one cannot do that safely since you never
> know when the face is going away.
Again: What would you like as an interface? Something
> First of all "source->width >> 3" is 0 for widths < 8 and the whole
> loop is skipped. So we need to make the condition j >= 0.
This is definitely a bug.
> Next thing is "tt[0] = (FT_Byte)( ( val & 0x80 ) >> 7 );" etc etc..
> The corresponding bit is masked and shifted. But this way only the
14 matches
Mail list logo
