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

[Keith Packard]

On Wed, 2006-01-18 at 23:07 -0500, Owen Taylor wrote:
> 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.

That was my argument; PS/PDF don't have intrinsic alpha in their output,
so why are we artificially adding them in cairo?

The answer can be as simple as "because we can", which is (of course)
weak. A stronger argument can be made that providing destination alpha
makes PS/PDF capable of more sophisticated operations along the lines of
X or GL. I note here that GL supports destination alpha but doesn't
support translucent surfaces either. Eliminating the ability to support
destination alpha reduces PS/PDF to a lessor surface type.

But, I think a legitimate question can be raised as to the possibility
of generating useful (non-bitmap) postscript output in the presense of a
destination alpha channel. If we don't believe it is possible to do so,
we should probably not pretend to offer this ability and force users
interested in generating giant bitmap images for every page to know what
they're about to do. I'm not that concerned about PostScript generation
performance, but I think we should be concerned about constantly
emitting enormous bitmap images.

Ok, so one counter to this position is that we have a proposed algorithm
that splits the page into two layers and uses bitmaps only where
necessary. Naïve code which needs destination alpha in only a few areas
of the page can be re-used without change and the output code will emit
a bitmap only for those areas, leaving the remaining portion of the page
in vector form. Without a surface that includes alpha, the application
would either have to just draw everything to a bitmap (something we're
trying to avoid) or would have to be recoded to identify pieces which
depend on dest alpha and draw those to a separate bitmap.

Why is this different for PS/PDF than Windows? It's different because an
application for X or GL doesn't have to face Windows limitations, while
these applications will have to face PS/PDF limitations as those are our
only print options supplied on any platform.    

I would like to see additional discussion on this topic; I still don't
see a 'killer argument' on either side.

-- 
keith.packard at intel.com
-------------- 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/3d55349b/attachment.pgp