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."
How come these small things are always lacking in linux?
It is time we stop printing, let the forests survive. Tree's are good, lets more to a paperless system, unless of course you mean printing to a file. :)
UNIX apps don't send GDI commands - they usually send postscript commands.
So unless someone wants to write a postscript to GDI filter, that approach won't work.
Oh, and things that need to communicate directly with your hardware (like this printer driver) may not be able to run in wine anyway.
A Wine printer layer would work well if we got to use the Microsoft drivers - those drivers are simple and to the point. Getting a Wine layer to work with manfactureres priter drivers would be hard, as most manufacturer drivers include the kitchen sink: Flashy dialog boxes, ink level applets, news paper delivery (I kid you not, some HP driver pacakges install software to deliver a newspaper to your printer every day)
I'm not sure how it would work though, as I understand it, you would have to have a buffer for the unix driver to print to and have your Wine app send 'bands' of info to the MS Widnows print driver, as the MS Windows print model was designed to work well with inkjet printer, you cant just send commands ad hoc to the driver to anypary of a page, you must send a complete bands of information to the driver in order from top to bottom. It's kinda of a kludge. But then we know we could expect the 'finest' from Microsoft.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
I love it when people post without actually making sure that they read the article correctly.
You do not have to give command line options to set printing modes, the author just decided it would be easier for him to enable different modes as different printers. If you simply want to change printing modes, you can use a graphical method similar to that used by Windows or Mac OS.
It doesnt support any of the "free", usually giveaway, lexmark, etc printers.
/www.turboprint.de/printers.html</a>
<A href = "http://www.turboprint.de/printers.html">http:/
what is the point? that list is so short...and there are free printing infastructures for them already. so why would we pay $19 for this product!?
these are all fairly expensive hardware printers...not the kind most joe schmucks will have.
Even on Debian, it was pretty much point-and-click for me...fire up a web browser, point it at http://localhost:631, click on "Manage Printers", click "Add Printer," enter a superuser name and password, and follow the steps from then on.
It really is that simple, unless you've got a distro that has a weird installation of CUPS.
Heck, on Mandrake boxes, one can often have the printer autodetected, and the installer can often (in my experience) choose the correct driver.
Stating on Slashdot that I like cheese since 1997.
In my experience, Lexmark has wonderful Linux support for its products. $79 at Best Buy got me a very high quality 1200dpi inkjet printer (the Lexmark Z23) with both Windows and Linux support. The Linux side actually works better than its Windows counterpart, oddly enough. It runs as a daemon process, does PostScript exactly the way it should, and the fact that its a USB printer doesn't complicate the situation either. It all just plain works, out of the box. Even has a nice graphical config utility
Kudos to Lexmark for doing it right!
Bowie J. Poag
You obviously have not tried Windows 2000/XP etc.
The simple fact is almost every printer out there works with these OS's, out of the box. That is important.
Plug-n-play means you get a dialog box, and half the time the driver is already loaded with windows, otherwise you can use the supplied diskette.
Users are comfortable and familiar with this system, and it work 90% of the time nowadays. I havn't had a problem recently on a whole range of systems and printers.
Now, getting printing going under Linux is NO WHERE near that easy. Vendor supplied disks don't have drivers, and linux simply has a smaller driver base than windows overall.
That your rather silly post got modded up indicates that most people reading slashdot don't actually have to support computer installations or havn't actually used linux to print. The fact is for things like printers which require large driver bases, Windows with its monopoly power has linux beat.
So please, get a clue before posting.
I recently tired TurboPrint and was impressed. There is a free version that works surprisingly well. The thing I really liked was the quality of the printer drivers. Graphic print outs on my HP inkjet printer are dramtically better than the RedHat/Ghostscript drivers that I was using before. This is the real value added of the product. The configuration tool is nice, but is not the real value added of the product.
Also, make sure there are no spaces after the 'No's. The first time I tried configuring this, I had a space after the word and the braindead parser couldn't recognize the option because of it(not sure if they've fixed it in the newer versions or not)...so I swore for a couple hours before actually checking my syslog as to why the damned thing kept ignoring the option :)
The GUI should let you purge completed jobs, IMNSHO. For a basically single-user system, it's best to just disable those two options, unless you are into checking your /var/spool/cups directory on a regular basis (I have better things to do with my time)
" You obviously have not tried Windows 2000/XP etc. "
Or maybe he's just used NT/95/98 more. What is the Win2k/XP installed base? 10%?
"The simple fact is almost every printer out there works with these OS's, out of the box. That is important."
I've run into just as many printers that don't work right under Win2k as under Linux.
"Plug-n-play means you get a dialog box, and half the time the driver is already loaded with windows, otherwise you can use the supplied diskette. "
At which point you either use the drivers built into Windows and give up 2/3 of the printer's feature set or you use the drivers that came on the cd only to find that they are badly broken.
"linux simply has a smaller driver base than windows overall."
Not really, remember that a single driver on Linux may work with dozens of different printers. The actual number of printers supported is probably pretty similar.
"That your rather silly post got modded up indicates that most people reading slashdot don't actually have to support computer installations or havn't actually used linux to print."
Frankly I think you either arn't all that experienced yourself or your convienently forgetting about the times Win2k has failed to work right with a printer.
KDE does have an excellent printing framework, called kdeprint. Basically it is a layer sitting on top of whatever your print system is (CUPS, lpr and so on) and allows easy configuration, job viewing, print dialog and print preview in a unified manner. From the programmer prespective, a simple API (kdeprint+qprinter) is present for printing. From the user prespective, everything is easily controlled from the Control Center or customized on the fly through the KDE Print Dialog. Everything is very similar to Win, and just as easy. This thing exists since KDE 2.2, but now (KDE3 beta 1) it has matured. See also
printing.kde.org
You're both right. The current GDI model with the standard "Windows Driver Model" type drivers just passes standard GDI drawing commands, and the driver is responsible for dealing with them.
That said, there are many printer devices that aren't "WDM", including the weird large-format printers, plotters, and copy-shop stuff. For these, GDI has "backdoors" and other trickery that allows some drivers and apps to send data directly to the device, bypassing GDI's interpretation. An example might be dumping a huge raster image at 600DPI 24-bit color to a 36" paper-size plotter. For this sort of thing, GDI will run out of memory trying to interpret the whole thing, and you have to send things down in "bands", as zulux points out.
The bulk of printers that everyone uses these days are pretty much WDM compatible, so GDI generally works. For those devices that ain't, it's pretty nasty business.
Um, CUPS does not use "its own rasterizing program", it uses GNU Ghostscript with the "cups" driver which outputs a generic raster stream that can be configured as needed by the printer driver (i.e. the driver can say it needs a 6-color image at 720 DPI, and Ghostscript will generate it through the cups driver)
We include a version of Ghostscript with CUPS because 1) most non-Linux operating systems don't come with Ghostscript pre-installed, and 2) the standard Ghostscript is bug-filled and doesn't come with that all-important cups driver compiled in. See the ESP Ghostscript project on SourceForge for a more generic replacement that can be configured with the standard Ghostscript drivers + cups.
CUPS also provides an image file RIP which provides faster/better image printing than is possible with Ghostscript.
Similarly, the GNOME folks could provide a rasterizer for GNOME metafiles that would be used for printing - the metafiles are generally a more compact representation than PostScript, and would provide faster printing for clients in a network configuration.
In short, it is the very design of CUPS that will allow it to support a wide variety of devices and applications today and in the future.
I print, therefore I am.
I'm running RH 7.1, which has LPR with Printtool by default, but after many wasted hours trying to get it to print reasonably well with any of my three printers, I finally found a solution that works.
The solution? CUPS with XPP. This basically gets me all the functionality I need, with compatibility in most apps. All of my KDE apps use CUPS's LPR emulation to print. StarOffice, Mozilla, and other X apps use XPP, in which the program sends the postscript data to XPP and XPP lets me select a printer, printing options, and sends it to cupsd. If any console apps want to print, they just use CUPS's LPR emulation. Samba also integrates with CUPS, letting me share my printers.
Setting up my printers was also a piece of cake. Downloaded & extracted the CUPS printer definitions from the website. Went to my nice CUPS admin page (http://localhost:631/) and went through the setup under "Add Printer." No config files to mess with or anything...
The only thing I could wish for is for RedHat to use CUPS as the default printing system, as other distros like Mandrake have done. It was really a pain to rip out printtool and all the crap it leaves behind.
Michael F. Robbins