Re: Gtk+ printing dialog highlevel thoughts

Alexander Larsson wrote:
(cc:ing some people who I think might be interested in this)
I've just started looking at doing a printing dialog for Gtk+
2.10. For some background thoughts from owen, see:

FWIW, both Windows and MacOS X provide APIs for accessing the list of
available printers, etc., and the CUPS API is also available on
MacOS X.  WRT Linux printing, CUPS is pretty much ubiquitous, and
failing that you can standardize on PAPI (the SourceForge library
apparently supports CUPS, LPR, and Solaris lp - check with Norm
Jacobs for details...)

I've started studying various platform APIs and UIs, cups, PPDs, etc,
preparing for this. To compare various platform and application
printing dialogs I have put together a set of screenshots from
Linux/OSX/Windows at:

Thanks for the extensive set of screenshots!

* Printing photos
  This is (these days) a pretty common task, but substantially
  different from what the traditional print dialogs are made to
  support. We could make this a standard type of dialog simplifying
  such printing. See the e.g. the "easy" print dialog in OSX in
  the screenshots above.

This type of printing functionality is also useful for a lot more
than just image printing.  Also, it would be really nice to allow
any app to print N-up as well as poster printing (scaling and
printing on multiple pages...)

* Using the Gtk+ dialog as a native print dialog
  For instance, OOo could use the Gtk+ print dialog for its printing
  UI on Linux/Unix, but then not use the Gtk+ print system (cairo) to
  print, instead going directly to the lowlevel printing system and
  use its own postscript generation.

Yes, there are a bunch of applications that want to do this, however
in most cases you'll be better off sticking with the standard print
path as generating good PS/PDF output is not trivial.  I'd argue that
the more we can do to improve the low-level print/file generation
APIs (i.e. Cairo or whatever), the more likely it will be that apps
will not need to bypass the standard paths.

Look at what Apple has done with Quartz and the Print Manager APIs -
by the sounds of things, Adobe will (finally) be moving away from
using the old Carbon print APIs, and their apps use just about every
trick in the book when printing...

* Printing without a UI
  Its very useful for applications to be able to print without opening
  a dialog. For instance by passing "--print <file>" on the command
  line. In this case it would be nice if the Gtk+ printing system
  supported a headless mode that didn't need a connection to the
  Display, but still allowed one to use the same printing code.

This is where a good low-level print API comes in handy...

One important question that owen brough up is the "Can we/can we not
use the native UI?". If we go with native dialogs we loose a certain
amount of customizability, we get a bit more non-standard APIs
(i.e. we're unable to use GtkDialog derived objects), and we're a bit
limited in what the dialogs can do (least-common denominator of
features, although we might be able to do better with some work).

For Windows, at least, you'll need to use the native interface to
select printer driver options/properties.  This is because Microsoft,
in their infinite wisdom, chose to make all printer driver options
part of private "device mode" data structures which are passed
around, and the only way to initialize these data structures is to
run printer driver code on the system...

My opinion is that we should go with native dialogs. Printing dialogs
are already confusing enough that having to learn a totally new one is
a pain, and its probably gonna be very hard to make a print dialog
that works right on Windows, because I don't think all the required
APIs are availible. Furthermore, you'd loose driver-specific additions
to the printer dialogs that are availible in Windows/OSX.

It makes sense to use the OS-supplied print dialogs when they are
available and provide sufficient functionality, however there *is*
no standard dialog on Linux (at least not yet :) so there is still
the issue of coming up with a toolkit-neutral interface that can be
used by all...

I've been talking to the Tor on Win32 and Andersca on OSX, and both
think it should be possible (but not tested yet) to embedd gtk+
widgets into a native dialog, so if we're lucky we can allow some
generic way of adding custom widgets to the dialog. (Given the APIs on
OSX and Win32 this will likely be in the form of an extra tab page.)
> ...

Right, we've looked at doing something similar with FLTK as well...
The same techniques for embedding windows in browsers, etc. will
work with the print dialogs.

Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software

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