About the Project

What It is

From my personal point of view:

The best way to understand the details is to implement them

It is my experimetal approach to make printing work as I want it

It is still a design study with regard to many details. For example don’t expect a stable API

It is a playground how to create and maintain a useful documentation

Playing around with embedded documentation to avoid the divergence between what the code does and the documentation describes

Using various tools like doxygen for the main API documentation, plantuml for exciting diagrams, ditaa for graphics. And doxygen-awesome-css really improves the boring doxygen style

And from the technical point of view:

All services start on demand only

Can rasterize PDF format

Supports USB based raster printers only

Supports monochrome printers only

And while at it: supports only a few printers, yet

Implementation details

The communication between the components happens via DBUS.

No persistent printer queues. E.g. you can print if your printer device is online, you can’t if it’s offline.

No static PPD files to describe your printer and its capabilities

The PPD files will be created on the fly on demand.

The PPD files contain the options/parameters you can really change. E.g. if your printer has only one paper tray, you have only one paper format available.

If your printer can autodetect the filled paper format (like some label printers do) it can reflect this automatically in the PPD.

Printer drivers are self-contained. They accept print jobs, raster them and deal with device communication (sounds complicated, but dfferent levels of abstractions are available).

The printer driver launches, if your printer becomes online. And terminates if your printer goes offline (at least if it is a USB based printer).

The CAPS universe components depend on various ‘systemd’ and ‘udev’ features.

Almost all CAPS universe components work without root permissions (with one exception).

If you always use one printer configuration (e.g. embedded usecase), all CAPS universe components can deal with a read-only root filesystem (except for the documents to print, this still requires a temp. storage).

A small compatibility library is available to make applications happy which depends on the CUPS client library. This is only an ugly hack, because the whole CUPS client library looks like an ugly hack to me.

The whole CAPS universe is built on individual libraries

The CAPS universe components use autotools based configuration and are fully cross build aware (the latter was one of the main development goals).

Where ever possible the libraries are LGPL, else GPL.