[cairo] Font interface problem (+win32 stuff)

Maarten Breddels dmon at xs4all.nl
Fri Apr 9 17:34:42 PDT 2004


> From: cairo-bounces at cairographics.org 
> [mailto:cairo-bounces at cairographics.org] On Behalf Of Carl Worth
> Sent: maandag 5 april 2004 16:07
> To: Banlu Kemiyatorn
> Cc: cairo at cairographics.org
> Subject: RE: [cairo] Font interface problem
> 
> 
> On Apr 5, Banlu Kemiyatorn wrote:
>  > I don't know if I like glyph_t to have both x,y in it. In 
> openstep framework
>  > we use an array of glyphs that only contain the index 
> value. It's the typesetters
>  > that will find the positions of the glyphs so I really 
> wonder if letting users
>  > to fill the glyphs' positions by themselves is actually 
> the right design. (Using this
>  > internally is understandable but I think making x,y in 
> glyph_t visible is confusing)
> 
> It's not so much that we expect "users" to fill in the glyph positions
> themselves.
> 
> What's going on here is that we recognized that various platforms have
> different "native" font systems which must be used for user-visible
> consistency. However, it would not be feasible to abstract these font
> systems within cairo. So, instead, cairo just exposes the native font
> system. (Currently, freetype is the only such system exposed by cairo,
> but I would expect others to appear if cairo matures on non-Linux
> platforms.)
> 
> So, the x,y stuff in the glyph allows code above cairo to call into
> freetype and pass values into cairo. If you don't expect your "users"
> to call into freetype, then this functionality can be abstracted in a
> layer above cairo.
> 
> -Carl

About the font interface:
I think the glyph structure is usefull, in addition I think kerning
information should also be available, to make things possible no font
api can ever provide. Making 3D text for instance.
That's why I also made these changes to the font backend, I've added the
following to cairo.h:

    typedef enum cairo_font_y_direction {
    CAIRO_FONT_Y_DIRECTION_NORMAL,
    CAIRO_FONT_Y_DIRECTION_INVERSE,
    } cairo_font_y_direction_t;
      
    typedef enum cairo_font_scaling {
    CAIRO_FONT_SCALING_LINEAR,
    CAIRO_FONT_SCALING_WITH_HINTING,
    } cairo_font_scaling_t;

    CAIRO_EXPORT(void)
    cairo_select_font_ex (cairo_t              *ct, 
		    const char           *family, 
		    cairo_font_slant_t   slant, 
		    cairo_font_weight_t  weight,
            cairo_font_scaling_t scaling,
            cairo_font_y_direction_t direction);

Where CAIRO_FONT_SCALING_LINEAR means that the font only uses
hinting(when available) based on the font matrix. This makes perfect
zooming possible.
CAIRO_FONT_SCALING_WITH_HINTING means that hinting is based on the
'fontmatrix * CTM' matrix 
CAIRO_FONT_Y_DIRECTION_NORMAL means the font x and y axis are like in
userspace(CTM). CAIRO_FONT_Y_DIRECTION_INVERSE is like with an inverse y
axis.

cairo_select_font is the same as cairo_select_font_ex with
CAIRO_FONT_SCALING_WITH_HINTING, CAIRO_FONT_Y_DIRECTION_INVERSE as last
2 arguments.

I've also implemented kerning in the win32 and the freetype backend.

Does this all seem ok?

Btw, there appears to be a bug in freetype, described here:
	http://www.freetype.org/pipermail/devel/2004-March/010371.html
But I got no reaction. I also tested it on linux today, and there it
doesn't occur.

-Maarten Breddels





More information about the cairo mailing list