Von: Michael Pfeiffer
Datum: 17. Juni 2008 21:22:27 GMT+02:00
An: Jovan Ivankovic
Betreff: Re: CUPS Port Progress
I see also these two possibilities:
1) CUPS Port
2) Integrate the various filters into Haiku
I don't know yet what's better for Haiku. The feature set of CUPS is
appealing (see comparison at end of mail) though it seems in
contradiction with Haikus principle to keep it small and simple.
Without conducting any studies it's hard to say which of the
features are really needed by the end user. OK, Mac OS X uses it
too :-)
Sharing a printer is one of the missing features in Haiku, but that
could be added to Haikus print_server too, by providing an IPP
server, probably implemented in the print_server.
I guess just porting CUPS would not be that hard, however the
integration into Haiku would probably be the difficult part.
It's OK for me if you prefer to integrate (some) of the various
filters into Haiku. That way we get what we need now (actually in
the future when/if Haiku R1 is release :-)) and not something that
we might or might not need far in the future.
Have a look at this picture:
http://en.wikipedia.org/wiki/Image:CUPS-block-diagram.svg
Independent from the two possibilities. For the front end there is
one or better two Haiku printer drivers needed that use PPD for
configuration of the printer model specific features.
1) PostScript printer driver (already there needs PPD support added,
should be
improved to create more compact output).
This driver is for native PostScript printers and for printers
where only a
GhostScript printer driver exists.
2) Raster printer driver with PPD support. This printer driver
constructs
a stream with MIME type: application/vnd.cups-raster.
This way there is no need to first convert the Haiku print job into
PostScript, which in turn would be converted by GhostScript to the
"raster" format.
I don't know the "format" of the "raster" format (do you have any
pointers?),
but I guess it would be trivial with libprint to accomplish.
In case of a CUPS Port the output of the Haiku printer driver is
handed over to CUPS for example via the hypothetical "CUPS"
transport add-on. For example this could write the output to a file
and then pass it to CUPS using lpr (whatever the command is) or
using the CUPS API directly.
Now that I think about it a second time, a CUPS port without tight
integration into Haiku, could work quite well at this point already.
Hmm? Maybe we can postpone the tight integration of CUPS for a later
project?
In case of the integration of various filters the layer "CUPS-
raster" in the picture needs to be integrated (either ported from
CUPS if possible (license issues need to be resolved first) or a
fresh implementation) into these printer drivers.
The output of the filter between "CUPS-raster" and "CUPS backends"
then needs to be passed to an Haiku transport add-on.
The proposed tasks are:
Either port CUPS:
[ ] Complete port of CUPS
[ ] Port filters
[ ] GhostScript
[ ] GutenPrint
[ ] Foomatic?
[ ] Tight integration into Haiku (TBD what that means)
or integrate filters into Haiku print driver(s):
[ ] Integrate "CUPS-raster" or implement it from scratch into these
printer drivers and
send output of raster-to-print_language/protocol to Haiku
transport add-on
[ ] Decide which of the "filters" should be integrated
[ ] GhostScript
[ ] Gutenprint
[ ] "native" CUPS drivers
[ ] PCL
[ ] ESC/P
[ ] others?
[ [ Foomatic?
[ ] other?
Both:
[ ] Add support for PPD to Haiku PS printer driver.
[ ] Create a "raster" printer driver with libprint that also
supports PPD.
This is optional if we support GhostScript.
Depending on the the "raster" format, the "raster" printer could be
faster than the PS driver, because the PS driver creates quite
large output.
BTW recently I had look at my PPD parser in C++, with a GUI
generator and even a PPD file selection already exist from 2004 or
so. I guess that could be used as a basis for the PPD support in the
printer drivers. Maybe I can even do parts of that myself, if time
permits.
Ciao,
Michael
- [ ] Comparison CUPS vs Haiku printing system
- [ ] Printing from application
- [ ] Haiku provides an API to open Page or Job setup
configuration dialogs (BPrintJob)
- [ ] Haiku: Printer driver is responsible to implement
that configuration UI
- [ ] Haiku provides an API to create the contents of a
print job (BPrintJob and other classes from Interface
Kit)
- [ ] CUPS is file based; the printing application is
responsible for page/job configuration (APIs probably
exist, but are not part of CUPS) and to create a file
in a format that can be processed by CUPS; e.g.
PostScript, PDF, text, various image formats
- [ ] CUPS provides API for configure a job based on PPD
file (as mention no UI though)
- [ ] Server
- [ ] Haiku print_server uses private BMessage based
protocol; application use BPrintJob to interface
print_server
- [ ] CUPS daemon uses IPP
- [ ] CUPS provides Berkeley and System V commands for
printer configuration, job handling, ...
- [ ] CUPS provides also an API for printer configuration,
job handling, ...
- [ ] CUPS provides a web interface for printer
configuration and job handling, ...
- [ ] Haiku provides Printers preflet for printer
configuration and job handling, ...
- [ ] CUPS can cancel started job
- [ ] Haiku cannot cancel started job
- [ ] CUPS server can be used by remote clients
- [ ] Haiku can be used locally only
- [ ] Printer Driver
- [ ] Haiku: printer driver takes a print job file with the
archived rendering operations and converts it into
printer language
- [ ] Haiku: printer driver uses a transport add-on to send
the result to the printer (e.g. USB port, parallel
port, over network)
- [ ] CUPS uses chain of filters to convert a file into the
printer language and uses a "backend" to send it to a
printer
- [ ] CUPS built in printer languages:
- [ ] PCL
- [ ] ECSP
- [ ] Haiku printer drivers (lack printer model specific
configuration; but also provide a configuration UI)
- [ ] Canon LIPS 3 and 4
- [ ] HP PCL5 and 6
- [ ] Adobe PDF
- [ ] Adobe PostScript (creates images only; no text or
vector graphics)
- [ ] Preview
- [ ] CUPS various filters can be integrated to support
more printer languages and printer models
- [ ] Ghostscript?
- [ ] Gutenprint
- [ ] rastertoprinter/rastertogutenprint?
- [ ] HPIJS Drivers
- [ ] rastertohpijs?
- [ ] Commercial drivers
- [ ] ESP Print Pro
- [ ] Turbo Print
- [ ] Okidata
