Re: Gtk+ printing dialog highlevel thoughts

[Alexander Larsson <alexl redhat com>]

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?

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

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

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

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

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a gun-slinging umbrella-wielding master criminal gone bad. She's a 
violent punk widow in the wrong place at the wrong time. They fight crime!