[Cairo] Re: [xsvg] cairo_text_extents ?

John Ellson ellson at research.att.com
Tue Nov 25 11:24:46 PST 2003

Carl Worth wrote:

>On Nov 21, John Ellson wrote:
> > OK, Please try this.    The attached tar file contains cairo and libxsvg 
> > patches and 4 test cases.
>John, thanks for this contribution. Your timing is excellent as I just
>implemented cairo_text_path and was just starting to implement
>cairo_text_extents. Your patch has already fixed a couple of problems
>I was having.
>But, I do still have a question or two about the semantics of the
>cairo_text_extents_t structure. Currently, it looks like this:
>	typedef struct {
>	    double left_side_bearing;
>	    double right_side_bearing;
>	    double ascent;
>	    double descent;
>	    double x_advance;
>	    double y_advance;
>	} cairo_text_extents_t;
>Are the bearing values magnitudes or signed quantities?
They are signed.

> That is, which
>of the following calculations is correct:
>	/* magnitudes */
>	width = extents.right_side_bearing + extents.left_side_bearing;
>	/* signed */
>	width = extents.right_side_bearing - extents.left_side_bearing;

The latter.

>Second, will the use of the names "left" and "right" behave in a sane
>fashion when subjected to transforms with reflection?

I believe so, but some testing of rotations and reflections is needed.

>Third, could we get by with shorter names here, eg. left and right?
I was just filling in the existing structure.  Shorter names would be 
fine by me, except
that I do think they should correspond to freetype's conventions as far 
as possible.

>I'm having a hard time managing word wrap issues with equations like
>the one above, (eg. think trying to do "offset = width / 2.0" in one
Yes, I know what you mean, see libxsvg/xsvg.c in my patch.

Now that you've looked at my patch, I also have a couple of issues.

First, I'm uncomfortable with the need to multiply by the original fontsize
in xsvg.c.  I think it would be better if the units returned by the  
functions were those of the model.   The issue is that the scale from 
the font matrix
includes two factors: the fontsize from the model and the zooming factor 
from the
view.   I couldn't find either of these terms independently in cairo_gstate
to allow the text_extents code to rescale to the model.  Did I miss it?

If not, then I would like to propose that the original fontsize be kept 
in cairo_gstate.

Second, the freetype code is able to support vertical text strings (e.g. 

I'd like to propose that cairo_gstate maintain a flag for vertical text 
so that the
text_extents code can compute just the appropriate vertical or 
horizontal extents.

If these sound reasonable then I would be willing to prepare a 
subsequent patch for


More information about the cairo mailing list