otaylor at redhat.com
Thu Jan 12 06:57:37 PST 2006
On Wed, 2006-01-11 at 23:26 -0600, Mike Emmel wrote:
> On 1/11/06, Gustavo J. A. M. Carneiro <gjc at inescporto.pt> wrote:
> > Qua, 2006-01-11 às 08:41 -0800, Bill Spitzak escreveu:
> > > It seems that Cairo itself has successfully implemented a large thing
> > > (the cairo_t) without using GObject or any "base" library. I see no
> > > reason that the text layout cannot do the same thing.
> > >
> > > What exactly does GObject provide and why is it so hard to remove from
> > > Pango?
> > glib + gobject is about 850K + basic data structures. Most of this is
> > shared between multiple applications. To use pango you don't even have
> > to use the glib main loop.
> > Incorporating pango into cairo would mean two text layout
> > implementations -> bad for fixing bugs, bad for memory usage. You
> > probably can't make pango use the cairo text layout api without breaking
> > pango api. And pango api cannot be broken, period. And you don't
> > honestly expect all the apps using pango to start using a new API for no
> > good reason, do you? I mean, for cairo drawing you get lots of new
> > features relatively to the gdk/x11 drawing, but from pango to cairo text
> > you get nothing in return. Also, we'd need new language bindings (!)
> > Without gobject reference counting and enums/flags introspection, things
> > become much harder for dynamic languages.
> > This whole thread is a really bad idea. I am tired of linux
> > development platform always shifting APIs for mediocre reasons.
> > Stability counts much more than 850K of shared memory.
> Then I would be very surprised if pango fills the role of a companion
> text library for cairo. It will have to be something else since there
> is a real need for one that can handle some simple cases but also
> complex text layout problems if desired. Its a shame you feel this
> way I think there are a lot of good things about pango that would be
> useful outside of gtk but 850k of code is not needed to solve this
Commenting briefly on this thread:
- The chance that Pango will be rewritten not to depend on GLib
and GObject is remote; they are part of the Pango API, so you'd
have to write some sort of "Pano" and then wrap it with the
Sure, it would have been possible to do Pango C-only along
the lines of cairo or fontconfig, and I had some intention
of doing that originally... but I found myself constantly
reinventing the wheel and wanting this or that or the other from
GLib. It didn't feel justified at that point to add another
6 months to the project.
In addition, by using GObject, Pango language binds much better
and fits better into the GNOME stack.
- The idea has been floating around this thread that you could
some how hack off the low-level parts of Pango or maybe
the fontconfig-backend of Pango, make that part GLib
independent and share it between Cairo and Pango.
Splitting of the low-level parts of Pango: you might be
able to write a PangoLayout-compatible object that support
95% of the Pango API that people actually use; but I doubt
you could fully maintain API and ABI compatibility.
Plus, using Pango at the low-level is painful. I wouldn't
wish it on my enemies.
Splitting off the fontconfig backend of Pango: possible -
we wrap Uniscribe on Windows and ATSUI on OS X, we could
wrap some other library on fontconfig platforms. But
presumably the desire is a *cross-platform* text rendering
API to use with cairo.
- If you think the GLib dependency brings in too much weight, then
well, you should look at what a large fraction (half at least)
of the GLib binary size is: it's the Unicode tables I added
when writing Pango...
My guess is that a mini-GLib with only the parts of GLib
and GObject that Pango uses wouldn't be mini at all; while there
is stuff in GLib that Pango doesn't use (thread abstractions,
the main loop, for example) it's not the bulk of the library.
In the end, what I wanted to do with Pango was to create an
capable, easy-to-use, cross-platform text library that integrates
well with the GNOME stack, but can be used in other contexts.
We've achieved that with Pango; I think the vast majority of people
who need a companion text library for cairo would do well using
Pango. Maybe it's not the text library for everyone, but it's
better to fill some roles well, than all roles badly.
More information about the cairo