Re: [Gimp-print-devel] Printing & KDE

[Michael S. <mi...@ea...>]

Waldo Bastian wrote:
> ...
> I guess that CUPS basically uses ghostscript in some fashion as a
> kind of printer-driver. That makes the following chain:
> 
> 1) printer driver  (ghostscript)
> 2) transport layer (CUPS)
> 3) abstraction layer (sysAPS)
> 4) KDE (?)

Actually, it's more like:

    KDE -> sysAPS -> IPP -> CUPS -> filters -> driver -> backend

For the current CUPS release, there are two possible "raster paths",
either using Ghostscript or our image RIP, which send raster data
to the printer driver, which sends the print data to a backend
process that talks to the parallel, serial, USB, IR, etc. ports or
one of several network protocols.

IPP is the transport layer.

CUPS is the printing system/spooler that decides when to print and
what filters are needed.

The filters are found from a MIME database that defined types and
filters available to the system.  For a typical PostScript job to
a non-PS printer, you'll run "pstops" and "pstoraster".  "pstops"
inserts the printer options (resolution, media size, type, etc.)
and "pstoraster" is Ghostscript with the CUPS raster driver (only)

The driver can actually be multiple filters, e.g. one to print
text fast, and one to do raster graphics, and one to do HP-GL/2,
etc.  The basic driver just needs to read pages of raster data
from the upstream filters and generate the appropriate printer
data.

> ...
> The disadvantage of so many layers is that new, more advanced
> features require adaptions in multiple layers before you can use
> them at the application level.

That's why you design your interfaces to be extensible. :)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com