[Cairo] Re: [xsvg] cairo_text_extents ?

[Carl Worth]

On Nov 25, John Ellson wrote:
 > Carl Worth wrote:
 > >	typedef struct {
 > >	    double left_side_bearing;
 > >	    double right_side_bearing;
 > >	    double ascent;
 > >	    double descent;
 > >	    double x_advance;
 > >	    double y_advance;
 > >	} cairo_text_extents_t;

The structure above is influenced by the XCharStruct structure from
Xlib.

I'm doing a survey now to see how glyph metrics are defined in various
systems. The PS specification shows a figure with "left sidebearing",
"glyph width", and "bounding box", but it's not clear how the bounding
box is specified.

The PS specification also references the Adobe Font Metrics File
Format Specification which specifies the glyph bounding box as being
four values, (llx, lly, urx, ury).

I'm still looking for other systems' metrics, so if anyone has a
favorite, please point it out to me.

 > 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.

Ah, right, I should have mentioned FreeType above. It provides the
following values:

	BearingX
	BearingY
	Width
	Height

So far, the only thing that's clear to me is that we don't have clean
consensus on how glyph metrics should be represented. ;-)

 > 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.

All of the values at the cairo interface are in user space
coordinates. So, if you're dividing by font size after
cairo_text_extents, then it's not returning the right thing yet.

 > 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.

Within a cairo_font, there's a single matrix. For the sake of the font
renderer, two scale values are extracted from the matrix and supplied
as the font size (see _get_scale_factors). This is important to do so
that font hints are applied properly.

The other relevant transformation is gstate->ctm which maps from user
space to device space. Its inverse is also available.

So I think we do have all of the necessary information.

 > 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.

Keith and I just chatted about this issue. The idea he came up with is
to require an FcPattern argument to cairo_ft_font_create_for_ft_face.
This pattern would contain only font rendering options (including
FC_VERTICAL_LAYOUT). Any face-specifying options would be ignored.

With that change in place, all cairo_ft_font objects will have an
FcPattern, and we can simply query that for the value of the
FC_VERTICAL_LAYOUT property to return the right metrics.

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

I'm working on this now. If you're interested in helping out in
realtime, I'll be in the #cairo channel on irc.freenode.net.

Thanks,

-Carl