[Cairo] Re: [xsvg] cairo_text_extents ?

[Bill Spitzak]

On Tuesday 02 December 2003 05:00 pm, John Ellson wrote:

> Bill, your proposal for two matrixes sounds quite reasonable.  The part I'm
> having trouble understanding is how your proposal differs from the code
> currently in Cairo.   From my recent reading of the code to implement
> text_extents, there are already two matricies.

Note: this is based on reading the newest cairo.h

It does appear that the current transform is serving the purpose of my 
text_matrix, and the matrix sent to cairo_trasnform_font is the same as my 
font_matrix. This is if cairo_text_extents returns values in the current 
transform, and not in either device space or in font space. I also assumme 
that cairo_scale_font(x) is the same as cairo_transform_font(x,0,0,x), right?

1. The main difference is that in my scheme, while the glyphs are transformed 
by exactly the concatenation of the matrices, the "advance" values are 
instead calculated by the font based on the font_matrix, in possibly 
font-specific ways. In particular it cannot have a non-zero y_advance and 
thus the advance cannot rotate even though the font transform can. Also if 
the font defines a "vertical advance" value then when it is rotated 90 
degrees the x_advance should change to this value. Also the exact point 
rotated around should be decided by the font, so that as  you rotate the 
letters it smoothly transitions from horizontal to vertical layout (this 
rotation point can be figured out for each letter from a font description 
that has both horizontal and vertical metrics).

In the cairo design I have no guaranteed way to make y_advance be zero. Even 
if I don't rotate the font transform the interface seems to allow the font to 
set it non-zero, perhaps due to internal rounding to pixels when the main 
transform is rotated. I want to be able to *guarantee* (by making it not 
exist in the interface) that y_advance is zero. If this is not forced, there 
are two ways to lay out tilted text (rotate the text_transform, and rotate 
the font_transform), where the advance values may be calculated differently 
(one by the font and the other by the calling program), and thus output text 
will not match between them, which is a bad thing that Cairo is supposed to 
fix.

2. I also had this idea to split the text_transform from the current 
transform. The reason was so that you could place labels using a different 
transform than is used for the characters. This would not be necessary if 
restore() would leave the current point and path unchanged, but it appears 
that is not how Cairo is designed, so it looks like we need something like 
this. I like the idea of only being able to copy the current transform to the 
text transform, to avoid having to add a dozen new calls to manipulate it.

3. The header mentions a "cairo font_t". I think this is a bad idea. In 
*every* program I have ever written that handles more than a small fixed set 
of fonts, I have been forced to implement a hash table that turns names into 
"font objects" and to implement some LRU scheme to throw them away. I think a 
great deal of savings could be had by having Cairo do this instead, it is 
probably much smarter about knowing which fonts are in use, and the hash 
table will be shared even if several different drawing libraries are used 
atop Cairo. Also it can hash different scalings if it wants.

-- 
                   ,~,~,~,~ ~ ~ ~ ~
     /\_       _|_========___         Bill Spitzak
 ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com