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

[Carl Worth]

On Wed, 18 Jan 2006 10:41:59 -0500, Michael Sweet wrote:
> > 
> > Do printers handle documents like this? Do they prompt the user to
> > load paper of a different size or automatically pull from different
> > trays depending on the per-page size?
> 
> Yes! :)

Excellent. I'm glad to see that we've got some people active on the
list who know printing and can provide some authoritative
answers. That gives me some hope that we can forestall my ignorance
dooming cairo to failure.

> In short, the PS/PDF API should support changing the page size on a
> per-page basis, but I would also provide guidance WRT printing of
> landscape pages - the app should rotate the CTM rather than choosing
> a landscape page size to avoid unnecessary size changes.

OK. Good to know.

> Also, without knowing the details of the current Cairo APIs or
> architecture (I've read enough to know we want to use it, but haven't
> started coding with it), it might make sense to have the notion of
> a PS/PDF "job" or "document" context, and then create surfaces that
> are associated with that context which actually adds pages to it.

Kristian proposed something earlier in the past.

I'm not too keen to the idea because it seems to put a larger
disconnect between operations to display graphics vs. operations to
print graphics. (And I've always tried to minimize the number of
objects users must juggle just to get started---I was convinced that
having cairo_surface_t and cairo_t separate makes sense, but each
additional object will be a harder sell for me.)

Right now, the primary API separation we have between display and
print is cairo_show_page. I'm wondering if we can't take advantage of
that state transition for doing the things we need to do.

Obviously, there _are_ a lot of printing-specific options, settings,
and metadata that users will need to provide. And the point has been
made above that these need to be available on a per-page basis.

I'm wondering if we can't just use cairo_t for these, and specify that
the time to set them is before any drawing operation on any given
page. That is, just after cairo_create or cairo_show_page, and before
any of cairo_stroke, cairo_fill, cairo_paint, cairo_mask,
cairo_show_text/glyphs on that page.

A few of us (and likely a group missing some printing experts) started
talking about what this new options-setting API would look like at the
GNOME summit. The strawman we came up with is here, and might make a
good starting point for further discussion:

	http://live.gnome.org/GtkTeamPrintingBreakout
	(See the "Cairo's printing API" section)

It's clearly not complete, but the question is whether this is a
workable-basis for extending to something complete.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060118/b295c4be/attachment-0001.pgp