[cairo] About cairo_show_text and UTF-8...

[Mike Emmel]

On 1/8/06, Behdad Esfahbod <behdad at cs.toronto.edu> wrote:
> On Sat, 7 Jan 2006, Mike Emmel wrote:
>
> > Cairo has the design that for each backend you provide a backend specific
> > implementation I did not mean that fontconfig would be the solution on win32/mac
> > just that for each platform or backend you may have a implementation
> > specific to that solution. Pango provides a pluggable abstraction
> > layer and is dependent on gobject mainly to support this abstraction
> > layer and to provide plugabble renderers. This can be removed if you
> > assume your working with a fixed implementation chosed at compile
> > time.
> > Internally in pango any particular implementation of the pango api is
> > not that large.
>
> Have you any proof that the pluggable architecture is making any
> problems whatsoever?  Is it just the glib dependency you are
> arguing here?
>
I did not say it was making problems just that by removing it
you could simplify the code. I don't see any reason to prove anything here.

And yes it allows you to remove the gobject dependency.
I don't want to drag GObject along every time I want advanced text layout.

Depending on GObject for Cairo was discussed in the past and rejected
the same reasons apply to a text layout engine for cairo.

Today Cairo  already has a lot of use cases where a GObject dependency
is problematic and advanced text layout is useful therefore why not a
simple cairo specific non gobject version of pango ?


Finally if GObject is not and issue then just use pango as is, or
better if this library existed it would be nice if it could also be a
pango module.


> > For cairo I'm saying it makes sense to extract these core
> > implementation remove the gobject dependency and expose them as
> > directly linkable libraries.
> > Its already in pango just do a
> > ls pangocairo*  Once you make the PangoCairoRenderer a simple C struct
> > and not replaceable then the gobject dependency is basically gone
> > win32 vs fontconfig is already handled I guess ATSUI is not at least
> > in the code I have.
>
> The ATSUI stuff is already in CVS.  Again, the question is:  do
> we want to duplicated/copy all the Pango functionality into
> cairo?  If we do, I'm sure we will get messages about ripping the
> text stuff because "my application doesn't use the text api and
> the implementation is god damn huge.."  I'm really with not
> extending the toy api at all.
>

No it would be  a companion library for Cairo. Once you had it done
I'm sure it would be possible to optionally support locales which
would remove the bidi engine from the build. Also it may make sense to
migrate rendering text using a fontset into the main cairo library I
don't know, I think this is what Carl is suggesting.
Maybe with analysis the library could be split some other way with
some going into
the main cairo api and some staying out as a companion library. Until
a intial version of  this library exists its hard to say.

Anyway it sounds like I need to go ahead and finish the work and just
present it.
I need it for my own projects anyway thats why I started on it in the
first place.
Also if some else either comes up with such a library are has
alternative proposal please share it. I liked starting with pango only
because it does provide a complete solution today.

Mike

>
> behdad
>
> > I worked on this already.
> >
> > Mike
> >
> >
> > > --behdad
> > > http://behdad.org/
> > >
> > > "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
> > >         -- Dan Bern, "New American Language"
> > >
> >
> >
>
> --behdad
> http://behdad.org/
>
> "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
>         -- Dan Bern, "New American Language"
>