On the Desktop
Linux in the news
All in one big page
See also: last week's On the Desktop page.
Linux Printing with CUPS. Printing on Unix systems has always been a bit of a black art. The history of Unix printing carries with it various implementations of print spoolers, i.e. systems which queue files submitted for printing so the printer software can handle them in some managed order. Users run command line tools like lpr (BSD) or lp (System V) to spool a request that will be processed later by the printer daemon (lpd for Linux and BSD-style systems, lpsched for System V-based Unix systems). This whole system works well for the command line world but is not very desktop friendly and leaves a lot to be desired when it comes to adding drivers for the latest inkjet printers.
Currently, the majority of Linux distributions rely on lpr-based solutions for printing. An updated version of lpr, called LPRng, has replaced the older, less secure versions. But while security and some network connectivity has improved users are still working with command line interfaces to their printing system.
CUPS supports PPD (Postscript Printer Description) files, making it easier to identify printer features for both local and remote printers. These PPD files normally accompany the Windows drivers that come with printer hardware but can also be found on Adobe's web site. User authentication is provided so that printer use can be limited to known users and print jobs can be encrypted (using TLS or SSL3). Finally, IPP-based systems permit the sender to use printers for which formatting and document handling issues may not be known. According to the CUPS web site, all major Linux distributions, including Caldera, Debian, Linux-Mandrake, Red Hat, SuSE and Turbolinux, ship with the CUPS software.
But while CUPS itself provides more support for printer hardware, it still relies on System V (lp) and BSD-style (lpr) command line interfaces for user access. Fortunately, it also provides programmed interfaces which GNOME, KDE and general applications can use. There are a number of graphical tools available for configuring and using it.
CUPS has been developed by Easy Software Products, a company founded by Mike Sweet, the man who wrote the original print plug-in for the GIMP. That project, too, has seen a major overhaul and become a printing subsystem of its own. The quality of the prints produced by this system can be outstanding, at least for the Epson drivers that have been tested by LWN.net, even without CUPS interaction. While the previously mentioned tools provide configuration options for adding printers to the system, the Gimp-Print tool offers job specific handling on a very sophisticated scale. It can also handle feeding print jobs directly to a wide range of printers, bypassing printer drivers that may be outdated on your system.
One of the problems with handling printing under Linux is that there are two very distinct configurations that need to be handled: one for system wide printer descriptions and one for print job specifics at the user level. Who should handle developing tools for both? Is configuring a printer to make it available an OS thing, or is it a desktop thing?
That, of course, depends on who you talk to. According to the XST project leader Chema Celorio, GNOME thinks all printer configuration is a desktop issue. Current plans call for GNOME print functionality to be configured using the Ximian Setup Tools (aka XST) while print job specifics (items like page orientation and paper size) will be application specific using the gnome-print-admin tool (aka Print Dialog). As Chema puts it,
The reason we are working on two different solutions (the XST tool and gnome-print-admin) is that the XST tool fixes system wide configuration and gnome-print-admin will take care of printing with GNOME applications, so we can interact with the user when he is about to print. The XST tool will fix printing with non-gnome applications like Netscape or Mozilla for example.
So users will add printers using XST and configure them for specific print jobs using the print dialog (in whatever form that eventually takes). The only problem is that this is currently just vaporware - the admin tool code is in the unstable branch and hasn't seen a public release yet and the XST package has yet to add the system wide printer configuration features.
At this point KDE appears to be handling things the same way, though their web site would make it appear the the 2.0 architecture doesn't do much in this area. Fortunately, this isn't true. In February, Michael Goffioul proposed a new printing architecture that will address the issue from many angles, including support for CUPS and the standard lpd subsystems. Much of the work Michael has done has been integrated into QtCUPS and KUPS for KDE. The 2.2 release of KDE should see more of this work in end user form.
The graphical interface is heavily based on my previous work QtCUPS/KUPS. It mainly consists of a powerful print dialog (like QtCUPS) which is now used by default by all KDE applications, and of a control module for print management (like KUPS). Everything is now included in KDE-2.2alpha, so if you have time, you might want to give it a try (you only need kdelibs and kdebase).
In the end, what this all boils down to is that printing is still a black art. Instead of one system - even if it were one for GNOME and one for KDE - you have what seems like dozens of distribution specific tools to configure variations on the originally BSD lpr system or the newer (and more complete) CUPS system. Finding the right tool still requires tracking it down and installing it manually and, worse, the higher level environments have not completely integrated printing into their office and desktop environments.
For the time being, at least, you'll need to keep your local Linux guru handy if you want to upgrade your printer configurations.
Printing Resources. The best place to start when exploring how to get printers to work with your particular system is the Printing Howto. This comprehensive document not only explains the details of how printing works on Linux systems from a users perspective, but what configuration tools are available for the various major Linux distributions.
LinuxPrinting.org contains an easy to use database of printers that shows whether the printer is supported or not, and if it is with what drivers. Most drivers are designed to work with Ghostscript, but some come directly from vendors such as HP.
Where not to go? Linux Printing Usage HowTo, which hasn't been updated in 3 years. While a moderately accurate technical document, it simply doesn't provide information relevant to the current GNOME, KDE, and CUPS-based environments.
Finally, IBM's OMNI project is another good resource. This project is working with GNOME (and others) to develop drivers for printers from many vendors, including Canon, Epson, Okidata, and Panasonic among others.
CD Distributions. A discussion has been on going on the KDE Promo mailing list regarding the selection of a Linux distribution to include with a distribution of the latest KDE. The original message says the question arose from a Dutch computer magazine. Since then, numerous responses have pointed out the issues related to associating KDE with any distribution. The consensus seems to be to either pick the distribution that is behind the curve on KDE releases (SuSE and Debian are noted here) or to pick the distribution that is most used (Red Hat, Mandrake or SuSE).
More corrections and clarifications. I've been informed that Opera does support anti-aliased fonts on Linux, when linked against a version of Qt which supports them. According to the mail I received, that would be Qt 2.3 or greater. Make sure you run the statically linked version of Opera for this. The dynamically linked version apparently runs against Qt 2.2.4, so you definitely want the statically linked version to try this. (Thanks to Camilla Karlsson)
An even clearer explanation comes from well known KDE developer Kurt Granroth: "You see, you are technically right when you say that it is the Xft library providing the anti-aliasing. However, for KDE's point of view, it's not Xft but Qt that is doing it. That is, since Qt has support for anti-aliasing (using Xft), KDE has it. " Essentially, since Qt is supplying anti-aliasing support for KDE, it can provide it for any application. And that explains why you can also get anti-aliasing in Opera.
Ximian Setup Tools 0.5.1. A new version of the apparent successor to Linuxconf, the Ximian Setup Tools (also known as XST), has been released. This version adds support for Debian Woody, Red Hat Linux 7.1 and SuSE 7.0, along with an uncountable set of bug fixes.
Kernel Cousin KDE #11. This week's Kernel Cousin KDE covers discussion on a KDE Games network, the future of Noatun, and Visio support issues in Kivio.
GDM 2.2.2 released. An update to gdm, the graphical front end to GNOME has been released. This is a fairly major update which includes better support for Xinerama, better language support and a clock in the login window.
Gesture Recognition for KDE (KDE Dot News). A project is underway to provide gesture recognition for KDE. The screen shots show that the gestures are to be mapped to commands, so a clockwise box drawn with the mouse over a window could be used, for example, to kill the application.
GnuCash 1.5.97 is released.. GNOME's money management tool, GnuCash, has been updated this past week. This release is considered an unstable developer's release, so use with caution.
The abisource web site changed IP's at the time this announcement went out which caused some problems with visitors access to the documents. The changes should have propagated by now, however. If you still can't reach it, try the new IP address directly (184.108.40.206): 43, 44, and 45
Gnomermind 1.0 stable released. Gnomermind, a Mastermind-styled game for GNOME environments, has reached a 1.0 stable release. The game is highly configurable, as the screenshot section of the web site shows.
KPovModeler. KPovModeler is a KDE-based interactive modeler for the POV-Ray raytracing engine. This is a very new project, so new the source is only available via CVS (a sort of nerd library, for those who have never used CVS). Screenshots look interesting for such an early release, though.
And in other news...
A GUI situation indeed (ZDNet). The Linux desktop isn't dead just yet, even if Eazel is according to Evan Leibovitch in his Linux Opinion column. "Nautilus was never deemed to be a critical component of any Linux GUI. For users of the GNOME desktop, Nautilus is but the prettiest among a number of available file managers, with aspirations of becoming the preferred default. Meanwhile, in the world of KDE, Eazel has always been a non-issue. KDE's Konqueror component combines file manager and Internet browser in a manner similar to Internet Explorer, and it is sufficiently attractive and functional that Nautilus was never coveted by the KDE crowd."
HP exec: Linux will be desktop champ (ZDNet). HP's Bruce Perens says that the Linux Desktop is further along at this point than other environments when they were 4 years old. "Dismissing Linux for the desktop is shortsighted, says Perens. "Consider the age of the Linux desktop. Development started from zero sometime in 1997. It's almost maturation time for that desktop, and four years is a lot less time than it has taken any other desktop project to get to the level that Gnome or KDE are at."
Desktop Usability?. A pointer to the Summary of Comments For GNOME User Testing (Winter 2001) popped up on the KDE Artists mailing list this past week. It's an interesting read, though it's not clear where, when or how the tests were done. What it does show is that users look for familiarity in the desktop. This means, like it or not, the interface has to look very similar to Windows or perhaps a Mac initially. Providing configurable changes to the UI is paramount, but you have to start with something the non-technical user understands, lest they run away in fear or worse, frustration.
Setting up a diskless kiosk using GNOME. Jamie Zawinski wrote an article explaining how to use GNOME in a diskless kiosk based on a project he did for a lounge he runs. "A friend talked me into spending a bit more money on the kiosks to get something more reliable: diskless desktop computers for the kiosks, plus external flatscreens. I've been experimenting with the ThinkNIC diskless computer (200MHz and 64M RAM for around $200) plus KDS Radius 15-inch LCD screens (1024x768 for around $580.) The benefits here are that: the machine itself can be serviced; and if the machine gets toasted, I don't have to buy a new screen too. The screens can be secured such that they are fairly indestructible, and they also have a warranty."
The Dot. We noted that the KDE news site, known affectionately as The Dot, has been difficult to reach this past week. Discussions on various mailing lists suggest that server may be overloaded or have other problems and options are being explored to remedy the situation.
A Common Linux U.I. for You and I (osOpinion). This article from osOpinion examines the aging discussion about GNOME and KDE trying to be too much like Windows. "Take a look at KDE and GNOME. While both have a pile of applications available, KDE applications won't work perfectly with GNOME, and vice versa. In effect, what we are heading towards is two "bundled" application suites."
Where Is the New Linux Experience? (osOpinion). The struggle for desktop acceptance for Linux may be taking the wrong path, according to this article from osOpinion. "Gnome and KDE both are taking the wrong path. They are trying to build too much into the desktop. In doing so, these UIs are getting slower, and are bringing bloatware to Linux for all the wrong reasons."
Section Editor: Michael J. Hammel
May 31, 2001