[cairo] Stroke and Fill

[Carl Worth]

On Thu, 2 Sep 2004 08:09:08 -0400, Jose O Gonzalez wrote:
> 	* It is indeed inefficient, from a user's point of view,
> to have to go through intermediate surfaces for this, so it would
> be good if Cairo provided a more direct method.

Noted. I do plan to try to come up with a good way to make this easier
on the users. And there was some discussion of some of the interface
options a year or more ago on this list.

> 	* A 'group' type of approach would be far more natural,
> and general.

Yes, that's the idea.

> 	In fact, it seems to me that with any such set of
> intermediate steps, it's going to be very difficult to do this
> (in the generality I'm describing here, ie. with independent stroke
> and fill alphas and/or independent stroke and fill compositing ops),
> unless at some point one somehow manages to 'subtract' the stroke
> region from the fill region.

Fortunately, you can do exactly that. Owen Talyor already wrote one
example in cairo-demo/X11/caior-knockout.c that uses an intermediate
surface and "subtracts" a group of three circles from another. The key
is to use other compositing operators than the default
CAIRO_OPERATOR_OVER. Owen achieves the subtraction with
CAIRO_OPERATOR_OUT_REVERSE.

As you can see, these operators provide much more general manipulations
than just subtracting a stroke from a fill.

The original Porter/Duff paper details the semantics of all of the
operators.

Keith has posted a copy of that paper here:

	http://keithp.com/~keithp/porterduff/

> 	This leads me to suggest that the simplest way of obtaining
> this (which I speculated on at the end of my original letter), is
> for Cairo to restrict a fill operation to not overlap the stroke
> region that is implicitly defined by a non-zero setting of the
> stroke-width value (of the context used when the fill operation
> was called) -- wether or not any stroking of that width is/was
> actually called to be done.

The problem is that the stroke-width could be arbitrarily large,
resulting in a zero-size fill, even if the user wasn't ever planning on
doing anything with that stroke width. Having to carefully set
stroke_width to 0 before every fill just to avoid obscure bugs doesn't
sound like a nice interface to me.

-Carl