[haiku-development] Re: GSoC Project - Continue the CUPS port

[sorry, pressed enter to soon previously]

Hi,

Ionut Cristian Paraschiv wrote:
If there is someone who knows what is yet to be implemented at this project, please give me some information. I've looked through the sources, but I haven't figured out this yet. 
Thank you!
CUPS is mostly working, I guess most of the basic functionality should compile and run cleanly. Besides the sources already pointed out in this thread, there's a patch at HaikuPorts[1] and there's the GPL source code[2] from ZETA (a previously commercial BeOS distribution).
However, CUPS basically only implements general printer driver management, not the actual printer support. A lot of the functionality in CUPS is already supported by our current print_server & transport add ons. The interesting parts (taking a closer look at the ZETA implementation) is in foomatic[3], which is a database of printer descriptions (it uses an XML database converted to PPD[4] files) for describing the supported printers and their features.
The real interesting part, and what ZETA used CUPS/foomatic for, is the actual printer drivers. Most of them use Ghostscript[5] backends to convert Postscript to the output format used by the printer. This gets Haiku the real printer supported that is normally expected when people talk about the CUPS port.
I was involved in earlier goes at porting CUPS to Haiku, and the implementation for ZETA. I've got a bunch of patches on my local development tree of Haiku that improves our current printing infrastructure. These should be committed around BeGeistert (next weekend).
My personal opinion is that CUPS might be a bit too much. I'd rather find a good way to create a printer driver that uses either Ghostscript or the Ghostscript backends to create the output stream, and then utilize our current transport add ons for actually sending the data to the printer.
So, the first step would be to determine which printing functionality we actually want to have out of CUPS, and it'll probably turn out to be easier to expand our current print_server to implement this. Then use the foomatic XML database to come up with a good format to store printer feature sets (my current idea is to either use PPD files, and add attributes to them for quick lookup), and use Ghostscript backends for the actual printing through a special printer driver.
Besides all this there is a certain amount of cleanup to do in the current printing architecture, as there's a whole lot of shared code floating about at different places in the Haiku source tree that should, IMNSHO should be integrated into the print_server. A discussion on this, especially wether or not we want to keep R5 backwards compatibility on printer driver/transport add on level would be appropriate (dropping that would make it possible to have a much cleaner addon structure for the print_server, making all this much easier).
I was planning to discuss a lot of this @ BeGeistert, but an earlier discussion on the list wouldn't hurt either I guess... 

HTH,

Ithamar.

[1] http://ports.haiku-files.org/wiki/net-print/cups
[2] http://www.zeta-os.com/cms/download.php?view.19
[3] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/database/foomatic 
[4] http://en.wikipedia.org/wiki/PostScript_Printer_Description
[5] http://pages.cs.wisc.edu/~ghost/

Other related posts: