[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:
> > 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.
>
> Sure, and the toy API is labelled as a toy precisely because of that;
> you can't use it to "grow into" a real text layout system.  Like I
> said, I didn't like seeing the toy API included to begin with, because
> it makes people feel like there's something more powerful there, and
> they get frustrated when they realize that there isn't.
>

#!@#!!  was what I actually said :)

> I agree that pango is not a solution for everybody; perhaps someone
> should write something, but whatever that "something" is, it can be
> done on top of cairo, instead of inside it.  We (Mozilla) use
> Uniscribe, pango, or ATSU for text layout, and we draw glyphs with
> cairo_show_glyphs().  Nothing stops you from doing something similar,
> or wrapping it with a cross-platform wrapper and contributing it.
> Pango's license is unfortunate, because pango already does much of
> this, but we can't fix that.

Its LGPL same as cario is this a problem for you? I'm on WebKit actually
so I have the monster icu library from ibm that makes pango look small.
I want to move to something else but not pango so....

Can you explain a little more what concerns you have with the license.
Note I could also start with the mozilla code and make it clean C++.
But I would prefer a C api at this level.



>
> > 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.
>
> How so?  cairo_scaled_font_t and cairo_font_face_t store information
> about the current platform-specific font, and the implementation knows
> how to render glyphs from those fonts to a cairo surface.  A
> particular surface (or font impl) can fast-path show_glyphs -- e.g. my
> Quartz backend knows that if the font is an ATSU font, it can pull out
> the bits it needs and call CGContextShowGlyphs or similar directly.
> If there's something related to glyph rendering that's not working,
> then it's a bug that should be fixed.
>
> Cairo is in the glyph rendering business; it's not in the text layout
> business.  Text layout is a very complex problem that's already been
> solved by other tools; it sounds like you're already on your way to
> creating a version of pango that suits your needs.  You may want to
> take a look at PangoLite, which I think might be what you need, though
> I haven't looked at it in too much detail.
>
Pango-lite never heard of it but googled and it looks like it is yet another gem
buried in the mozilla code base.  Thanks.
I'm not using pango right now as I mentioned I'm using icu but I did a
lot of work
looking at doing a pango-lite that removed gobject and all the backend support.
I'll dig deeper into your pango-lite library thanks for the tip.

Mozilla is rendering all the pages through pango on linux and
performance and memory usage is not a problem ?

Or it sounds like your actually doing your own glyph layouts and using
cairo from your other statements.

In any case tell me more about what you would want as I've said I've
got no choice but to write this pango/icu replacement library so I'm
actually begging for the community to consider working out the api
they would like.
And I planned to start from a existing code base.
1.) Unify the WebKit code and bring in the guts of pango to replace ICU
2.) Dig through mozilla and de-xpcom the code
3.) Look at what QT does ..
I don't' plan on starting from scratch and I'd actually prefer the
library be in C thus the lean towards pango but I'm very open if
someone is interested and has suggestion on a implementation approach.
No way I can start from scratch.
Also I planned to move as much of the data into XML formats for the
various languages.

I think that both webkit on linux and mozilla would benefit from
having a toolkit independent text library and I've got no choice but
provide one.





>    - Vlad
>