PS/PDF API Change Proposal: (Re: [cairo] Semantics of
otaylor at redhat.com
Wed Jan 18 20:07:14 PST 2006
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
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060118/cc6bd58e/attachment-0001.pgp
More information about the cairo