10 Questions about Printing



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.

2. If there is a cross-platform way that "printing works" in
   terms of menu items, is that really what we want for 
   GNOME? 

   The GNOME integrated page setup dialog does have
   the advantage that the interaction between selected printer
   and selected page size is more obvious.

3. What extension points are needed for applications?

   Windows provides a reasonably extensive amount of print
   dialog customizability ... you can add pages to it,
   and you can provide custom variants of certain portions
   of the main page. What do apps really want to do?

   Many applications probably will end up writing their own
   Page Setup dialogs ... there is a lot more variety there
   than with the print dialog. What hooks do we need to 
   provide to let them do this well?

4. Can we use the native UI?

   Using the native UI means giving up a certain amount of 
   gtk-ness. You can't use the GtkDialog API for a dialog
   create with PrintDialogEx on Windows.

   Instead of widgets, we'd probably have to have objects
   of some sort with signals for completion, or have a 
   simplified blocking API that just shows a dialog and
   waits for completion.

5. Can we not use the native UI?

   If we write our own dialog, then we have to be able go
   beyond enumerating printers, show printer specific options,
   possibly with driver-provided UI, etc. It doesn't seem
   that either windows or OS X has a "API for writing print
   dialogs"

   I think trying to avoid the native UI is going to be a lot
   harder for the print dialog than for the file chooser.
   For the file chooser, we may be idiosynchratic, but there
   is a lot of variability anyways (on Windows). For the
   print dialog, we'll just be non-functional.

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.

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.

9. What options do we persist? How?

   Page setup options should be saved with a document. Also,
   perhaps remembered as "defaults" for the application.

   Selected printer probably should be remembered across 
   applications.

   How does the application get the information it needs? As a 
   chunk of XML? As key-value pairs?

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?

Of course, there aren't just 10 questions....


						Owen

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]