[Cairo] Re: [xsvg] cairo_text_extents ?

[Bill Spitzak]

On Wednesday 03 December 2003 06:20 am, Carl Worth wrote:

>  > 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.
>
> Can you come up with something like a pseudo-code sequence
> demonstrating a problem you can't solve with the current API?

Draw horizontal matching labels next to scaled symbols drawn with arbitrary 
transforms:

setupfont // select font for label
gsave
translate a,b, rotate c // go to transform 1
drawsymbol x1,y1 // draw a scaled symbol
moveto x1,y1; drawlabel // draw horizontal label
rotate d // go to transform 2
drawsymbol x2,y2 // draw another symbol, rotated
moveto x2,y2; drawlabel // draw horizontal label
grestore
gsave
translate e,f; rotate g; scale h // go to transform 3
drawsymbol x3,y3 // draw a different-sized symbol
moveto x3,y3; drawlabel // draw horizontal label
grestore

Without the independent text transform, this *can* be done, but only by doing 
a gsave & grestore and redoing the transform around every symbol and only by 
replicating all the transform math in the application so that the xy position 
for each label can be calcuated correctly.

Drawing all the labels last avoids the multiple gsave/grestores, but it does 
not produce exactly the same output due to stacking order, and you still need 
to replicate the transform math in the application.

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.

Plenty of programs using existing drawing api's, especially OpenGL, but also 
most existing vector libraries written atop Xlib or GDI32, are written to 
assumme that they can draw such labels efficiently. Rewriting these programs 
would be very difficult.

> We've
> tried to base the text manipulation API on PostScript, and I don't
> want to complicate the interface without solid evidence that there's
> something lacking in the PostScript model.

Yes I agree that is the biggest problem with the text_matrix. However I think 
I have a solution in that the *only* way to change the text matrix is to set 
it equal to the current transform (also grestore will change it back to a 
previous value). The PostScript model is duplicated by copying the current 
transform to the text matrix each time the current transform is changed, and 
a program will not be able to deviate much from the PostScript model.

>  > 3. The header mentions a "cairo font_t". I think this is a bad idea.
>
> Font management is extraordinarily complex and differs from one system
> to the next...
> Instead, we provide the "toy" API with string-based font names for
> people like me that just want to display some text without thinking
> about it much. Any "real" font use requires constructing a
> cairo_font_t via an external font system.

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. It seems to me that the device-specific interfaces would like a 
lot of freedom in how a font object works, for instance a "font_t" may 
correspond to a whole "family", or it may want to correspond to only a 
particular font_matrix, or even to a particular final transform, subset of 
glyphs, or even compositing operation. Also the device interfaces will want 
different ideas about who owns the font_t objects, who creates them, who can 
destroy them, and how they are cached, etc. All of this is defeated if we 
make up rules for what a font_t is.

Instead the "toy" api should accept complex strings that can describe a font 
in the device-specific API. These strings should be designed so if they are 
fed to a different device, it can make a reasonable guess. For instance 
"HelveticaBold WIN32_SPECIAL_FEATURE WIN32_STRANGE_ADJUSTMENT=7 
WIN32_GOBBLYGOOK=silly" is the type of string I would expect. The X version, 
fed this windows-string, would probably only recognize the "HelveticaBold" 
part and ignore the rest, and hopefully produce a close approximation.

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. 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. 
Notice that these strings are vital even if the program uses some Pango-like 
library that knows all about the device-specific API.

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