[cairo] [API] unbreak CAIRO_FONT_TYPE_ATSUI
Vladimir Vukicevic
vladimir at pobox.com
Wed Mar 26 13:09:54 PDT 2008
On Mar 26, 2008, at 10:47 AM, Carl Worth wrote:
> On Mon, 24 Mar 2008 12:20:02 -0700, Vladimir Vukicevic wrote:
> Yeah, Behdad has pushed for that as well. And it definitely makes
> sense, (and it's too bad we didn't get this in place before 1.0).
>
>> and then some compat defines:
>>
>> #define CAIRO_SURFACE_TYPE_IMAGE (cairo_image_surface_get_type())
>
> I don't think we could pull off a change like that at this point, (see
> the snippet from cairomm's enums.h above, for example).
>
> So it may not be worth doing anything different right now.
I don't know -- we could hardcode #defines for the existing enum
values, and any apps that want to support newer surface types will
need to switch to the new API, which I think is fair.
> What might justify a new system would be support for dynamically
> loadable backends. We've had ideas for things like a "forking" surface
> that would target two backends simultaneously, (perhaps for debugging
> or other interesting uses). So that might be a very interesting thing
> to explore.
>
> A *long* time ago people asked about supporting dynamic backends, but
> I wasn't comfortable with freezing any of the backend
> interface. Specifically, I wanted to see high-quality PostScript/PDF
> output coming out of cairo before I would be comfortable freezing
> anything. We've got that now, so taking the "high-level" backend
> interface, (stroke, fill, mask, paint, show_glyphs), and providing it
> for use in dynamic backends might now make a lot of sense.
I have one issue still with the backend API -- I think we need to keep
the high level API in terms of floating-point values, and not go to
fixed point. So I'd hold off exposing it until we figured that out
internally.
> And if we do that, then we'll obviously need dynamic type identifiers
> as well. Using pointers to strings for the type identifiers is cute,
> but not feasibly compatible. So I think we'll just want something that
> can register numbers greater than the highest enum value, (those will
> then be locked in stone), and then a function that can map a numeric
> identifier to a string. That seems simple enough to me.
The strings were just a convenient static constant -- it's not
different than what we do already for hash keys for user data, no? We
could also just use the pointer of the backend struct as well for
identification, though using a separate ID lets us do things that I
mentioned above like (cairo_surface_type_t)(0) for the image surface
type. I'm pretty confident that we could do the change in a backwards-
compatible way.
- Vlad
More information about the cairo
mailing list