From: www.itworld.com

Hi-res printing with Gimp-Print

by Joe Barr

March 20, 2001 —

 


I admit it: now and then, I feel a twinge of platform envy. For example, I would have preferred to build a Linux box for my daughter and her family this past summer. But I had to use Windows 98 so they could run their favorite game (NASCAR 3) and its hardware accoutrements: steering wheel, gas, and brake pedals.



More recently, my girlfriend wanted to print some beautiful pictures she had taken with a Sony Digital Mavica camera. She asked if she could take some of the images to a friend's Windows machine to print them on a fancy Epson printer. A few days later, I saw a special at OfficeMax on an Epson Stylus Color 880. It boasted an amazing 2,880 by 720 dpi resolution, and only cost $149. The itch began to burn.



I had seen a blurb on LinuxWorld.com a week or two earlier about drivers for Epson printers, but I wasn't sure if GIMP supported that particular model. When I got home, I ran it down and found myself on the Gimp-Print project page. (See Resources.) Praise Baud, a driver for the Epson 880 was there! The next day, I returned to the store and bought an Epson.



LinuxWorld.com links

LinuxWorld.com home

Best of LinuxWorld.com

The Legacy Files

The Penguin Brief

Version Control

Linux links

Linux forums

I wish I could tell you that I had the Gimp-Print software installed in a flash and that was that. But it didn't go down that way. First, I downloaded one of the last betas for the 4.0 release of Gimp-Print. The Website also mentioned that, for common print duties, Gimp-Print could share its drivers with CUPS (Common Unix Print System) and ghostscript, the free software postscript alternative. I wanted those capabilities, so I needed the source code for CUPS and ghostscript. Compiling ghostscript requires having the jpeg, png, and zip compression libraries as well. So I hit freshmeat and downloaded the latest version of each needed item.



Then it was make city for a while. It was also touch and go. I needed to make a number of tweaks, and the readmes were full of warnings of other things that might go wrong. In time, they did. Just when I thought I had cleared the last barrier, I got gcc errors complaining about not finding something to compile a cpp file. That error only fit into the "screwy" category, so I decided to step back and take another approach.



First, I downloaded an even fresher copy of Gimp-Print -- release candidate 1 for version 4.0 (version 4.0 has since been released). I got everything else from the same place: CD number 2 of the Red Hat 6.2 distribution.



Building the two programs included with Gimp-Print was then as easy as the traditional ./configure, make, and make install routine. One of the programs, print, is a plug-in for GIMP. The other, escputil, is a utility for Epson Stylus Color printers that cleans and aligns the print heads.



One caveat: If you installed GIMP from binaries, you also need to install the gimp-devel package in order to use the Gimp-Print plug-in. That aside, if all I wanted was to print photo quality images from GIMP, I would have been set. But like any good dweeb, I wanted more.



The next step was to build ghostscript. This is where I had problems in my first attempt, so I proceeded slowly and carefully. But I think having a Linux-friendly makefile already included in the source RPM package was the difference between frustration and success. Be sure to read the readme file regarding "installation and compilation" in the Gimp-Print/Ghost directory. It contains some very specific instructions that could change how you do things, depending on which version of ghostscript you are modifying.



To begin, I copied the C source code and header files (the *.c and *.h files) from the Gimp-Print/Ghost directory to the directory containing the ghostscript source. Then I made sure makefile could find the libjpeg, libpng, and zlib directories, relative to the location of the ghostscript source. My ghostscript source files and makefile live in /usr/src/redhat/SOURCES/gs5.5. The three directories that contain the library source code live beneath that directory. The libjpeg sources, for example, are in /usr/src/redhat/SOURCES/gs5.5/jpeg.



Next, I modified the makefile and associated files exactly as detailed in Gimp-Print/Ghost README. For Ghostscript 5.5, the version I got with Red Hat 6.2, that meant appending the contents of contrib.mak.addon in the Gimp-Print/Ghost directory to the contrib.mak file in the gs5.5 directory. I used cat to do it; it was a snap. The format for concatenating two files into a third file is simply cat file1 file2 > file3. Then I backed up the original contrib.mak and replaced it with the new one.



