Slashdot Mirror
Making Linux Printing as Easy as in Windows
Jonny5 writes: "In preparation for the transition from windows to a Linux based workstation, the main focus is that of peripheral compatibility. Sure Linux is rock solid stable, and has an almost totally customizable GUI, but dammit, if my hardware won't work, what's the point? ...After hearing about TurboPrint, and their claim to provide 'Printer set-up and configuration is as simple as on Windows or MacOS,' I had to rise to the challenge. LinuxLookup.com has done a full review of TurboPrint For Linux."
I use KPrint (part of KDE infrastructure) with CUPS... I dont think I could ask for much more, though admittedly I think you still have to set the thing up via the CUPS web interface.
Still, it's better than using lpr/lpq and wondering what bit of the pipeline ate your document =)
Have you ever tried to set up a shared printer on a windows box attached to a LocalTalk network (Mac)? This is NOT easy :-(
Granted that is not the most popular case, but you've got to admit that MS didn't make that option too obvious. Those bastards. My HP 2000NT is still printing 2 pages of PS crap at the end of each printing session ONLY from the windows box (with latest drivers and 4 days watch in hand with MS/HP tech support.)
PPA -- the girl next door.
-- I feel better now. Thanks for asking.
What's wrong with this picture?
Printer set-up and configuration is as simple as on Windows or MacOS
TurboPrint for Linux comes as a tarball containing 'install' and 'uninstall' shell scripts, installation instructions, and all the binary software.
Yes, it's a command-line installer!
The default printing would be in black and white, and when I want to print in colour, I can just change the print command used by the program from 'lpr' to something like 'lpt -Ptp0'.
Yes, you have to give command line options to set printing modes every time you print with a different mode!
And yet this gets an 18 out of 20 in the review. It's amazing to me that this late in the game, there are still so many Linux-heads who just don't get it. This is not just inferior to Mac and Windows -- it's a giant quantum leap backward from where Mac has been for seventeen years and Windows for six. Real end users don't memorize command languages.
Tim
The next problem after printing is ironed out is the lack of a single, easy to use tool to add, temporarily disable, manage and remove fonts in any Linux setup, that makes one set of fonts (both ttf and Type 1) in a single directory available to all applications system wide, in the way that Adobe Type Manager does.
We then need CMYK capability in The Gimp. After these are in place, it will be possible to assemble a desktop publishing suite that will have mass appeal, because anyone will be able to design and publish to QuarkXpress/Photoshop/Illustrator quality, and print the results, all in a rock solid, free alternative to Windoze and OSX, without any pain.
ATH0 Bitcoin: 1DnwFLXczVZV8kLJbMYoheUrpqHesjxrSi
I used to maintain printer drivers for Windows and OS/2, and the implementation of the print subsystem on those operating systems is one of the very few areas where I've thought the design was more elegant than any UNIX solution I've seen. I suspect this is due to the modular nature of UNIX, which in this case turns out to be a weakness.
In a nutshell, the OS/2 and Windows kernels export an interface that you write functions to when you're writing a driver. This interface covers page rendering as well as printer set-up and configuration. That means anyone who wants to render a page need only call those functions and doesn't need to worry about what printer he's sending to. Integration of feature selection into your application program is also much simpler and takes advantage of the code written by the printer driver programmer.
The down side to all this of course, that since the GUI subsystems of OS/2 and Windows ran in kernel space, a poorly written printer driver can easily crash your entire system.
Only recently have efforts been made to address the rendering side of the problem with the Xprt extension to XF86 and the toolbox-level gnome-print library (I assume the KDE people have something similar as well.) While these efforts are good, a printer manufacturer is not likely to put the effort into supporting all of them. This means that we will continue to write our own rendering code to render into PostScript.
Ghostscript seems to have become the de-facto printer driver for Linux and the only real complaints I have about it are that it's much harder to integrate printer features into your program when Ghostscript is in use. I ended up trying to get around these problems by writing an incomplete PPD parser for the printers I was working with. This parser generated information files about the printer features and a lpr replacement program would present these features to the user. We did a pretty good job of making a GUI installer and front-end for printer feature selection, but it only supported our printers.
Technically it wouldn't be a very difficult problem to address these issues and make everything seamless for the programmer and the users. Politically it's rather more difficult though. This is one area where you're going to need a single standard if you want the printer manufacturers to write drivers for you. There needs to be one render interface, ideally at the X level so the toolkits can make use of it and one feature communication interface so that various programs can query for printer features. Queueing and spooling is already pretty well addressed.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
The real problem and reason why printing in Linux, esp. from the GUI, is a pain in the behind is that no distribution has a working system-wide font configuration mechanism where X and gs can painlessly access the same fonts (Recently I stated that Debian does, but it still has problems with font names with spaces in them, rendering it practically useless because many common truetype fonts have spaces in them) and the lack of a working printing toolkit. I don't know about libgnomeprint, but Qt/KDE's printing is horribly, horribly broken.
This leads to the dilemma that GUI application developers not only have to write routines to display their data on screen, but also ones to bring everything to Postscript. Web browsers are a prime example where the screen display is complex enough so that there's no more resources left to reinvent the wheel in Postscript, leading to Mozilla's broken printing.
The final problem is the lack of Unicode support in the ancient Postscript/Type 1 font standard. The introduction of the Euro made this painfully obvious for European Linux users.
Before we look at the hardware, we need a reliable printing library that surpasses Postscript's stone-age encoding, rendering out every single character. I believe libgnomeprint wants to do that, but I haven't been tracking it. We need a printing system that does not rely on printer drivers that are compiled into the PS rasterizer (lpr, ugh!) or has other quirks (cups is a step forward with its modularity and two behind with its own rasterizing program, effectively introducing a separate app for PS->screen and PS->printer). The hardware support is already here, but what use is a fast car if you can't get the door open? (Don't you just love metaphors?)
It doesn't really get much better if the "linux-heads" try to put a GUI front-end on things. Widget layouts are often poorly thought out and often covey contradictory or ambiguous choices for configuration. These sad attempts at usability are even praised more highly than the supposedly "easy" command line stuff. The real problem is that the linux hackers designing interfaces in the linux community get sugar-coated reviews of their stuff by other linux hackers who are far too eager to say something is usable out of their ignorance of user interface design and out of their belief that anything under GPL is inherently superior to anything proprietary, interface or otherwise. As a personal experience, I once talked to a person who created a linux installer for a very prominent linux distribution and I mentioned a few of the dozens of confusing or ambiguous or inconsistent things I found in its interface. He couldn't understand what the problem was: he thought I thought that it "wasn't pretty enough". And yet die-hard linux zealots who remember vi commands before they remember their wife's anniversary claim that this interface is perfectly easy and that this installer is perfectly ready for the desktop.
The few people with interface design knowledge who point out these problems are usually called "whiners", and are told to shut up and code their own improvements.
Putting it bluntly, the linux development community is doing more to kill linux on the desktop than Bill Gates ever could. Microsoft realizes this, and that's they have never considered linux on the desktop a threat.