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

[Carl Worth]

On Thu, 27 Apr 2006 11:32:18 +0200, Emmanuel Pacaud wrote:
> > This ROADMAP still says April for 1.2.0 and I'm going to do my best to
> > actually meet that. I'm ready for a long weekend...
> 
> Are you still interested in a marking SVG backend as supported for cairo
> 1.2 ?

Is that, am I interested in seeing it happen or am I interested in
making it happen? ;-)

But, yes, I am interested in this---sorry for neglecting to reflect
that in the roadmap edits I made. But, again, if you're willing to put
the effort in here, (which you are obviously doing already), then feel
free to note as much in the ROADMAP file.

> Second solution needs a review of patches that touch other files than
> cairo-svg-surface.c. In my opinion, they're trivial, but still, they
> need a review.

I'll do this. They do look quite simple. Do you mind if I just
cherry-pick them to the master branch? Then you can just merge that
in, leaving your original versions in the history, or you could
rebuild your branch, (which would then just edit SVG-specific stuff),
on top of the new branch.

> And We also have to decide on the API for selecting SVG version. May
> be:

I'm not really a big fan of adding this to the create function for a
couple of reasons:

1) I'm afraid it will result in inconsistency.

	That is, we'll likely end up needing to do similar
	version-control stuff on PS and PDF. But we may release 1.2
	without anything like this in their create functions. Then if
	we add that later, we'll have to come up with another scheme
	and then the different backends will be implementing similar
	functionality in different ways.

2) It doesn't provide guidance/default options.

	The specific need for controlling the version is fairly
	narrow. That is, this is not relevant at all until the user
	starts using "uncommon" rendering operators.

	At the same time, it does require the user to look up and
	think about a value for the version parameter before ever
	using an SVG surface.

	That is, this makes the SVG surface harder to use, without any
	benefit for many common uses.

So I'd like to move this functionality to a function separate from
create. Maybe:

	void
	cairo_svg_surface_set_version (cairo_svg_version_t version);

Then we could put some requirements on the timing of that function. It
could perhaps be documented as "should be called immediately after the
surface is created" and more specifically "will result in an error if
called after any drawing has been performed to the surface".

I think we're going to be adding a bunch of functions with similar
timing requirements soon, (for the document meta-data for
example). And related requirements of "before any drawing has been
performed to the current page" for the page-specific size/layout
options.

> In either case, all failures in test suite are problems not related to
> SVG output, but due to the rendering via librsvg/cairo to png for
> comparison to reference images.

Excellent. Perhaps I need to update my librsvg---it looks like I'm
seeing more failures than you expect.

-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/3b180693/attachment.pgp