Owen Taylor <[EMAIL PROTECTED]> writes: > On Fri, 2004-10-15 at 22:53 +0100, Roger Leigh wrote: >> Owen Taylor <[EMAIL PROTECTED]> 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. _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list