[cairo] Serious concerns about cairo

[Mike Emmel]

On 9/24/06, Behdad Esfahbod <behdad at behdad.org> wrote:
> On 9/24/06, Mike Emmel <mike.emmel at gmail.com> wrote:
>
> > 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 don't want to get into this thread, as others have already replied enough
> and you just don't seem to get it.  As much as I respect your contributions
> to cairo, I also believe that you really have no idea what Unicode text
> rendering requires.  Anyway, just wanted to note that you are confusing ucs2
> with utf16.  Utf16 is the one with surrogates, and covers the entire Unicode
> range.  Ucs2 only covers the BMP.  Not the other way around.
>

First thanks for not being that helpful I wish you guys would back off a bit
and discuss this problem.

I looked at the OSX implementation and they route the simple api back through
a layout engine which means you get different results on different
platforms same for Win32.
Also the fallback code looks like it may be broken in the case that
multiple glyphs are returned for a single usc4 char since it can't
handle this case.

So it looks like the api will produce quite different results
depending on the platform. Platforms that fallback to the default will
not be able to handle the same charset range in fact it is basically
the same partial support hack that I have been proposing which I find
intresting considering the responses I've gotten for propsing it.

I guess the fix would be to add a pango
backend if you want to be cross platform compatible.

In any case I'm happy enough to follow the other platforms and route
the simple api back through a layout engine no problem I agree with
the approach. Its much better then what I've suggested (and what cairo
does ) which is to try and come up with some way to extend the simple
text api to handle more cases but still be broken.

Now I of course still feel there is no reason we can't have a layout
engine written in plain C that does not bring in a lot of dependencies
but thats my preference and problem.

> --
> behdad
> http://behdad.org/