[cups.general] ditherLine available in libcupsdriver in 1.4-1.5, future directions

Michael Sweet msweet at apple.com
Mon Jan 23 14:04:48 PST 2012


On Jan 23, 2012, at 12:46 PM, Johan Henselmans wrote:
> ...
> I did not know that use of the source code of the filters and drivers 
> would implicate to open source the printer driver that is based on it. 
> Is that also the case for the sample raster filter code that is 
> available in the documentation and the source code?

All of the filters are provided under the terms of the GPL2; only libcups, libcupsimage, and the files in the "test" directory are LGPL2. There *is* an exception for code that runs on Apple operating systems (right now Darwin, iOS, and OS X), but that is limited accordingly.

> ...
> I just had a look at the IPP Everywhere specs.
> 
> Would the spec not implicate that every printer has to implement it's 
> own PDF/cupsRaster to raster internally, and run some kind of cups alike 
> printserver internally?

Yes, the printer needs to implement support for CUPS Raster (not all that hard considering that every printer vendor has used PackBits in their products and most have 8-bit gray/24-bit RGB paths already) and IPP.  It doesn't need to be as complex as the full CUPS installation, and in fact the test directory has a simple IPP server implementation based on libcups that could be adapted for embedded use quite easily.

> It seems to me a lot of duplication of effort. 
> (Unless of course, every printer runs it's own freebsd/linux that would 
> use the cups/openprinting work...)


You can look up the slides I've shown over the last few years, along with the IPP WG mail archives going back to 1998 or so.

To summarize: printer vendors already need to write large amounts of driver software and a smaller amount of firmware code to support printing today. Every platform (and often every version of those platforms) needs a different (large) set of driver software written to support printing, and then that software must be tested in all of the common client and printer configurations, supported for a long period of time, etc.

By standardizing the interface between client (computer/phone/whatever) and printer the vendor only needs to focus on doing a good firmware implementation and whatever feature-ware they want to bundle with their printers - more than half of the software needed for a printer (which is duplicated for every printer model) will no longer need to be written, and that printer will be usable from any client that supports IPP Everywhere...

Similar things have already been implemented for many of the peripherals you use daily - mice, keyboards, monitors, hard drives, optical drives, etc.  Imagine if you still had to install vendor-specific software to use them?  How much duplication of effort was there in the days before standardization?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair





More information about the cups mailing list