[cairo] semantics of cairo_copy()

[Carl Worth]

On Wed, 16 Feb 2005 13:13:18 -0800, Bill Spitzak wrote:
> while still taking advantage of Cairo's transforms. I'm not totally 
> convinced of the consistency problems of my idea,

Things like line_cap and line_join were specious in my argument,
(since they are transform independent so could be locked in at either
point with the same effect). But set_dash is transform dependent just
as set_line_width is.

>                                                   but it certainly does 
> not match PS or PDF (or possible SVG?) so that may make my idea unworkable.

I think this is the better argument for rejecting the idea. We already
have a PDF backend. We certainly expect people working to write code
handling PS, PDF, and SVG data with cairo, (we already have PDF and
SVG examples in hand). And we expect users of cairo code to be
familiar with those models. So significant deviation in a way that
could cause confusion should be avoided.

I'm actually curious to check the SVG specification on this issue, as
I can't say offhand if it is handled there the same was as PS/PDF.

> If set_skewed_transform() is difficult or expensive to call twice, but 
> you can save/restore the CTM, it can be done this way:

Thanks for demonstrating that even when the current model is not
ideal, the user can still recover from any performance loss incurred.

> PS: in general I am very happy with all your proposed API changes. In 
> all cases where you disagree with me you have come up with a *better* 
> solution!

That's excellent news to hear. We did spend many hours debating things
last week. It would have been nice to have been able to do that with
everyone on the list in attendance. But, since we couldn't, I'm glad
to see the results being well received.

> I think your idea is fine, but I'm not sure you understood mine. What I 
> meant is that any path-construction operator after a fill/stroke would 
> do an implicit new-path.

Ahah! I hadn't understood that. While it would allow short-term
benefits, (in not having to modify some programs in some ways), I
think the behavior is too magic and would cause more confusion in the
long-term.

The "_preserve" proposal has the advantage of making the preserve-path
vs. discard-path alternatives much more explicit. Hopefully, this will
be less confusing than even the PostScript model, (where fill/stroke
discard the path but clip preserves it).

-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/20050223/566f7200/attachment.pgp