[cairo] Cairo and GdiPlus or two win32 backends

[Owen Taylor]

On Mon, 2005-02-07 at 01:35 +0100, Hans Breuer wrote:

> > I don't actually know what you mean by logical operators. If you
> > mean the blending operators of cairo_set_operator(), then they are
> > only "logical operators" when you have bi-level alpha. 
> > 
> If you look at the difference of Cairo/win32 and say Cairo/png for
> operator IN, ATOP, ATOP_REVERSE, ... you'll notice it. There
> are operators which are purely a combination of pixels and others
> which also need to take the clip region of previously drawn stuff
> into account. [ You probably can copy the clipping stuff from my
> wmf based backend ;-]

The difference here is whether there is destination alpha or not.
If there is no destination alpha (or if you fill the PNG surface
with a solid color to begin with, since the PNG backend is buggy for 
CAIRO_FORMAT_ARGB24), you'll see results that match what the win32
backend produce.

cairo_snippets is a little confusing here because the PNG version
uses destination alpha, the other versions don't. The win32 version
matches the X version quite exactly except for stroked text. 
(Which just takes some straightforward implementatoin in 
cairo_win32_font.c)

I guess there is an argument that printing is always really 
transparent background since it is ink vs. no-ink. To support
that, you need:

 - Printer driver support for AlphaBlend()
 - Either:
    - Knowledge in the printer driver of what color paper is being
      printed on and handling of for out-of-gamut colors.(Lighter than
      the paper, say)
    or
    - White ink

Given that, the proposed cairo_meta_surface system should work fine with
minor modifications. 

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/20050206/e57933b9/attachment.pgp