Breakout session for the Boston2005 conference
The GTK+ team is going to have a working session on fixing printing for GTK+ 2.10. To try to split up the workload, we're going to break into the following working groups. We'll have a better summit if we're able to do some research on these topics ahead of time. Each group has a lead (listed below). There are other parts of the print infrastructure that I'm assuming exists, and isn't really covered here. There's information on general requirements at ProjectRidley/GnomePrintDialog
How GTK+ talks to the printing infrastructure (JodyGoldberg)
Open Issues:
- Where in the stack does it go
- Getting a list of available printers
- Getting a list of standardized options from the printer drivers
- Getting feedback from the printers
- Feedback here is mostly things like printer status, number of queued jobs, etc. Feedback about the status of an individual job is not really necessary in the toolkit, since we have eggcups for that.
- Make sure that all communication with the printing infrastructure is async, since it may talk to remote printers or
- print servers, and we do not want the print dialog to hang due to that
Cairo's printing API (CarlWorth, KristianHogsberg)
Open Issues:
- Windows backend?
- PDF-specific features (links, page numbers?, title, subject, author, producer, creator, paper size, orientation)
- We likely need something like a cairo_document_t object to store some metadata together with the cairo context
How good can we make the PostScript output? (clever tricks to reduce the amount of image-fallbacks, for watermarks for example, etc.)
User test-case:
Discussion results (2005-10-08):
The API additions can be broken into three logically independent pieces:
- New API is needed to allow "printable" PDF (or similar document-oriented output). Perhaps not unlike:
typedef struct _cairo_document_properties cairo_document_properties_t;
cairo_public cairo_document_properties_t *
cairo_document_properties_create (void);
cairo_public void
cairo_document_properties_destroy (cairo_document_properties_t *properties);
cairo_public cairo_status_t
cairo_document_properties_status (cairo_document_properties_t *properties);
/* XXX: Need to double-check these names against the PDF reference */
cairo_public void
cairo_document_properties_set_title (cairo_document_properties_t *properties,
const char *title);
cairo_public void
cairo_document_properties_set_subject (cairo_document_properties_t *properties,
const char *subject);
cairo_public void
cairo_document_properties_set_author (cairo_document_properties_t *properties,
const char *author);
cairo_public void
cairo_document_properties_set_producer (cairo_document_properties_t *properties,
const char *producer);
/* XXX: Does cairo get to set creator as itself? */
/* XXX: Need to define an enum cairo_orientation_t here. PORTRAIT, LANDSCAPE, SEASCAPE? */
cairo_public void
cairo_document_properties_set_orientation (cairo_document_properties_t *properties,
cairo_orientation_t orientation);
cairo_public void
cairo_surface_set_document_properties (cairo_surface_t *surface,
cairo_document_properties_t *properties)
/* XXX: Need an enum cairo_paper_size_t here. Who has a "complete" list? */
cairo_public cairo_surface_t *
cairo_ps_surface_create_for_paper_size (const char *filename,
cairo_paper_size_t size);
cairo_public cairo_surface_t *
cairo_pdf_surface_create_for_paper_size (const char *filename,
cairo_paper_size_t size);- Notes on the above:
- Other surfaces can likely benefit from these sorts of properties, (such as by shoving RDF metadata into a PNG header)
Using the PDF reference for the set of property names is probably the wrong thing to do. A much more interesting set is the Dublin Core stuff (an ISO standard since 2003): http://dublincore.org/documents/2004/12/20/dces/
Or we could throw away most of the API above (except the new named-size create functions) and just have cairo_surface_set_metadata (cairo_surface_t *surface, const char *name, const char *value), but I would really rather have compile-time checking for this stuff.
- New API is needed to support structured PDF, (and this is just for PDF). Rough API concepts:
We can probably use the pwg's catagorization of paper sizes. http://www.pwg.org/standards.html#5101.1 It's not sufficient to just use names, we need to have a way to encode custom sizes.
/* XXX: Again, double-check this terminology against what's in the PDF reference. */
cairo_public void
cairo_pdf_surface_set_page_label (cairo_surface_t *surface,
const char *label);
/* XXX: Do we even want this? What other random page-specific junk might PDF want? */
/* XXX: Need an enum cairo_pdf_transition_t here */
cairo_public void
cairo_pdf_surface_set_page_transition (cairo_surface_t *surface,
cairo_pdf_transition_t transition);
/* XXX: Need something to support URL links? */
/* XXX: Need something to provide a table-of-contents within the PDF document.
Check the reference to see what it needs, and what the real terminology
is, but we might just have three function calls something like:
cairo_toc_create ()
cairo_toc_add_tag ()
cairo_pdf_surface_set_toc ()
*/- New API to allow PDF text to be selectable/searchable. We're guessing this means providing UTF-8 characters to backends even when using cairo_show_glyphs.
- Cairo's SVG backend needs something similar, so it probably makes sense to do something not pdf-backend-specific.
- One idea is to add a new pair of begin/end function calls that would bracket multiple calls to cairo_show_glyphs and might accepts a single location and a utf-8 string. Question: Could we assert that the bracketed text all belongs in a single line? Could we avoid that messy API and instead add a variant of cairo_show_glyphs that also accepts a string of utf-8 characters corresponding to the glyphs? Clearly more investigation is needed here.
Evince as print preview (JonathanBlandford)
Open Issues:
Does it even make sense? PaoloBorelli: PaoloMaggi: We don't think it makes much sense
. We'd prefer to avoid opening a new window (or a new application in this case) to display the print preview. We think preview should be a widget not a window. For example, in gedit we are experimenting with embedding the print preview in the tab instead of using a separate window (see screenshot 1 and screenshot 2). - Incremental rendering vs. pre-rendering
Existing Examples:
Windows backend (TorLillqvist)
Open Issues:
- ...
Gtk print dialog and API (OwenTaylor)
Open Issues:
- How do we use native GUI elements on different platforms?
- How do we keep all the messiness of selecting printers and printer options from the app?
Existing Examples:
Draft API:
API mockup proposal thing:
void my_app_that_prints () {
// Open problem: do we need a page setup dialog first?
// The following code has no page setup dialog
dialog = gtk_print_dialog_new ();
gtk_print_dialog_run ();
settings = gtk_print_dialog_get_printer_settings ();
// settings can be stored, read, etc
duplex = gtk_print_settings_get_duplex_mode (settings);
job = gtk_print_job_new (settings);
// what information belongs to the job vs the printer settings?
dpi = gtk_print_job_get_dpi (job);
margins = gtk_print_job_get_margins (job);
cr = gtk_print_job_create_cairo (job);
// draw first pagehere
// to go to the next page, do we need to go through the job or can we call
// cairo_show_page () directly ?
gtk_print_job_show_page (job);
// draw second page here
gtk_print_job_end_document (job);
}