[cairo] Reworking text handling

[Keith Packard]

On Mon, 2005-08-22 at 19:41 -0400, Owen Taylor wrote:
> I've only looked through the cairoint.h changes, but they look good to
> me... really no comments other than:
> 
> +typedef enum _cairo_scaled_glyph_shape {
> +    cairo_scaled_glyph_shape_none = 0,
> +    cairo_scaled_glyph_shape_surface = 1,
> +    cairo_scaled_glyph_shape_path = 2,
> +    cairo_scaled_glyph_shape_surface_and_path = 3,
> +} cairo_scaled_glyph_shape_t;
> 
> Doesn't seem to conform to Cairo style with upper case enumeration
> values (and why specify the numeric values?). You could also
> use a bitfield here of course.

Oops; I'll fix the case of the value names.

I used explicit values because I wanted to use & operators to
detect the presense/absense of the individual options. Is there another
style you'd prefer here?

>      cairo_status_t
>     (*scaled_glyph_init)       (void                        *scaled_font,
>                                 cairo_scaled_glyph_t        *scaled_glyph,
>                                 cairo_scaled_glyph_shape_t   shapes);
> 
>      cairo_status_t
>     (*scaled_glyph_ensure_shape)(void                       *scaled_font,
>                                 cairo_scaled_glyph_t        *scaled_glyph,
>                                 cairo_scaled_glyph_shape_t   shapes);
> 
> I don't really understand the relationship between these two - what
> does init() do? If we need a separate init(), wouldn't it be cleaner
> to omit 'shapes' from it and just init() then ensure_shape()?

Yes, these two are rather muddled together. glyph_init is the same as
glyph_ensure_shape except that it also computes the glyph metrics. 

There are two reasons for this particular style, the first is that
glyph_ensure_shape was added later, which of course isn't relevant.

The second reason they are different is that loading the glyph is
expensive, and you have to load (and hint) the glyph to compute metrics
and to compute either the path or the surface contents. Combining these
two steps into one function is a significant performance benefit.

Inside the ft backend, I've actually merged these two into a single
function with an additional boolean parameter -- need_metrics which
says whether to compute the metric information. We could use that as the
single entry point if you'd like.

Thanks for taking a quick look at the changes.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050822/d7efac62/attachment-0001.pgp