On Sun, 14 Mar 2010 21:19:44 -0400 Behdad Esfahbod <[email protected]> wrote:
>On 03/11/2010 02:47 AM, [email protected] 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. >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. >On 03/13/2010 06:53 AM, Werner LEMBERG wrote: >> >> Very nice! If Behdad thinks this is useful just add it to the git >> repository. Shall we control this by an FT_CONFIG_OPTION_XXX macro? > >I'd rather it be enalbed unconditionally. Indeed. I guess, Fontconfig, Cairo, HarfBuzz, Pango and GTK+ developers don't want to make their softwares dependent with FreeType2 under non-default configuration. Maybe, it is expected that new feature is available in widely distributed libfreetype binaries on free Unix-like systems. Werner, except of the code size, do you have any concern about my patch? I will post about the code size evaluation. # 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. Regards, mpsuzuki _______________________________________________ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
