[Cairo] Re: [xsvg] cairo_text_extents ?

[Christof Petig]

Bill Spitzak schrieb:
> There are two 2x2 matricies: the text_matrix, and the font_matrix. Font 
> glyphs are transformed by the concatenation of these matrices before being 
> drawn.

got it. Liked it.

> 1. It gets rid of the confusion about what coordinate system font 
> measurements are in.

I see the problem. (I do not understand yet which coordinate system will 
be used - but I trust your design, it simply _sounds_ well thought out!)

So no need to explain to me. But I have two different issues (see below):

> 2. It allows y_advance to be defined as zero, while still allowing rotated 
> letters, and rotated baselines.
[...]
> However font metricies and text advance direction are NOT 
> independent, in fact the "y_advance" is defined to always be exactly zero. It 
> may also be that "x_advance" is defined to be >= 0. This non-independence was 
> far more important to me because of the huge simplification of layout code.

Please do not envision a text API which does not work well with arabic 
(right to left) or CJK scripts (can be top to bottom)! Sadly I don't 
know enough about it to judge.

Looking at the freetype graphs it seemed to me that CJK is a totally 
different beast. If a text matrix of ( 0 1 ) ( -1 0 ) (-90° rotation) 
gives normal behaviour (font's y_advance) for a vertical font that's 
fine with me (but might be strange to people used to vertical fonts). 
Perhaps vertical advancement is the only right thing to do at 0°.

> This is so if you rotate 90 degrees you get 
> glyphs that can be laid out as vertical text (assumming a -90 degree rotation 
> is appled in the text_matrix). A rotation around the origin would not produce 
> anything nice for any proportional font.

You're right. That's why I spoke of an elliptical advance transformation 
(take the "bounding box + some space" for vertical layout of a 
horizontal script). But I am no longer sure whether this makes any real 
sense. It just sounded like a reasonable default (compared to the hassle 
of calculating a different rotation center for each glyph).

> No, the x_advance value will be set to produce the correct spacing.  If a 
> font actually contains "vertical advance" information, this is simply used as 
> the horizontal advance when 90 degree rotation is selected. If you don't use 

you mean character rotation here - right?

> the text_transform, you will see perfectly fine output if you turn your 
> monitor sideways.

> If a font description has a vertical advance dy and a horizontal advance dx, 
> I would transform the vectors (0,dy) and (dx,0) by the font transform, take 
> the absolute value of the x coordinates of the results and add them together, 
> and return this as the x_advance. Thus the information stored in the font is 
> not lost.

seems to be the perfect way to support vertical scripts (but I suspect 
that the y_advance taken as x_advance when not rotated will give 
suboptimal results - see below)

> In your example I would rotate the text_transform by 45 and the font 
> transform by -45. This font transform would produce an x_advance of 
> sqrt(2)/2*(dx+dy). The text_transform would turn this back into an x_advance 
> and a y_advance of (dx+dy)/2. If you imaging square letters, they boxes would 
> just touch at the corners.

If I imagine proportinal fonts I clearly get strange results. What do 
you think about the elliptical/bounding box proposal?

   Christof