[cairo] Serious concerns about cairo

[Mike Emmel]

On 9/23/06, Carl Worth <cworth at cworth.org> wrote:
> On Sat, 23 Sep 2006 08:45:46 -0700, "Mike Emmel" wrote:
> > I'd like to add that I think the decision to have binary compatibility
> > was premature at best. A api freeze is even highly questionable.
>
> You do understand that our API/ABI guarantees do not prevent us from
> _adding_ anything we like to cairo?
>
> From a brief skim of your email:
>
> > Add one call to get the glyph index for a unicode char.
> ...
> > Add drawing operations at least for ucs2 chars. No one doing advanced text
> > layout works with utf8 you can't internally. There is no reason not to expose
> ...
> > Next there is no way to get the current clip path or see if a clip is set.
> > As with the path there is no function to reuse a complex clip path on
> > multiple cairo context's.
> ...
> > There is no way to get the surface back from a pattern that's a surface.
> > I can get the type but not the surface. Same with all the pattern types.
> > If its argb I can't get the color or gradient. This means I can't retrieve my
> > surface from a pattern for further drawing.  Nor is their a matching
> > create_similar
> > function for patterns.
>
> Everything you're talking about here sounds like additions, so the
> API/ABI stability guarantees won't present any problem in adding any
> of that.
>
I'm just saying that there is a lot more work to do and considering how much is
missing discarding some approaches to ensure API/ABI stability is not
a good idea at this point.

> And, significantly, some of it is already done. For instance, just
> this week Vladimir committed new API for several of the things you ask
> for in the last paragraph I quoted:
>
>       cairo_get_dash
>       cairo_get_dash_count
>       cairo_pattern_get_rgba
>       cairo_pattern_get_surface
>       cairo_pattern_get_color_stop_rgba
>       cairo_pattern_get_color_stop_count
>       cairo_pattern_get_linear_points
>       cairo_pattern_get_radial_circles
>
> And for querying the current clip, Robert O'Callahan has recently
> submitted an updated patch for that, (after going through several
> rounds on the mailing list). I think he's just waiting for me to
> review the latest version at this point.
>
> So, these things are already being addressed, (and I'll note that in
> both of the cases I just cited it's Mozilla that has been doing a lot
> of the work for fleshing out a few missing pieces of API).
>
Agian your just reinforcing my point so far the changes have not effected
the API/ABI but this is a lot of changes still going in how are we going to
know that its safe to freeze the API/ABI yet ?
I don't know I just feel with this much going in maybe we should relax
the concept of AP/ABI freezes.
And next why freeze it now whats the rush ?

Now as far as Mozilla goes I've looked at their SVG implementation
its far form complete and it sounds like they have already made a lot
of contributions. My orginial email suggested waiting till after they get
a reasonably complete implementation done before considering a api
freeze. Have they told you they are far enough along that they feel like
cairo will meet there needs ? I don't think they have done the
animation support yet for example.  I think I've actually got a more
complete implementation they
they do at the moment mainly of course because I could build on the
changes the y have already submitted.



> > I hope that other people implementing applications that seriously
> > exercise the cairo api
> > will speak up and voice there concerns if there is enough feedback
> > then I hope that
> > we can really review the state of cairo and consider addressing these
> > concerns before
> > considering the library robust enough for general use. If I'm the only
> > one not happy with
> > cairo then fine I'll except my position as a whiner but, I just think
> > people haven't voiced their experiences with the library.
>
> I agree that the more feedback we get the better the library will be.
>
> I don't agree that we've not been getting feedback---as mentioned
> above, the feedback from mozilla, (in the form of patches for desired
> functionality), has been particularly valuable.
>
But there not done with SVG as I mentioned earlier.
I'm not happy with my implementation its not optimum mainly because of missing
calls. The path copying is the biggest problem I ran into.


> 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.
>

I have a big post on this already suffice it to say the arguments a fallicous
the claim is that for a real font engine you need to support multiple
fonts and multiple charset etc i.e a pango api therefore nothing is
done.

In reality you can easily support ucs2 and glyphs and this api is needed.

I don't disagree that there is not a need for a companion library that provides
a more extensive api but that's not a good argument to not provide a
more complete basic api. Adding the ability to get a glyph index and
ucs2 char support will cover 99% of the text rendering needs. The
remaining 1% can be handled by a companion library. Refusing to solve
the most needs because you don't wan't to do the complete library does
not make a lot of sense. Even the multi glyph chars can probably be
handled with this api.

For the remaining 1 percent good bidi libraries already exist to
handle part of the problem.

What you don't want to do is do mixed fonts and mixed charsets and
mixed direction and I agree and I'm willing to help create a companion
library that handles these more extensive problems. But please lets
solve the common
problems and make cairo become a good library for providing the basis
for these more extensive libraries that handle the harder cases. Now
if we actually had a good api in cairo and it was used to implement
something like pango sure you may have to add additional support for
ucs4 and hinting but it would be a api for use by a higher level
library not one for application programmers but worry about this when
there is a need too. Finally I have to write this library anyway
starting sometime late this year or next year so I will be doing it It
would be nice if a
api was fleshed  a sample implementation could easily be done that was
a mix of a wrapper around pango and the needed additions to cairo that
I mentioned. Then I just have to do my gobject removal
and clean up of pango to remove the multiple backend support the
community has solved the rest of the problem for me :)

And I even have the name for it already demontic.


Read my other post for a longer more drawn out version of this argument.

> -Carl
>
>
>