Re: Gtk+ printing dialog highlevel thoughts

[Michael Sweet <mike easysw com>]

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: 
> http://mail.gnome.org/archives/gtk-devel-list/2005-October/msg00024.html

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: 
> http://people.redhat.com/alexl/print_dialogs/

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        http://www.easysw.com