I added $(DD)stp.dev to the line beginning DEVICE_DEVS6 in unix-gcc.mak in the gs5.5 directory and renamed it makefile. Then I ran make and make install in the ghostscript directory, and that was that.



It was time to build CUPS. Again using the SRPMS CD from Red Hat 6.2, I installed the source for version 1.1.4. Next came the familiar sequence of ./configure, make, and make install. With 1.1.4 in place, I returned to the CUPS directory in the Gimp-Print directory, and installed it in that same three-step fashion. By the time make install finished, all the Gimp-Print drivers had been made available to CUPS.



I used CUPS for the first time to configure my new printer. I opened an HTML file called documentation.html in the cups/doc directory, and clicked on the link for the Software Administrators Manual. Then in Section 3 of the manual, Printer Management, I walked through the steps to add my printer to CUPS. Piece of cake. I had to reconfigure my services run at startup so Apache would also run; otherwise, I couldn't have used the GUI admin interface.



Then came the big moment: printing a high-res photograph. I started GIMP and picked one of the many photographs we've taken over the past couple of months. The first one I printed took forever. I made a very newbie mistake by not scaling the output size, so the image completely filled the 8.5-by-11-inch paper size. It took more than a half-hour to complete. But even on stock inkjet paper, it looked pretty decent.



My next attempt scaled the output appropriately; the printed image occupied about a quarter of the page. I used one of the two free sheets of Epson photo quality paper that came with the printer; the resulting print was gorgeous. I had never seen print quality that fine on an inkjet printer.



I had a printing need that day that provided another test. I had downloaded all 70 pages of the curriculum for a Linux adult education class that I assist with, and needed to bring the curriculum to class that night. The downloaded file was in postscript format, so I just aimed it at the Epson from a command line by typing lpr curriculum.ps.



For a second or two, nothing happened. Then the printer made a few small whirring sounds, and page after page of crisp dark text began to emerge, some of it highlighted with a bright yellow, pink, or light blue background. It looked extra sharp.



How did they do it? How did the Gimp-Print project, only in existence for a little over a year, put such a great product together so quickly? I thought Epson might have provided the project team with drivers, programmers, or extra help. I asked Epson some of those very questions, but the company did not respond by deadline. I then asked Robert Krawitz, the Gimp-Print project lead, straight out: How did you do it?



Krawitz attributed some of the project's success to reverse-engineering the
output of the Epson drivers for Windows platforms -- not reverse-engineering
the driver itself, just its output -- and to developer documentation that Epson has made available on the Web. But he was quick to add, "That's only part of the answer. The real 'way we did it' was by gathering people around a solid nucleus. Nothing breeds success like success, and by putting something that produced much better quality output than any other free driver up on SourceForge, people who know stuff about color and dithering were attracted to work on it, and that further improved the quality -- a virtuous cycle."



Krawitz also said, "The publicly available Epson documentation is far superior to that from HP or Canon, the other two vendors whose printers we support. . . and the results show -- just knowing the basics has let us write really high-quality drivers for Epson printers, but our HP and Canon drivers lag."



How good are these free software drivers for Epson printers? Krawitz said, "An employee of one printing company later told me that one concern his company has is that third parties will write inferior printer drivers and devalue the product as a result. My response is that anyone who's concerned about that should go out and buy an Epson Stylus Photo 870 or 1270 (Epson's best printers) and compare output from Epson's drivers with ours. I don't want to claim that our output is 'perfect' -- we know we have some things we need to improve; our color model has a way to go -- but I'm willing to stack it up against anything else out there."



I'm convinced he's right on all counts. I also think there is a message in what he said about the wisdom of releasing information to open source developers. It's a message that Carly Fiorina, HP's "open source friendly" CEO needs to hear. Though she recently challenged other industry CEOs to get more involved with open source, Fiorina would do well to put some code where her mouth is, unless she wants HP to forever trail Epson in quality -- and popularity among free-software users.

Resources


LinuxWorld.com