Re: 10 Questions about Printing

[James Henstridge <james jamesh id au>]

Owen Taylor wrote:

>Some fodder for discussion this weekend:
>
>1. Is there a cross-platform printing user interface?
> 
>   Actually, what we are interested in is not the printing
>   user interface per-se, but the points of interaction between 
>   the application user interface and the printing user - 
>   what are the menu items? What are the places where the
>   application can extend the printing user interface?
>
>   In terms of menu-items, Windows typically has:
>
>    Page Setup
>    Print
>
>   And sometimes "Print Preview".
>
>   OS X has Page Setup and Print; Preview is a button on the
>   Print dialog.
>
>   GNOME has Page Setup integrated into Print, though many
>   (most?) apps also have a separate Page Setup which may 
>   or may not duplicate stuff from the print dialog.
>  
>
For many document based applications, the items available in the "page
setup" dialog are generally things associated with the document being
edited, and will be saved with the document.

Assuming you don't want to confuse settings saved in the document with
settings that are not saved (or settings that are global to the
application or session), a separate page setup dialog makes sense.

Now it might make sense to put the settings that are not stored in the
document in the print dialog.  However, since different document types
will store different settings, it would be necessary to be able to
control which settings are displayed there.




>6. How do we divide up the objects?
>
>   There are various "roles" that need to be filled:
>
>   - Information about the printer
>   - Information about the print job
>   - Document content
>
>7. Is printing callback based or simply procedural?
>
>   Do you a) provide a callback to draw a page b) just open a
>   document, draw_page/show_page/draw_page/show_page.
>
>   For a print preview, we need random access, but that could
>   conceivably be implemented with a metafile (as is done in
>   libgnomeprint currently.)
> 
>   We could even provide both - some sort of interface with
>   a signal-based implementation and a meta-file implementation.
>  
>
Assuming the print dialog lets people select page ranges, being able to
render arbitrary pages would be useful.  Of course page ranges can be
implemented by ignoring sections of the output, but it would be quicker
if the app could render individual pages on request.

>8. How do we represent printer information and options?
>
>   Some options
>
>    - Paper size
>    - Selected margins and orientation
>    - Color profiles
>
>   are needed by apps - and we can provide API for them. But do
>   we need some more generic API that allows applications to access
>   any conceivable option that might be set by a printer-specific
>   print-dialog page?
>
>   Does an app need to be able to access the fact that the user has
>   told the printer to turn on the built-in stapler? To find out
>   the phone number that the user has entered for the FAX driver?
>   Can we consider that stuff to be private and backend specific.
>  
>
In theory, an app would want to be able to control any print setting
that gets stored in the document.  However, I could imagine some
esoteric printing options specific to one particular driver that they
wouldn't be interested in.

On the other hand, I could imagine a use for the application wanting to
be able to control the phone number used for a fax driver: mail merge
via fax.

>10. What, if anything, do we need to do to support non-GUI printing?
>
>  There are some reasons people might want to print without a 
>  print dialog ... a web page that provides you PDFs of a generated
>  spreadsheet, say.
>
>  Is telling people to use Cairo good enough for that, or do we
>  need to make parts of our printing infrastructure available?
>
>  Would that imply "printing in GLib", or could we simply allow
>  people to use a printing API in GDK without initializing a display
>  connection?
>  
>
It depends on what sort of interface we provide.  Discovering what
printers are available and the settings available on those printers is
not particularly easy on Linux, so if we have a simple API, people might
want to use it for command line apps too.

James.