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

[Owen Taylor]

I can't really object too strongly to this change, since the the model
where a PS/PDF surface matches a CAIRO_CONTENT_COLOR surface is still
available.

But I'm really not very comfortable with the with the idea of a 
CAIRO_CONTENT_COLOR_ALPHA PS/PDF surface; I have concerns about 
efficiency, concerns about consistency with the rest of cairo,
and concerns about utility.

What is destination alpha good for?

 A) It's good if you want to end up with an object with 
    destination alpha. You want to draw a transparent
    clock that you'll combine with the rest of your 
    desktop. This doesn't really seem relevant to printing
    to me. In the end, you are going to end up with an 
    opaque piece of paper.

 B) It's good for slicing and dicing objects - cutting one
    object out of another, and so forth. This is basically
    always done in a group rather than on the final destination
    surface (Because, other than in A) above, we need to
    end up with an opaque surface in the end, so cutting
    something out of your destination is a bad idea...)

 C) Related to B) is using ADD to prevent seams. Again, in
    the normal screen case we are always doing this in
    a group, since you can't end up with a transparent 
    backdrop.

 D) Using SATURATE and front-to-back drawing to prevent seams
    is a somewhat different in the end result is an opaque
    image. Being able to recycle such drawing code and use it for
    a printer would be nice, certainly. 

    But the PS/PDF model is a painter's model. We need advanced
    code to try and detect when we can reverse the drawing order 
    and use OVER, and/or we are going to generate a gigantic 
    bitmap. The second is the much more probable case.

In the end, the reason why people want to use the PS/PDF model
is not to produce printouts of the Cairo test cases, but
to create and print documents; word processor documents, photos 
of their kids, and so forth.

We're going to have enough trouble producing good high-quality
output for the normal case where they do that by simply drawing
objects with OVER, that introducing a whole other code path
of questionable utility that probably will never be optimized
seems dubious to me.

And especially without such optimization, the extra parameter
to cairo_ps/pdf_surface_create() just becomes a FAQ trap. 
For normal uses, CAIRO_CONTENT_COLOR and CAIRO_CONTENT_COLOR_ALPHA
will give exactly the same result, but CAIRO_CONTENT_COLOR_ALPHA
will likely be considerably less efficient.

Plus, I'd argue that CAIRO_CONTENT_COLOR_ALPHA here really
doesn't mean the same thing here as it does in the rest of the
API. You say that you think we should be able to create Win32
surfaces with alpha... you certainly don't mean that you should
be able to create Win32 surfaces that magically composite
against white, do you?

The final result of drawing to a PS/PDF surface does *not* 
have alpha, no matter what your best intention. (Even you print
to overhead slides, the alpha there is just the color white,
and has no relation to the alpha of your surface.) What would
be the analogy elsewhere? If I create a ARGB surface for an
xRGB X window that doesn't have transparency, then areas I leave
with alpha < 1.0 come out black not white. for their printer or for
redistribution. 

As I said at the beginning, I don't object strenuously here,
but it is a parameter to confuse users, and a code path to
confuse implementers that in the end doesn't seem useful
to me, except for making our test cases look more orthogonal
and consistent. PS and PDF don't have transparency.

Regards,
						Owen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060118/cc6bd58e/attachment-0001.pgp