[cairo] Serious concerns about cairo

[Mike Emmel]

On 9/23/06, Vladimir Vukicevic <vladimirv at gmail.com> wrote:
> On 9/23/06, Carl Worth <cworth at cworth.org> wrote:
> > As for providing mapping from a unicode character to a glyph index,
> > there has been some discussion of this in the past. I'm not an expert
> > in this area, but the last time the issue came up I was convinced by
> > well-reasoned arguments against including this support in
> > cairo. Similar arguments might apply to a ucs2-based API, though I'm
> > not sure. Again, I'd have to dig up those conversations to remember
> > the details.
>
> The basic issue is that cairo should not be in the text layout or even
> in the font business.  It should know how to render a glyph with the
> current source at the current position, with the current
> platform-specific font, and nothing more.  The "toy" text API was
> included as a concession to wanting to easily do simple text, but it's
> not intended to be a real text rendering API.
>
> Doing glyph lookups, rendering non-ascii script, font selection, etc.
> are all huge jobs, and are best done in a layer above cairo -- whether
> that's Uniscribe, ATSU, pango, or some custom-grown thing.  It's very
> easy to say "well, all I need is to just do glyph lookups for UCS2
> characters", until someone tries to render an Indic or other script
> where there isn't a 1-1 mapping... you end up either needing even more
> functionality added, pushing things closer and closer to pango, or you
> end up abandoning cairo for text layout and start using
> Uniscribe/ATSU/etc.
>
> If you want a cross-platform solution, pango has backends for
> Uniscribe and ATSU for those platforms, and interacts well with cairo.
>  Unfortunately, it has potential licensing issues.
>
Exactly and pango is not a solution for everybody. I disagree about cairo
not being in the font business. Excellent text layout facilites along with glyph
drawing go together. The argument agianst having a engine is more a
argument to just use pango but if pango is not a viable solution then
you the open source community has nothing more to offer. If you don't
want cairo to offer fonts then
we need a public api for plugging in the font engine and the current
font code should be stripped from from the api. Right now once you get
past the toy stage you just have a bunch of dead code.

If  cairo_scaled_font_t and  cairo_font_face_t where public structures
that allowed the user to provide a implementation then your assertion
that cairo is not in the font business would be true.


So I'd say if Cairo is not in the font business then get out
completley provide a plugin api and make the current code a sample
simple plugin.

If it is going to present a font api please drop the just use pango
argument come up with a api and if you wish use pango for the sample
implementation no problem.  As long as the public api did not expose
GObject then it fine to make it just a thin wrapper around pango.

I'd suggest taking both of the above approaches. If you have plugins
then people with simple rendering needs can use fast small simple font
engines and move to bigger ones if needed.

The current font api does not meet any of these needs. I'm not agianst
helping do the work if people were willing to work out the api. I even
started work already on
such a library and called it demontic as a companion library for cairo.
But the resistance to even trying to develop a cairo based companion
is pretty high. I've done a very deep review of the pango code base
and see no reason the gobject dependency cannot be removed the plugin
design can also be stripped letting cairo handle the core font engine.
 Whats left would have all the functionality of pango with less then a
third of the code. A lot of the reasons for the complexity of pango
and its use of GObject do not exist if your target is cairo.
I'm actually not agianst pango just pointing out that it was written
before cairo existed and now that we have cairo pango could be much
smaller and simpler and does not need the GObject dependency anymore.

At the moment most of my font handling code is cut and pasted from the
internals of cairo simply because of the lack of a way to get a glyph
index. And pango I might add is almost exactly the same internally. It
does the same thing I do and cairo does and I'm sure mozilla does if I
dug out the implementation.  I've attached the code from WebKit.
And if you find a bug even more reason to not force people to write
the same wrapper code over and over agian :)

Why force everyone to replication the same code over and over agian
just because you don't want to provide one public function ?

Now moving up the to multi fonts and multi unicode range support bidi etc
correct they exist and I'm not asking for cario to provide it. As I've
said I want to work towards this companion library called demontic
that handles all these problems and the implementation will probably
be a simplified strip of pango.
But just because this higher level library exists does not mean you
don't provide the lower level api and that the lower level glyph api
is not useful.

It would be nice to get the cairo community to at least discuss the
api for a companion font engine but hey I'm the one that needs it I'll
write it initally it
will simply be gobject stripped pango maybe at that point people will be willing
to reconsider.


>     - Vlad
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FontGdk.cpp
Type: text/x-c++src
Size: 2757 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060923/9164eee1/FontGdk-0001.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FontDataGdk.cpp
Type: text/x-c++src
Size: 4074 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060923/9164eee1/FontDataGdk-0001.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FontPlatformData.h
Type: text/x-chdr
Size: 2176 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060923/9164eee1/FontPlatformData-0001.h