[Cairo] Review of text API in new virtualized font interface

Keith Packard keithp at keithp.com
Tue Oct 21 12:19:38 PDT 2003


Around 14 o'clock on Oct 21, Carl Worth wrote:

> Keith, with an eye toward those calls, we can get away
> with dropping the font field from the glyph structure, correct?

Yes, the cairo_glyph_t should not have a cairo_font_t * in it.

> Why don't we follow the naming convention from CSS2 here. We can even
> throw in the CSS2 weight values if we want, though I don't know if
> that's really important:

If you're going to use CSS2, you might as well stick all of the values 
into the typedef; it's 'free'; the underlying code can simply compare <= 
NORMAL and > NORMAL for not-bold/bold.

> typedef enum cairo_font_style {
>     CAIRO_FONT_STYLE_NORMAL,
>     CAIRO_FONT_STYLE_ITALIC,
>     CAIRO_FONT_STYLE_OBLIQUE
> } cairo_font_style_t;

Style includes many attributes not covered here, this really is just slant.

> Of course, rename slant to style here as well. I think we're probably
> fine ignoring variant and stretch from CSS2 since the idea here is to
> make a simple text-selection API, not necessarily a complete one.

Absolutely; this API does only weight and slant.  If you want more, go get 
yourself a real font API.

> There was quite a bit of discussion about whether fonts should be
> resizable or fixed to a single-size at creation time. I think that the
> user should be able to transform a font after creating it. We can be
> lazy about resolving the font until it needs to be drawn.

cairo_select_font/cairo_set_font should always be followed by 
cairo_scale_font/cairo_transform_font.

> And, if needed, we can freeze the font after it has been resolved. We can
> also add cairo_font_freeze/cairo_font_thaw calls or similar if the user
> needs to control this. So I propose keeping the cairo_font_transform call.

Freeze/thaw?  I don't see the point here.  With cairo_set_font, there may 
be device-specific 'issues' with scaling fonts, but that's not our problem 
in this part of the API.

> The freetype-specific portion of the API should be moved into a new
> file cairo-ft.h.

I thought we'd discussed this and decided that cairo.h should be 
sufficient on every platform and that applications can do feature 
dectection to discover what cairo APIs were available.  Namespace polution 
from external librarys could be prevented by having some convention like

	#define CAIRO_FREETYPE 0
	#include <cairo.h>

	...
	#if CAIRO_FREETYPE
		FT_Face	f = ...
		cairo_ft_create_font (f...)
	#endif

By default, CAIRO_FREETYPE would be set to 1 and the relevant freetype.h 
headers loaded into the compiler.  I don't want to need a include lines 
just to use cairo.

Other than that, I like Carl's other suggestions about the API (and the 
existance of a prototype implementation as well!)

-keith






More information about the cairo mailing list