[cairo] Cairo + Pango

Jost Boekemeier jost2345 at yahoo.de
Sun Aug 8 02:20:37 PDT 2004


I guess my suggestion was a little bit unclear, so please let me try
again. :)

As I understand it, cairo is only a vector graphics API.  Drawing or
showing text does not belong to such an API.  In fact it is possible to
feed text into cairo with only the compose/surface_show operations (I
think :>).

Now, cairo contains an API to show simple text, which is okay.  My
problem with this is only that this API does not sit on top of the
library but is implemented deeply within the lib. 

If we pull the forAll glyphs loop with the glyph cache out of cairo into
a convenience function and implement the text->glyph transformation in a
convenience function, too, then an implementation above could re-use
these functions.

To be more concrete:

cairo_show_glyph(cairo_t *ct, cairo_surface_t*glyph, double x, double y);

would be the only API function.  But there would also be a
cairo_get_glyph(cairo_t, string, int) convenience function as well as a
cairo_show_text convenience macro which combines them.

Why  would this help me?  Well, the retained implementation would simply
wrap the cairo_show_glyph and re-use the cairo_get_glyph convenience

On Sat, 2004-08-07 at 19:58, Jon Smirl wrote:
> If I read the Microsoft docs right Longhown has an API where you pass
> in all of the glyphs and floating point x/y coordinates for them. 

If you want to display glyphs in X, you would use XFT anyway (which I
think _can_ send more than one glyph in a single message, at least the
render protocol allows this).  

Cairo currently composes one glyph after the other.  It might be
possible to add a XFT backend to cairo's font backends, but I think it
does not belong there.  I think a good text interface would sit on top
of cairo.  Pango for example.

> The
> floating point positioning is used to achive subpixel placement of the
> glyphs.

I could imagine that special hardware devices would need special
algorithms for AA text and graphics, but what do you mean with subpixel

> With DirectX 10 level hardware, assuming the glyph is in the video
> memory cache, all of this call can run on the graphics board. The
> performance numbers are well over 1M glyphs/sec.

Hmm, I still don't see the point.  Composing glyphs should be indeed
very fast, but what do they have that render does not support?  Do they
calculate the mask or the operation on the server-side or something?


More information about the cairo mailing list