PS/PDF API Change Proposal: (Re: [cairo] Semantics of transparent objects)

[Carl Worth]

On Thu, 19 Jan 2006 18:54:04 -0800, Keith Packard wrote:
> Of these options, I prefer 1) if only because it places the information
> about what's going on right in front of the developer when they're just
> starting to think about printing;

And my goal of course is to not force the developer to have to think
about anything special here when they just start to think about
printing.

>                                   providing a 'default' with an
> alternative function will mean that many people will only learn about
> the default, assuming that the 'advanced' function is not something they
> need.

I'd buy that as an argument for not making COLOR the default. But
rather than 'advanced' I'd say that the COLOR_ALPHA provides a
'complete' set of functionality while COLOR will only be needed for
deliberately 'restricted' functionality.

>       In fact, which variant is required depends solely on what kind of
> surface the original code was written for. In most cases, it will be a
> COLOR surface (most X surfaces, all Windows surfaces), and so a COLOR
> printer surface will produce matching output. In some cases, it will be
> a COLOR_ALPHA surface (ARGB X surfaces, PNG files), where COLOR_ALPHA
> will produce matching output.

I think there's one subtle point missing here which does give
justification for making COLOR_ALPHA the default.

As we've mentioned, in "common" usage there won't be a difference in
the two modes. The difference shows up only when the user starts using
the more elaborate operators (DEST_OUT say). And when would a user
actually use the operators? My claim is that they are only useful when
destination alpha is available, so they will "only" appear in code
that is expecting destination alpha.

Without destination alpha, I'm pretty sure the effects of the more
elaborate operators devolve into things that are easier to achieve
without them. So it's quite unlikely that users targeting a COLOR-only
display surface will have trouble printing.

We can't prevent the user from using the elaborate operators for the
less interesting results, but in that case, I think we have two easy
answers to provide:

	1) "Don't do that"---go draw things a simpler way.
or:
	2) Leave the rendering code alone and just throw a
	   cairo_surface_create_similar (CAIRO_CONTENT_COLOR) around
	   your printing to make it all just work.

-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/20060120/34e71812/attachment.pgp