[cairo] Serious concerns about cairo

[Ralph Giles]

On Tue, Sep 26, 2006 at 08:14:56AM -0700, Mike Emmel wrote:

> Even if I have to scan the string twice to optimize the rendering its
> way cheaper
> then sending it to the shaper. Related but also easily handled is the
> font providing
> the glyph but this is another point I would need to split if the string.

If this is the case, shouldn't the layout engine (e.g. pango) just do 
this internally?

I don't know much about this, but it seems like for naive string drawing 
you need two pieces. You need to turn a utf8 (or other unicode) string 
into a sequence of (glyph, drawing position) structs, and then you need 
a drawing engine to parse and draw that to your surface.

If you're rasterizing the glyphs, a cache is important for performance, 
so I wouldn't be surprised if region analysis and a codepoint to 
glyph-in-some-font cache is important for the other half.

But as far as that goes, I don't understand why the separate, one-to-one 
codepoint-glyph mapping fast path needs to be exposed in the layout api. 

If you're trying to do more sophisticated layout than "draw this string" 
you have to have feedback about how big various substrings rendered with 
various parameters turn out to be for hyphenation/justification, and for
that I can see that dividing the text into subregions at a higher level 
might help. Is that the sort of application you're talking about?

 -r