Re: Gtk+ printing dialog highlevel thoughts

Alexander Larsson wrote:
On Wed, 2006-01-18 at 19:39 -0500, Michael Sweet wrote:
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 think relying on CUPS might be good enough. Opinions on this? Does
e.g. solaris ship CUPS?

It is provided on the Solaris companion CD, but not installed by

* 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...)

With a callback-driven printing "mainloop" i think this is pretty easy
to do. The mainloop would just set the CTM and clip rect before calling
the page rendering callbacks (multiple callbacks per physical page for
N-up, and call the same callback for multiple physical pages for poster


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...

I think this is an fine long term goal. However we have to recognise the
fact that there are currently apps (like OOo) that won't do this and we
have to support these apps anyway.

Right, you'll always have a "back door" for submitting custom output,
just make sure that app developers don't need to do it... :)

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...

Since this is the discussion of the gtk+ print dialog addition I think
its fair to say that the linux/unix-specific dialog will be written in
Gtk+. A toolkit-neutral dialog seems very hard to make from a technical
standpoint, and its gonna have integration issues with all toolkits.

Not specifically the dialog itself (although it would be nice to
offer either a standalone command a la kdeprint/gtklp or a simple
C API to hook into it), but definitely a standard low-level API to
hook into the print system (CUPS, PAPI, whatever) so that all
toolkits can get their printer info from the same place...

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.

Did you get any results from this? I.E. do you have some working code.

I think there are several implementations on the links page:

I'll see if I can come up with some specific links...

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]