[cairo] Serious concerns about cairo

[Mike Emmel]

On 9/26/06, Ralph Giles <giles at ghostscript.com> wrote:
> 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. My predecessors on the webkit project dropped pango because
it was to slow.
I've not second guessed there analysis.

> 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?
>

Correct in that there are a number of higher level objects involved.
I'm not splitting the layout engine from them its a unified system.
All I wan't the layout engine too do is three things.

1.) Font subsitiution i.e find a resonable set of fonts that have a glyph

2.) Work with my scanner concept to break the string up into complex and simple
     regions which means provide a intial pass just to understand the
shaping requirments.
    and the fonts that provide the glyphs if a region needs advanced shaping
    mark it.

3.) Shape string regions that have a complex mapping between the unicode and
     the glpyhs and return the glyphs of course this works in the
simple case but
     since it told me in the scan pass that I don't have to shape the
text to get the glyph
     generally I'll just do simple mapping on the fly.

Above this I may need it to provide some helper routines say for
splitting words etc.
I recognize that there is more work to be done. Also by glyph I mean
the glyph indexes
not the actual glyphs I'll decide how I want to deal with these.

To my knowledge all the engines try to hide this behind a simple api
for programmers.
I'm not interacting with the engine as a application programmer but
instead trying to integrate it into a text layout engine. The reason I
want all the fonts thay provide a glyph
is I need to decide if I'm going to extract the glyphs and close the
font or perform other optimizations like combining a run of glyphs
into a single buffer there are a large number
of strategies I could use at this point to optimize the drawing.
Is the text editable ?
How big is the overall region ?
Do I need to underline or highlight ?
How big is the font itself does it scale ?
How many references exist for the font ?
Is  the font used for on the fly drawing ?

Mike