Re: Printing in GTK+

[Roger Leigh <rleigh whinlatter ukfsn org>]

Owen Taylor <otaylor redhat com> writes:

> On Fri, 2004-10-15 at 22:53 +0100, Roger Leigh wrote:
>> Owen Taylor <otaylor redhat com> writes:
>> 
>> > There's some discussion of possible GTK+ future printing interfaces
>> > in my GUADEC paper:
>> >
>> > http://people.redhat.com/otaylor/guadec5/

I forgot to say thanks for writing that; I found it very interesting.

>> > I think a fairly simple printing interface does makes sense for
>> > GTK+, but it's been long blocked on not having a rendering API
>> > that's suitable for printing.
>> 
>> It looks like there's a nice clean separation between two pieces:
>> 
>> 1) A print dialog for selecting printers, paper sizes, printer
>>    features etc.
>> 
>> 2) A rendering API to produce PS, PDF, SVG etc.
>> 
>> Most programs will want (1), but only some will need (2).  Most of the
>> programs I've written don't have any use for rendering (making no use
>> of the Canvas): they either output plaintext or do their own
>> printer-specific control, or use groff or TeX as the rendering
>> mechanism.  They would still find (1) very useful, to select the
>> output destination, paper size, print quality etc.
>
> I think you are looking at a somewhat distorted sample of
> applications. :-). I think most application writers who want to print
> something would like to write code to draw what they want to print.
> Preferably using the same API as they are using to draw to the screen.

That's very true.  However, not all GTK+ applications will be using
the Canvas.

> Because it's been needed for libgnomeprint for things like ggv and 
> gpdf, it's likely that a GTK+ API would contain a "backdoor" for sending
> raw PS to the selected printer, but that can't be cross-platform, and it
> certainly wouldn't be the primary interface.

That's good to know.  There's no requirement for print schedulers such
as CUPS to accept /only/ PostScript.  You can also have "raw", PCL,
ESC/P or whatever you like as the input or output format, and convert
using filters as you like.  For many bespoke applications, PostScript
will not the output format of choice.  There are also a lot of
printers which are not capable of printing postscript (since they
aren't raster devices), or haven't got enough resolution to produce
legible output.

Some of the recent (paid) work I've done with GTK+ has involved output
to receipt printers for point of sale applications, where this sort of
thing would have been quite useful.  As it was, I just used normal
pipes.  And all the reporting used groff as a backend; a GTK+ frontend
is also planned.  For Gimp-Print, the libgimpprintui library provides
its own print dialog, providing full control over the printer, but
it's currently dependent upon libgimpprint and so would only be good
for client-side processing.  I talked with Jody about moving some of
the widgets into libgimpprintui if they would be useful (once the code
has been cleaned up--it's not currently modular enough).


I'd prefer the Print dialog to provide the programmer with a some sort
of structure detailing the printer name, capabilities and job options
(printer settings chosen by the user), and a means to get a GIOChannel
for sending output to from that structure, e.g.

GtkPrinterSettings *
gtk_print_dialog_get_printer_settings(GtkPrintDialog *dialog);

GIOChannel *
gtk_printer_settings_get_output_channel(GtkPrinterSettings *settings);

The PostScript rendering API could use the same GIOChannel to send the
print job--it would just be an extra layer that you have the choice of
using or not as you see fit (and the fact that there are two layers
could be hidden by the rendering API).

I'll take a closer look at libgnomeprint(ui) to see what you are
currently doing in this respect.  I've not had a close look for quite
a while, and I understand there's quite a lot of work been done since
then!

>> With regards to (1), I did have a chat with Jody Goldberg about this
>> in Bordeaux this summer.  One issue we have in the Gimp-Print project
>> is that the current mechanism of describing printer capabilities with
>> PPDs is no longer sufficient to describe a Gimp-Print driver, which
>> supports curves and value ranges which the PPD spec can't cope with.
>> This becomes a problem when you want to edit them in a portable
>> manner: currently only the GIMP Print UI is capable of this, leaving
>> CUPS and LPRng users unable to access the extended functionality on
>> offer.
>
> I  this all can be kept hidden from applications so that if a better
> replacement for PPD files starts being used, it can just be dropped in
> transparently.

This is *very* hard because both the spooler and UI need to use the
same mechanism for describing job options, and PPDs have become the
de-facto standard.  For the most part it's OK as long as the options
are simple lists of choices.  When you want to to anything more
complex, you are straight into non-portable hacks, and unfortunately
PPDs are the only portable cross-platform option at this time...

For things like the Print dialog, using libraries like libcups to talk
directly to the print server are very compelling.  Have you looked at
stuff like KPrinter (KDE) which does this in a modular way to support
multiple spoolers?


Regards,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.