[Desktop_architects] Printing Summit 2006

[Carl Worth]

On Fri, 09 Dec 2005 08:54:47 +1300, Robert O'Callahan wrote:
> > Carl Worth wrote:
> > > 
> > > Yeah, I think all that's missing is someone knowledgeable to hook up
> > > what's needed within cairo here.
> 
> We need to do this for Firefox, which will be all-cairo in a year, and
> the Win32 printing story is one of our three biggest cairo worries. (The
> other ones are the Mac backend and general performance.)

Printing support (in general) and performance are the two biggest
things on the cairo roadmap right now. So there's definitely a good
fit there as far as that goes.

I still don't know what to say about the Mac/Quartz backend. I'm
honestly still just waiting for a maintainer to materialize to carry
that forward.

>                                                          It's not simply
> a matter of hooking the existing Win32 backend up to a print DC, because
> Windows print DCs don't support all the operations screen DCs do (e.g.,
> alphablend). We probably need some sort of meta-surface analysis like
> Postscript is going to have.

Yeah, that's what I meant by "hooking up". I really think that the PS
and PDF backends will have the hardest issues solved before the win32
printing stuff happens.

Quite recently, the cairo_meta_surface_t stuff has gotten good enough
that it can pass the entire test suite. This means that we now have
structure in place to get basically any backend that can take an image
to print "perfectly" in terms of output quality.

So then the question becomes how to produce "perfect" output as
efficiently as possible, (using native operations as much as possible,
falling back to images as little as possible, and being careful not to
introduce seams for objects that might cross the boundary between
native and image-fallback).

So, there are two parts there:

1) Analyzing the meta-surface and grouping objects according
   to fallback vs. non-fallback regions with seam avoidance.

   This is the "hard" part that will be tackled first in terms of
   PS/PDF and should be completely sharable for win32 printing.

2) Running through the new win32 printing backend and implenting
   whatever pieces can be done natively.

   This part should be really easy in comparison. Hopefully we'll have
   someone for whom the win32 printing capabilities are well-known.
   We have a test suite to guide the process. And the process can be
   entirely incremental; at first everything is done with image
   fallbacks and the capability can be improved from there, but at
   any point along the way the backend should be able to correctly
   print anything that cairo can throw at it. 

> Then it's not clear whether this support should be dropped into the
> existing Win32 backend or it would make more sense to fork off a new
> Win32 printing backend. Anyway, we'll have to solve it one way or
> another.

I don't think that's too much of a concern to me. The only really
significant question there is whether a new surface_create function is
needed, and that will be obvious to someone who knows. Currently we
have:

	cairo_surface_t *
	cairo_win32_surface_create (HDC hdc);

If a win32 printing context needs to be created via some other object
type, then we'll create a new function, otherwise we're done. As for
what happens underneath, whether there are two separate function
tables for win32-display and win32-print is an implementation detail
that can be changed at any time.

-Carl

 LocalWords:  DC DCs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/desktop_architects/attachments/20051208/e1f9f6a8/attachment-0001.pgp