Re: Gtk+ printing dialog highlevel thoughts

[Michael Sweet <mike easysw com>]

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

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

Right.

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

    http://www.fltk.org/links.php

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