freetype-devel
[Top][All Lists]
Advanced

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

API: how much to expose


From: Stefan Seefeld
Subject: API: how much to expose
Date: Wed, 15 Mar 2000 09:34:20 -0500

David Turner wrote:

>    FT_Set_Char_Size  & FT_Load_Glyph can be translated either to:
> 
>       FT_Size_Set( face, ... )
>       FT_Glyph_Load( face, ... )
> 
>    or
> 
>       FT_Face_Set_Size( face, ... )
>       FT_Face_Load_Glyph( face, ... )
> 
>    The first case is confusing, at best, for most novice users, because the
>    first argument isn't a "size" or "glyph". The second isn't too bad,
>    but nearly all functions are methods of a FT_Face, and I find it
>    really redundant.

I don't really care about one notation or the other. Since I'm (still) planning
to write the C++ API for it, it'll all be wrapped to something like

face->setSize(...);
face->loadGlyph(...);

On the other hand, what is the Glyph_Load function supposed to do ? If
the result is cached inside the face object (the glyph slot), why having this 
function at all ?
I mean, couldn't the face load the glyph on demand and then cache it ? If glyph
caches are part of the face's private state, I'd consider them to be 
implementation
detail so I would *not* expose them via such a function call. On the other hand,
if there are chances that someone wants to fine tune his application and keep 
full 
control about this, I'd rather *completely* outsource the glyph cache into a 
different
object and let the face object bind to it. For example the face could have a 
pointer to
a glyph cache which either points to a private buffer (default) or an assigned 
buffer.
This buffer then would become a 'first class citizen' of freetype's API even 
though
users aren't forced to use it (same with all the other low level tools such as 
streams,
allocator etc.)

Having another look at the API docs, I think what I'm asking for is:
Can't the 'Glyph slot' be separated from the Face ?


Regards,        Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: address@hidden

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...



reply via email to

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