Gutenprint (formerly called Gimp-Print) is a package of high quality printer drivers for Mac OS X, Darwin, Linux, BSD, Solaris, and other UNIX-alike operating systems. At present, Gutenprint supports over 1500 inkjet, dye sublimation, and laser printers. It is the most comprehensive free source printer driver package available.
Gutenprint strives to offer full functionality and the highest possible quality on the printers we support (within the constraints of our available resources), and many people claim that Gutenprint offers better quality than the proprietary drivers supplied by the printer vendors themselves. We have done extensive work on screening algorithms, color generation, and printer feature utilization.
Additionally, Gutenprint provides excellent drivers for many printers that are otherwise unsupported on Mac OS X.
Why and how did you get started?
I’ve been a serious amateur photographer for about 15 years. In the summer of 1999, I was looking for alternatives for printing my photographs. High quality commercial prints (C-prints for negatives or Ciba/Ilfochromes for slides) were very expensive — a 16×24 C-print at a good lab cost $75 — and I thought that scanning my source material and printing it on a good inkjet printer would make the hobby more affordable.
I bought a used Epson Stylus Photo EX from a friend at work and was dismayed to find no Linux driver available for it. Rather than mope around, or switch to Windows, I decided that I wanted to write a driver for it. The best starting point I could find was Michael Sweet’s print plugin for GIMP. The code was reasonably easy to follow (more so than what was in Ghostscript), and printing directly from GIMP was in line with my goals. It was a fairly long process making the printer generate all 6 colors, but eventually I got it working.
I’m professionally a software engineer and project lead, and it wasn’t long before I started doing releases of my code and attracting considerable interest. I started the SourceForge project late in 1999; it was the only free software hosting service around at the time, and if I wanted more people to be able to access it, I needed somewhere to host the project. The full history of the project is in the User’s Manual.
Who is the software’s intended audience?
Anyone who needs to print to non-PostScript printers: home users, businesses, photographers, artists. It’s part of the basic printing infrastructure on just about any Linux system, and it’s also distributed with Macintosh OS X and OpenSolaris.
What are a couple of notable examples of how people are using your software?
As a part of the basic open printing infrastructure, it’s mostly one of those things that “just works” and isn’t really visible to end users. However, the core is a library with a well-defined API, and there are other projects built around it. A couple of notable ones are PhotoPrint (a free software application for printing photos, with color management and many layout options) and QuadToneRIP (a proprietary application using the Gutenprint core in a GPL-compliant manner). People have been experimenting with Gutenprint in novel ways. Some people are using inkjets to deposit custom “inks” (actually chemical reagents) on specialized media, and need precise control over where the drops are placed. Others are experimenting with color management, in some cases effectively replacing our color transforms and taking advantage of our DeviceN input (accepting the raw ink values for each ink actually used by the printer). These are things that OEM drivers typically don’t provide access to.
What are the system requirements for your software, and what do people need to know about getting it set up and running?
Just about any modern Linux/UNIX system can run Gutenprint. It can be used with CUPS, or with other print spooling systems with Foomatic.
It uses the standard autoconf system for configuration, and the standard make/make install for building and installation. If you need to upgrade to a newer version of Gutenprint, we provide a utility for CUPS users to easily complete the upgrade.
What gave you an indication that your project was becoming successful?
I put the Gimp-Print development tree on SourceForge starting with version 3.0, around late 1999, and quickly found a group of like-minded people who wanted to print high quality output on inexpensive inkjet printers. One of the main goals, which was not expected to be met until late in the 3.1 cycle, was to write a Ghostscript driver so that printing would not be restricted to the GIMP. Much to my surprise, someone wrote one within days! That gave me my first clue that the project was destined for bigger things.
The rest of 2000 was a whirlwind of activity; the project was attracting a lot of attention from the Linux community, since it was the first attempt to generate photographic-quality output from high quality inkjet printers yet was supporting a wide range of printers. Being invited to the Linux Printing Summit in July 2000 was another indication of success.
What has been your biggest surprise?
If I look back to the early days, just how successful the project became almost overnight. I like to think that I’m a good engineer and project manager, so I’ve been able to keep pace with things, but it’s never something I expected to happen.
What has been your biggest challenge?
It’s hard to say; we’ve had technical challenges around color management, management challenges in terms of maintaining people’s long-term interest in a project that’s not an end-user application, and “customer support” challenges in terms of the very large number of end users with very high expectations for flawless operation. I think overall we’ve been fortunate in that we’ve kept the project going for over a decade despite vast changes in the free source world.
Why do you think your project has been so well received?
On the whole, I believe we’ve executed and communicated well. We’ve managed (except for a few years when we were stabilizing 5.0) to deliver support for new printers on a more or less regular basis, and we’ve avoided major regressions along the way. We’ve certainly had our share of bugs, but our release strategy has been fairly conservative and we’ve generally avoided delivering broken releases. Basically, Gutenprint is an infrastructure project, and the most important thing for infrastructure is to not break anything else, so we try to ensure that things that aren’t broken don’t change between releases.
I also believe we’ve delivered good value to users. For the printers we support, Gutenprint for the most part just works, and it works basically the same way for all printers supported by Gutenprint. Particularly for Epson inkjet printers, quality is high. We’ve also put considerable effort into ensuring that the upgrade process is simple and non-disruptive: upgrades within a release series should cause no change to function or output except for what we define.
We’ve also avoided the temptation of expanding into areas that aren’t really within the purview of the project. There have been suggestions that we should work on a bigger part of the printing chain, or more support for multi-function devices, or our own user interface. This would have been a distraction, in my opinion, and would have inhibited us from delivering the best printer drivers we could.
Finally, we’ve had sound architecture. While that isn’t directly visible to end users, it has made the project a lot easier to maintain and enhance over time, which is.
What advice would you give to a project that’s just starting out?
Once you get past the prototype stage — say, when you have something that’s useful to you and other like-minded people who don’t mind living on the bleeding edge — start thinking about planning and execution.
Planning and execution are loaded words to some people; they conjure up images of Gantt charts, presentations, weekly status reports, management reviews, and other trappings of corporatia. All I really mean is to think about where you’re going with your project, set yourself some concrete goals, and think about how you’re going to deliver a good quality release that can be used by other people sharing your interest but who aren’t as technically savvy as you. Plans will change over time; one of our biggest early plans (color management) hasn’t really gone anywhere just yet. But you need to keep focus on what you’re doing, and having things written down can help you keep track of what you’re doing.
As far as releases go, there’s nothing wrong with releasing bleeding edge code, but make sure that people know what they should be using. You don’t want people using prototype code in development, because it’s likely to be buggy and may change drastically before release. For the work you want used by a broader audience, make sure you test it well, preferably by some people outside the project, before it’s released.
In terms of architecture, you’re not going to get it right the first time, so don’t be afraid of releasing early and deciding that you’re going to improve the architecture later. You simply don’t know what’s going to happen over time, and lessons learned from early releases will help you with the architecture. That doesn’t mean you should be gratuitously sloppy, but don’t expect your first release to be perfect.
If you have an interest in leading the project for an extended period of time (not just being technical lead), I suggest learning a little bit about project and team management (more dirty words!). Nobody’s reporting to you, but everyone can quit if they don’t enjoy working on the project. I suggest reading “Debugging the Development Process” by Steve Maguire (Microsoft Press) — it’s an easy read and helps you understand how to keep people focused.
Where do you see your project going?
That’s an interesting question. I really think this project is most effective being focused on the device part of the printing chain. I’d like to see us support more printers, and I’d also like to see some of our ideas (high bit depth and deviceN input support, for example) become more mainstream in the rest of the printing system.
One of the good things has been that while we’ve had a strong vision (generate high quality output for a wide range of printers), we haven’t been too insistent on exactly how we got there..
What’s on your project wish list?
Our grand strategic wish is for fully managed color transformation in the printing chain, so that any supported printer will generate identical high quality output with identical input, within the capabilities of the device and the output media.
For the Epson driver, I’d like to support the high end (Stylus Pro) printers at the same level as the consumer/prosumer ones. This is a challenge because we’ve been unable to get programming information on these printers. We’re making progress on this front. Some of the newest printers have inks with colors other than just cyan, magenta, yellow, and black, which have proven very challenging to support well.
What are you most proud of?
Overall, I’m very proud of the fact that we’ve been able to deliver a good solution to a major problem facing a lot of users, and continue to deliver improvements on a regular basis for better than 10 years. While the pace of change is nothing like it was in the early years, we’ve continued to deliver incremental improvements and support for new printers without disrupting our user community.
If you could change something about the project, what would it be?
That’s a difficult question to answer. Sometimes things that haven’t looked so good at the time have worked out well in retrospect, and vice versa. For example, the long delay (basically a 2 year slip) between 4.2 and 5.0 was very discouraging both for us and for users with new printers that had been introduced in the interim, but in the event the changes we wanted to make were simply too extensive to be done quickly and we wound up with a better platform for moving forward.
On the other hand, 5.0 went out with a major problem in handling borders that caused a number of distributions to introduce a patch that caused a lot of trouble — had we spent more time getting feedback and thinking about it, we would have avoided a major problem. Many distributions changed the borders for letter and A4-size paper to avoid cropping, and didn’t withdraw that patch when we released a fix in 5.0.1. Since there are still some distributions using 5.0.2, their users continue to suffer this limitation.
But as far as the project itself, I think that overall things have gone very smoothly indeed. Of course, it’s possible that others see things in a different light.
How do you coordinate the project?
Email and the tracker database. We tried using the SourceForge wiki for a while and it simply didn’t work out very well for us.
Regression testing has always been an issue for a project like this; with the large number of printers we support, it’s very difficult recruiting enough testers to cover them all in the breadth needed to ensure complete testing. In 5.2 we added the capability to perform bit-level testing against prior releases to detect any changes at all to the output, which increases our confidence that users will not see undesired changes from an upgrade. That makes it very easy to regression test a release against the previous one and spot any changes, and greatly reduces the need to manage the release testing process.
How many hours a month do you and/or your team devote to the project?
In the early days, I was sometimes spending 20-30 hours per week on this — quite a lot in addition to a full-time job. I don’t know what everyone else was doing, but there were some others who must have been spending close to that. It’s much less now, probably between 5 and 40 hours/month depending upon what’s happening.
What is your development environment like?
Our primary development platform is Linux, using the traditional gcc compiler and autoconf-based build system. We emphasize portability to other POSIX-based platforms and processor architectures; portability failures are serious defects that must be fixed for release. I believe that seeming portability problems are more often than not latent bugs that will cause problems on primary platforms sooner or later.
We also provide Macintosh packages thanks to Tyler Blessing and more recently Matt Broughton, both of whom are very experienced in that environment. While that platform has UNIX underpinnings, the upper layers are very different, and producing packages that will be well received by Macintosh users demands understanding of that platform.
We rely heavily on automated regression testing and have improved our tools over time. As noted above, we perform bit-level regression testing against previous releases. We use Valgrind as a key part of our release testing; while it is time consuming, it helps us detect crashes and memory leaks before they will affect users. We have zero tolerance for Valgrind failures.
Some of our tools are delivered as Perl scripts; the upgrade tool for CUPS users is a Perl script that upgrades PPD files, preserving user settings. This is another component that ensures minimal disruption for user upgrades.
|Jan. 13, 2000||Gimp-Print 3.0.5 (first public release)|
|Feb. 21, 2000||Gimp-Print 3.1.0 (initial Ghostscript support)|
|Oct. 28, 2000||Gimp-Print 4.0.0 (CUPS support)|
|Nov. 24, 2001||Gimp-Print 4.2.0 (first 4.2 release)|
|Sep. 12, 2002||Gimp-Print 4.2.2 (first Macintosh release)|
|Jul. 7, 2004||Gimp-Print 4.2.7 (final 4.2 release)|
|Jul. 22, 2006||Gutenprint 5.0.0 (first 5.0 release)|
|Oct. 19, 2008||Gutenprint 5.2.1 (first 5.2 release)|
|Aug. 10, 2010||Gutenprint 5.2.6 (current release)|
How can others contribute?
People who are interested in contributing should send mail to firstname.lastname@example.org (subscription required).
We need maintainers for the Canon, Lexmark, and PCL (Hewlett-Packard and compatible) drivers. These are important printers for a lot of people. A lot of HP inkjets are supported by HPIJS, so many (but not all) of those people have alternatives, but there’s no other FOSS support for Canon printers. If people are interested in other printers and can help out, we’d welcome that too. We’d particularly welcome color support for PCL color laser printers (currently they’re only supported in black and white).
It would be very desirable to convert the hard-coded data for those printers into XML format, as we did with the Epson driver a few years ago. It makes everything much easier to maintain, and it’s also easier for people to contribute support for new printers. It actually took us only a few months to do, and we have better tools than we did at the time to ensure that the extensive changes did not inadvertently break anything.
There are other specific projects that we’d welcome assistance with; one example is incorporating the latest version of Raph Levien’s EvenTone Screening dither algorithm. There are surely others that we’re not aware of. Also, we can always use assistance in testing.
This month and for the rest of 2010, we’re highlighting some of our most venerable projects. This month’s Project of the Month is one of about 1,000 that began hosting on SourceForge.net in the site’s first year of existence, beginning in November 1999.
More projects of the month
Project name: Gutenprint
Date founded: January, 2000
Project page: http://gutenprint.sourceforge.net
Occupation:Software engineer/project manager
Education:Education: SB in Computer Science and Engineering
Location: Boston, MA
Occupation:Software developer, Linux admin & Oracle DBA Currently involved in Spacewalk, TOra and Gutenprint
Education:MSc in Computer Science
Location: Czech Republic
Education:BS in Business Administration
Why did you place the project on SourceForge.net?
Initially, I simply wanted to make the source code available to more people. At the time (late 1999), I had dialup Internet access, and even though I had a dedicated line, it was simply too slow for people to download from.
When it quickly became apparent that the project was going to be more than just an improved Print plugin for GIMP, having a full-featured service supporting releases, bug and RFE tracking, collaborative development, and source control was essential. At the time, there were very few hosting services of any kind catering to non-business users, much less ones with offerings optimized for supporting free software projects. SourceForge was the only viable choice for this purpose.
How has SourceForge.net helped your project succeed?
The most important service SourceForge has provided is the same as it was when I started the project: source control (we’re still using CVS — it’s sufficient for our needs), release management, developer management, mailing lists, web hosting, and the like. This makes it easy for additional contributors to join the project, and saves me from having to cobble together and manage my own hosting.
What is the number one benefit of using SourceForge.net?
One-stop hosting for all of our project needs.