[Cairo] Re: [xsvg] cairo_text_extents ?
christof at petig-baender.de
Wed Dec 3 00:17:48 PST 2003
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
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?
More information about the cairo