[Cairo] Re: [xsvg] cairo_text_extents ?
spitzak at d2.com
Wed Dec 3 13:15:32 PST 2003
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
setupfont // select font for label
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
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
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.
> 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
More information about the cairo