[cairo] Updated ROADMAP for cairo 1.2.0 (and beyond)

[Carl Worth]

On Thu, 27 Apr 2006 10:14:02 -0700, Ralph Giles wrote:
> So an application would be expected to #ifdef all the version stuff 
> based on a declared cairo api version define, or stuff it discovered
> itself in the configure script?
> 
> I would think some kind of property interface that can report failure
> would be cleaner, though there is some conceptual advantage to not
> having cairo_surface_set_property() return ETOOLATE. :-)

I was arguing from the point-of-view of an application that requires a
particular feature in order to function.

Now, if what you want is to actually negotiate with cairo and live
within what it can provide, then yeah, things are different. For
example, maybe you want to provide a "save as" dialog that provides
all the different SVG/PDF variants that the current cairo library can
support.

Then, back to the enum approach, we could do this by providing a query
function that gives the largest supported enum value, as well as a
function mapping the enums to symbolic strings.

> I would also like to comment as far as requirements that while a numeric 
> version works fro SVG and Postscript, for PDF there are non-numerical 
> compatibility profiles people will eventually be interested in 
> supporting, like PDF/A and the various PDF/X. (There's even a PDF/is 
> which is entirely image fallbacks!) An enum would do fine here,
> though.

Good point. By and large, these subsets fork off of a particular
version of PDF, right? That is we don't get a 2D matrix here of PDF
version and PDF variant, (though, yes, I realize there are multiple
variants of PDF/X too).

-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.freedesktop.org/archives/cairo/attachments/20060427/57a85357/attachment.pgp