[cairo] Serious concerns about cairo

[Mike Emmel]

On 9/23/06, Vladimir Vukicevic <vladimirv at gmail.com> wrote:
> On 9/23/06, Mike Emmel <mike.emmel at gmail.com> wrote:
> > Now as far as Mozilla goes I've looked at their SVG implementation
> > its far form complete and it sounds like they have already made a lot
> > of contributions. My orginial email suggested waiting till after they get
> > a reasonably complete implementation done before considering a api
> > freeze. Have they told you they are far enough along that they feel like
> > cairo will meet there needs ? I don't think they have done the
> > animation support yet for example.  I think I've actually got a more
> > complete implementation they
> > they do at the moment mainly of course because I could build on the
> > changes the y have already submitted.
>
> You probably do -- we actually have very little interest in Cairo as a
> SVG backend; instead, we are using Cairo as the general rendering
> engine for our entire browser.  The above changes and additions were
> not motivated by SVG at all; instead, they were based on things that
> we needed (or thought we needed) to solve some other problems.  So
> waiting for us to "finish SVG" to give feedback for cairo is probably
> not useful, as that is not our goal.
>
Considering my entire front end is written in SVG on top of cairo I'd say
I'm  doing the entire brower cairo. You can see my concern about paths
since its SVG for the whole system.


> > In reality you can easily support ucs2 and glyphs and this api is needed.
>
> No, you can't.  If you do a simple ucs2 -> glyph mapping, you are
> trading one toy font api for another toy font api.  Someone will run
> into the same brick wall and have the same "dead code" problem that
> you ran into, not to mention adding a -ton- of code to cairo that
> someone has to maintain that once again doesn't actually solve the
> whole problem!
>
You claim that the ucs2->glph rendering is not a good backend path for
a advanced text layout engine I disagree. Its not the only path you
need for the complete solution but its the one used the vast majority
of the time.
Sure you need other paths I did not say you did not.

And there is not tons of code to maintian this is already in cairo.

Hmm
cairo-unicode.c
and the first step in the font drawing it to call either
_cairo_utf8_to_ucs4
or
_cairo_utf8_to_utf16

Okay I'm fine with utf16  I don't need ucs-2 there the same except
for the surrogates.

I can detect earlier if it needs to be ucs4 or utf16.

Have you looked at the cairo font code the first thing it does is
convert from utf8 to ucs4 or utf16

all you need to add are entry points to allow these to be sent in.
And one new function that returns the glyph index.

There is no new code just a few new entry points.

Agian the argument is to not expose capabilites that already exist
in cairo simply because they only solve 99% of the use cases.

Cairo right now supports ucs4 and utf16  today and is capabale of
providing the glyph index for a font given a ucs4 or utf16 encoded char.

All you need to do is expose the text_glyph functions with
the addition of entry points for ucs4 and utf16
which all the backends immediatly convert to.


>     - Vlad
>