[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] [FYI] Re: Getting pathname from FT_Face (patch for future
From: |
Behdad Esfahbod |
Subject: |
Re: [ft-devel] [FYI] Re: Getting pathname from FT_Face (patch for future discussion) |
Date: |
Mon, 15 Mar 2010 22:52:52 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 |
On 03/15/2010 01:44 AM, address@hidden wrote:
> On Sun, 14 Mar 2010 21:19:44 -0400
> Behdad Esfahbod <address@hidden> wrote:
>
>> On 03/11/2010 02:47 AM, address@hidden wrote:
>>> Attached (get-stream-info.diff) is a revised patch with
>>> a feature to get the info about the origin of the memory
>>> in FT_Stream object, which is inspired by recent discussion
>>> with Behdad about mprotect() to the buffer in FT_Stream
>>> object. Sample code (get-stream-info.c) invokes the new APIs
>>> FT_Get_MemInfo_From_Stream() and FT_Get_Path_From_Stream()
>>> then shows results, aslike:
>>
>> Thanks! Looks interesting. I don't see the mmap() in there though.
>> What am I missing?
>
> I'm sorry for poor description, you missed nothing.
> get-stream-info.c does not invoke mmap() by itself,
> it reports if FT_Face->stream->base is allocated by
> mmap(), ft_alloc(), static buffer (for Amiga).
> If it is mmap()ed, it should be read only.
> If it is ft_alloc()ed, it can be modified without
> changing font file.
I understand that. I didn't see the code for returning mmap allocation type
in the patch though. I'm sure I just missed it.
>> Otherwise, looks like something I can use, yes.
>
> Thanks. Considering with another comment from you
> on my idea restricting memory allocation methods
> in FT_Face object creation, I have to switch "this"
> direction.
Sounds good!
> # 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 philosophy of
> # the encapsulation of FT_Stream.
I definitely had this concern myself when the Get_Path API was being
discussed. I think the stream meminfo is different however. And as Werne
pointed out, seems like getting the path is also something people find useful
anyway (oh and you have no idea how useful it would be for debugging!), so
lets add them.
Thanks,
behdad
- [ft-devel] Re: [FYI] Re: Getting pathname from FT_Face (patch for future discussion), (continued)
- [ft-devel] Re: [FYI] Re: Getting pathname from FT_Face (patch for future discussion), mpsuzuki, 2010/03/15
- Re: [ft-devel] Re: [FYI] Re: Getting pathname from FT_Face (patch for future discussion), Werner LEMBERG, 2010/03/15
- [ft-devel] Re: [FYI] Re: Getting pathname from FT_Face (patch for future discussion), mpsuzuki, 2010/03/15
- Re: [ft-devel] Re: [FYI] Re: Getting pathname from FT_Face (patch for future discussion), Behdad Esfahbod, 2010/03/15
- [ft-devel] Reference count in FreeType2, mpsuzuki, 2010/03/15
- [ft-devel] Re: Reference count in FreeType2, Behdad Esfahbod, 2010/03/15
- [ft-devel] Re: Reference count in FreeType2, Werner LEMBERG, 2010/03/16
- [ft-devel] Re: Reference count in FreeType2, Behdad Esfahbod, 2010/03/23
- [ft-devel] Re: Reference count in FreeType2, Werner LEMBERG, 2010/03/16
- Re: [ft-devel] Re: [FYI] Re: Getting pathname from FT_Face (patch for future discussion), Werner LEMBERG, 2010/03/16
- Re: [ft-devel] [FYI] Re: Getting pathname from FT_Face (patch for future discussion),
Behdad Esfahbod <=
- Re: [ft-devel] [FYI] Re: Getting pathname from FT_Face (patch for future discussion), Werner LEMBERG, 2010/03/16
- Re: [ft-devel] [FYI] Re: Getting pathname from FT_Face (patch for future discussion), Behdad Esfahbod, 2010/03/23