Introduction

The CAPS universe is a yet another approach to print on a Linux based system. It doesn't use a monolythic implementation. It's separated into different operation blocks. It assumes your printer is attached locally to your host.

History

A few years ago I tried to get my printer work from within an embedded device. This was a real pain. Everything existing seemed not intended to work in such a way. Then I took the existing sources and tried to repair things, to make them work as intended. But after a few tries I decided the existing code is a mess and broken beyond repair in this regard.

And if you want to understand things, the best way doing so, is to program it by yourself :)

That was the birth of the CAPS universe. At the beginning it used a different name, but that doesn't matter. The beginning was in 2012. The first try was like a re-implementation of the existing printing system: a big central monolitic beast. Once I faced this, I threw it away. This was in 2016.

The next approach was and is what I call the CAPS universe: a few slim applications dealing with each other and make printing work.

What it is and what it isn't

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
I'm playing around with embedded documentation to avoid the divergence between what the code does and the documentation describes
I'm using various tools like doxygen for the main API documentation, plantuml for exciting diagrams, ditaa for many 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 😄

What It isn't

a full replacement of the CUPS printing system, 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
- they will be created on the fly on demand
- they 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
an IPP service is available. But IPP is a mess: A totaly overengineered and error-prone protocol you even cannot check if the received data is correct. Try to run the "american fuzzy lop" against it and be surprised.
And IPP needs a lot of non-standard extensions to make it a little bit useful. And it's hard if you want to be compatible with CUPS.
Because CUPS is much more a mess regarding IPP (and even fails if it tries to communicate with itself via IPP…). Don't try that. You will lose that fight and many valuable years of your life.