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

[Carl Worth]

On Thu, 19 Jan 2006 16:54:34 -0500, Owen Taylor wrote:
> The thing is, if the original code was used, say, in a GTK+ expose
> handler for a normal window, you'd get the exact same black hole.

What does "normal window" mean here? Is this a current limitation of
windows to having no alpha content or a long-term expectation?

> The way you draw a donut with a hole is
> 
>  You create a group
>  You draw the circle
>  You cut out the hole
>  You composite the group
> 
> (Using "group" as a shorthand for the moment.) That clearly has to
> work.

Yes. Obviously. And once we have that, we basically have to have
a COLOR_ALPHA "PostScript" (or meta-surface or whatever)
implementation inside cairo, even if not exposed. This is the point in
the thought process where Keith realized his plan of "PostScript ==
COLOR surface" wouldn't work.

> So, "CLEAR" seems like it should mean "don't draw any ink", while
> for a no-alpha pixmap, it's easier to accept that it is a 
> nonsense operation. But if that's the argument, then the only real
> solution is to make the COLOR_ALPHA behavior the normal behavior.

That was where I started, (as you can see in my original proposal
starting this thread). It's when Keith pointed out that this mode
would not provide for consistent output compared to drawing to a
no-alpha window that I decided that "PostScript == COLOR_ALPHA
surface" wouldn't work.

> You can't solve people's confusion by adding an option to do it
> in a non-confusing way :-)

No, the addition of cairo_content_t does not eliminate confusion. The
hope is that it provides a solution when the confusion arises. But I'm
still trying to figure out the best plan.

>    To a first approximation, all operations that actually require
>    destination alpha will require image fallbacks. So, having the
>    option there is a trap for users.

This does parallel perfectly with source alpha, does it not? Almost
all operations that require source alpha will require image
fallbacks. (We could optimize things like an initial 50% alpha
watermark by changing the colors based on the known empty background,
but that will be an exception, not a rule). Isn't that just as much of
a trap?

And if destination alpha is the way to get what the user wants, the
alternate approach would be a group, and also resulting in the same
image fallback. The only benefit would be a bit more obvious
expectation of the fallback, (if the user learns to associate groups
with image fallbacks).

>    If there were things you couldn't draw without using destination
>    alpha on the final surface, then we'd have a clear reason to
>    offer the option. But we know that Cairo is a complete 
>    drawing API without destination alpha for the final surface
>    because that's how it works for screen rendering...

I don't think the fact that it's possible to do things another way is
sufficient justification for not providing the feature.

Here's another way to phrase my concern:

	A user is looking at a window containing an image (our donut,
	say) with obvious transparent portions (perhaps rendered over
	a checkered background). Can you or the user predict what the
	user should get if he clicks the print button?

>  - Considering more advanced Postscript/PDF pre-press applications
>    where destination alpha has a real meaning:

That's not the motivation I'm arguing from, (nor do I know enough
about the requirements), so I agree it doesn't make sense to rely on
any such application for the current requirement.

> It may be that that this is actually the case in practice -
> the question really is whether there are any operators
> other than OVER which are actually interesting to use when drawing
> on an opaque surface.

I don't see "when drawing on an opaque surface" as a valid
qualification for the question of selecting operators.

A basic tenet of cairo is that it is designed to provide consistent
print output for everything.

> However, perhaps the user *should* change all of their rendering
> code? If the user is doing stuff where the mode makes a difference
> then they are going to be producing bad postscript / PDF output.

I'm imagining cases where the "user" that writes the rendering code
and the "user" that is doing the printing are separate and cannot
influence each other. In the current gtk-devel thread, Alexander
Larsson is proposing a cairo_t-based callback function as the
mechanism for printing. Alex doesn't get to choose what operators get
used by any random code.

And I don't want the authors of any random code to have to restrict
themselves by any special consideration for printing. My hope is that
cairo will magically provide perfect print output _in spite of the
fact_ that they didn't give printing any consideration.

(And PostScript with images in it isn't "bad". I definitely prefer it
if it gives the correct answer. At worst it's "big" and if the user
wants to recode to make print output smaller, then that's just fine. I
just never want a user to be forced to recode to get a matching
result.)

> > I would like our print output to support the entire cairo imaging
> > model.
> 
> Are you unhappy that drawing to the screen on a 16bpp display doesn't
> support the entire cairo image model? It's exactly parallel.

I don't think that's parallel. We agree that there are two different
kinds of surfaces in cairo:

	> We already have a clear distinction between the behavior of surfaces
	> with and without destination alpha.

But I don't see the "print" surfaces as just another surface. I feel
fine with demanding more from them since I want cairo to be able to
provide consistent print for any display surface.

> If you want to argue that printing inherently has an alpha channel -
> letting the paper show through - that's a stronger argument to me.
> 
> In fact, this may even be the model of PDF ... in the 1.4 spec

I've been careful to restrict myself to consideration of PostScript in
this discussion (since I have a better understanding of its
limitations).

> But then it becomes very unclear to me why we provide the choice of
> CAIRO_CONTENT_COLOR ... you've claimed above that we can make 
> CAIRO_CONTENT_COLOR_ALPHA as fast as CAIRO_CONTENT_COLOR in the cases
> where they produce the same output. Are there then cases where you
> *want* the different results of CAIRO_CONTENT_COLOR?

The only one I can think of is that the user has written code for a
CONTENT_COLOR display surface and wants to get consistent printing for
it.

I guess we'll probably need a cairo_surface_get_content in order for
various print systems to be able to create a matching print surface.

> we can do this for PDF by emitting the fallbacks as images with
> alpha channels (hopefully the viewers won't choke...)

Yeah. This will require support for PDF 1.4's SMask or so. We should
get that in poppler soon from what I'm told.

>                                                       but we can't
> really do that for PS. So you'd have to chose between:
> 
>  - Compositing against white. Works for normal cases

This is what I have now. Michael Sweet confirmed early in this thread
that this approach seems valid.

And we can generalize to compositing against a provided media color in
the future if that would help.

> (Since PDF probably is the desired transport medium going forward,
> having PS output be somewhat limited is not a huge deal.)

Yes.

> > PostScript also doesn't provide for source alpha either, but you
> > certainly would not recommend we abandon all of our image fallback
> > plans to emulate source alpha on PostScript, right?
> 
> I don't think that's parallel. We support source alpha on all devices.
> We don't support destination alpha on all devices.

But the objections with regard to efficiency, "bad" output, and the
complications of representing the implicit background in the
PostScript result all still apply in that case. I don't see any
fundamentally new issues that destination alpha raises that aren't
already raised by the existence of any image fallback output.

-Carl

PS. I'm still convinced we need support for both models. But the
support could still take various forms:

1) cairo_content_t passed to surface_create for all "print" surfaces

2) cairo_content_t assumed as COLOR_ALPHA by default for print surface
   and alternate constructor available for COLOR

3) cairo_content_t assumed as COLOR by default for print surface and
   alternate constructor available for COLOR_ALPHA

4) cairo_content_t assumed as COLOR_ALPHA for print surface and the
   user is expected to use a group to get COLOR semantics

5) cairo_content_t assumed as COLOR for print surface and the user is
   expected to use a group to get COLOR_ALPHA semantics
-------------- 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/20060119/dbb4cd6d/attachment-0001.pgp