[cairo] [API] unbreak CAIRO_FONT_TYPE_ATSUI

[Carl Worth]

On Mon, 24 Mar 2008 12:20:02 -0700, Vladimir Vukicevic wrote:
> On Mar 23, 2008, at 12:29 PM, Benjamin Otte wrote:
> > I was pretty sure that making the old symbol work again properly was
> > the correct thing to do. In fact, I was guided by
> > CAIRO_FORMAT_RGB16_565, another deprecated enum value.
> > If it was not correct, feel free to revert it.
>
> I'm ok with this change, but I would prefer to get rid of the ATSUI
> name entirely in case someone expects it to actually use ATSUI in the
> future.  The behaviour won't change though, so maybe it's ok to just
> #define it.  But up to carl and behdad; we should come up with some
> kind of policy for those enums, since I bet this will come up again in
> the future.

Benjamin's fix is correct.

Basically, the cairo 1.5.14 snapshot breaks the build of any
application that uses the cairomm bindings since that binding has a
header file like so:

	typedef enum
	{
	    FONT_TYPE_TOY = CAIRO_FONT_TYPE_TOY,
	    FONT_TYPE_FT = CAIRO_FONT_TYPE_FT,
	    FONT_TYPE_WIN32 = CAIRO_FONT_TYPE_WIN32,
	    FONT_TYPE_ATSUI = CAIRO_FONT_TYPE_ATSUI
	} FontType;

So I'll likely push out cairo 1.5.16 today to address this.

As for encouraging people to migrate away from the old name, we could
provide a pre-processor directive that would hide the old names. That
would allow authors of cairo-using code to ensure that their code
isn't using any deprecated names. I think GTK+ has something like this
for example, so we could mimic its name for the macro, for example.

> It would be nice to get rid of the enums from cairo.h entirely to
> avoid this problem; I thought about this a little while ago, but never
> wrote up a suggestion.  Here's one thing that could be done:

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.

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.

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.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080326/ec4c857d/attachment.pgp