freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] FT_New_Memory_Face free buffer? (v2.2.1, win32)


From: Darkvater
Subject: Re: [ft-devel] FT_New_Memory_Face free buffer? (v2.2.1, win32)
Date: Fri, 8 Dec 2006 23:06:51 +0100

On 12/8/06, Werner LEMBERG <address@hidden> wrote:

> My actual question is that, obviously you do need to free the buffer
> yourself when using FT_New_Memory_Face.  Regarding this, I have one
> question and one proposal.  The question is how can I reliably
> determine from the face itself if the font was loaded from Memory?

A good question.  Why do you need that?  Up to now nobody has ever
requested that.

We are using Freetype for our project and to be more user-friendly and
give more functionality also support specifying fonts by font-name,
and not just filename (so if a user specifies a filename in the config
it's loaded by filename, otherwise by font-face). For windows we
didn't want to use FontConfig because it is too big, and can easily be
done with native Win32 API function.
The initial implementation used CreateFont() and GetFontData() to read
the font data into a memory buffer allocated dynamically and using
FT_New_Memory_Face. Obviously when the font is no longer needed I need
to deallocate the memory allocated previously by the call to
GetFontData().
If FreeType cannot tell me what type of allocation it used for the
font (eg memory, file-pointer, etc.) I have to keep track of this
myself. This was the reason why I asked.


> My suggestion would be to create an additional FT_Done_Face() function
> that not only accepts an FT_Face paramter but also a second one, which
> when set to free also frees any user-supplied buffers to FreeType.

Mhmm.  How shall your proposed FT_Done_Face_Memory function know which
deallocation function it should use?  It's far easier to say: You
allocated the stuff, so you deallocate it too.

Yes, I think you might be right about that. Therefore I think only a
function returning the type of allocation used would be more useful.

    Werner

Thank you for your reply and the update of the documentation.

Farago Tamas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]