My dad has two printers, not especially cheap ones, and he wants to print things on them. Should this be hard? CUPS is configured, which was pretty easy, and works great. But:

Mozilla (he uses both Firefox and Thunderbird) does Xprint-based printing on *nix. Nevermind that using the X protocol for printing is twisted and wrong. The problem from a user’s perspective is that printing is completely unconfigurable in Xprint, and in fact it didn’t work for him: one of his printers consistently covered only a roughly 4”x6” area and started printing before the paper had fed in completely. I’ve had him set it to print PostScript to ‘kprinter’, which means he has to click through two print dialogs, but it bypasses Xprint so at least he gets correct results and can configure the printer. We can hope that the Cairo version of Mozilla will provide partial relief from this problem, but Mozilla will still need a usable printer configuration dialog box.

The GIMP has its own printing interface that also doesn’t let you adjust any printer-specific settings. Since my dad wants to do serious digital photography work, I’ll probably have to have him bounce PostScript through kprinter from the GIMP too. OpenOffice has yet another nearly unconfigurable printing interface, as does AbiWord and I suppose most every other app on a free desktop. Each of these programs can be configured separately to direct printing through kprinter, and I suppose that’s what I’ll have to do.

In fact, as far as I know, only KDE provides a decent printing UI with full support for CUPS and all printer-specific options. I’m no fan of KDE, any more than anything else, but they’re the only folks who got this one right. (kprinter, of course, is a stand-alone application that just pops up the standard KDE print dialog.)

I think what I want is for someone to apply the Model-View-Controller pattern to printing dialogs. Which GUI toolkit is in use (Qt, Gtk+, Motif, Windows, whatever) should be swappable while leaving a core set of printer configuration functionality alone. The CUPS API looks pretty good for the model layer, but I wouldn’t mind wrapping it in something if it meant this hypothetical “libprintui” library would get used by everything.

I think I want something similar for documents, too, so that the many various office suites can have their different UIs while still supporting all the same file formats and functionality.