[Cairo] Re: [xsvg] cairo_text_extents ?

[Carl Worth]

On Dec 3, Bill Spitzak wrote:
 > Draw horizontal matching labels next to scaled symbols drawn with arbitrary 
 > transforms:

OK, I see what you're getting at now.

But that is just one particular layout mode. Any API change to make
this mode easier would necessarily make other modes, (eg. labels
rotated along with objects), more difficult.

And the layout problems you're talking about affect more than just
text. Layout for different objects has the exact same issues, but
would not be addressed by adding a new text-specific matrix.

And cairo already allows the user to manage external matrices via
cairo_set_matrix and cairo_current_matrix. Those calls should let you
do exactly what you've described, but in a manner that is simpler,
more flexible, and consistent with PostScript.

 > You can avoid the need to replicate the transform in Postscript by doing a 
 > moveto and then grestore and then drawing the label. This still requires 
 > excessive gsave/grestores, and it also seems it may not work in
 > Cairo.

Are you claiming that cairo_move_to/cairo_restore behave fundamentally
differently than PostScript moveto/grestore? If so, that's a bug, and
I would be quite interested to see a test case so we can fix this.

 > This makes sense, but I would not publicize the existence of any cairo_font_t 
 > in the portable interface, instead making a different type for each specific 
 > interface.

The system-specific fonts really are different for each system. For
example, in the current interface there are 3 Freetype-specific
cairo_ft_font_* functions that accept a cairo_ft_font. These functions
just won't do anything if you give them a cairo_font_t created with
anything but one of the cairo_ft_font_create_* functions. The type
situation is not ideal, but that's what you get with C.

 > Instead the "toy" api should accept complex strings that can describe a font 
 > in the device-specific API.

No, I don't want to go there. That's why I keep using the word "toy" here.

 > This is necessary so that a program can use the "toy" api and still select 
 > fonts that are given to it by a configuration program that understands the 
 > device.

No, if you want platform-specific fonts, then use the platform-specific API.

 > Without this either the amount of GUI configuration that can be done 
 > is limited to the portable api, or people writing GUI programs are forced to 
 > use the device-specific api, ruining portability, or there is inconsistent 
 > results between programs, which is something Cairo is supposed to
 > solve. 

Cairo aims for device independence within a platform, but not
necessarily platform independence. This stance was arrived at after a
long discussion of the text API this summer:

http://cairographics.org/pipermail/cairo/2003-August/000367.html

(And note that with that terminology I've been saying
"device-specific" fonts where I should have been saying
"platform-specific".)

-Carl