[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
>line).
>
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
text_extents
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.
Chinese).
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
them.
John
More information about the cairo
mailing list