[cairo] [API] unbreak CAIRO_FONT_TYPE_ATSUI

[Vladimir Vukicevic]

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