I am familiar with kernel modules and have heard of the IPP, PPD, PS, PCL, PDL printer drivers concepts. I have read that there are "generic" printer drivers that come preinstalled on Mac/Windows so you don't have to install a custom driver and it makes the UX seamless.

In that light, I am looking for what these generic drivers might look like (assuming it would be a kernel module). Haven't found any examples exactly on this topic, but found these repos:

  1. https://github.com/koenkooi/gutenprint
  2. https://github.com/OpenPrinting/cups-filters
  3. https://github.com/watson/ipp-printer
  4. https://github.com/apple/cups

Related to these, I found in Gutenprint: src/main/print-lexmark.c and src/main/canon-printers.h, which have these cap_t ~table~ things that seem to have the features encoded for individual models of printers. That seems like a lot of work to do. There's a huge list of supported printers in Gutenprint here.

My question is in a few parts:

  1. If these printer specs/features like the 2 links above were reverse engineered, or obtained from a specification of some sort. (Sort of a tangential question).
  2. Where, in any of the 4 above listed/numbered GitHub repos, a "generic" device driver such as for PCL or PCD or PPD exists.
  3. The concept in which I should be looking for drivers: PPD, PCL, PDL, PS, IPP. It sounds like PPD is a configuration format defined by the printer, while PS/PCL (and maybe PDL) are the main driver specification languages/formats, and IPP is a driver protocol but isn't widely supported. And PS is for high-quality photos, while PCL is for standard document printing. This is why I was looking specifically at PCL, and not PS, but I haven't found any "generic PCL driver on GitHub" sort of thing, and not sure if this is what I should be looking for.
  4. Otherwise, if there exist any open source printer drivers outside of what I have provided which provide an example of implementation.

closed as off-topic by Michael Homer, Mr Shunz, roaima, Shadur, Rui F Ribeiro Jan 12 at 9:11

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Requests for learning materials (tutorials, how-tos etc.) are off topic. The only exception is questions about where to find official documentation (e.g. POSIX specifications). See the Help Center and our Community Meta for more information." – roaima, Shadur
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Look at CUPS. You don't need a kernel-level driver for your printer - there already are perfectly working drivers for both parallel port and USB printer connections; the "driver" part you need is the filter that translates the various input types CUPS can handle into the PCL/PS that the printer wants to hear. – Shadur Jan 11 at 10:12

PCL and PostScript (PS) are not driver specifications but page description languages (PDL): if your printer supports either of these, the job of the printer driver would be to convert the print job to either PCL or PS.

Both PCL and PS can do high-quality photos. But PCL is actually more efficient with large high-resolution bitmap images, especially when your computer's main processor is much more powerful than the printer's processor (the usual case today). PostScript is at its best with text and vector graphics: it can offload much of the scaling/rendering process to the actual printer, which was useful back when a laser printer alone might have had about as much memory and processing power as the rest of your computer. For vector graphics, PostScript can just transmit the required commands to draw the graphic, and the printer will then reproduce the graphic on its own, using its full native resolution.

The driver would need to take into account the available features of the printer: for example, if parts of the print job reach all the way to the edges of the paper, but the printer requires certain minimum margins at paper edges to which it cannot print, it would need to make decisions whether to scale the entire page to fit, move parts of the job to another page or just cut off the unprintable edges. And sending color data to a printer that can only produce shades of grey is just a waste of time (and network bandwidth, in case of network printers). A PPD (= PostScript Printer Description) file supplies this printer-model-specific information.

Unix/Linux printer drivers are usually not kernel modules: instead, they are just regular user-space programs (or even scripts) that convert the print job sent to their standard input to the appropriate page description language on their standard output. In CUPS terminology, this is known as a filter.

If a locally-connected printer uses a non-standard USB endpoint structure (some cases of "host based printing") or some other special protocol, the driver might include a program that handles the special communication protocol too. In CUPS terminology, this is known as a "port monitor". CUPS includes port monitors for some common cases, but a print driver can supply a customized one.

The print spooler daemon (these days, mostly cups) has the job of receiving the print job from the user, identifying its format, applying any necessary conversions (by filter programs which might also be called "drivers"), and finally outputting the result to the printer device (optionally using a port monitor tailored to this specific printer model).

CUPS has built-in "generic drivers" to handle most PostScript printers by using PPD files (PostScript Printer Description) to supply the printer-specific details. CUPS also extends the PPD file specification so that non-PostScript printers can also be described by PPD files. In this case, the PPD extensions specify one or more extra programs CUPS should run to convert the print job from one of the formats already known to CUPS to whatever data format the printer will accept.

For your numbered questions:

1.) The most widely-used page description languages like PCL and PS have published specification documents: once upon a time, back when actual paper manuals came with the hardware, the specification book might even have been included with the printer.

Other languages and protocols, like many used with "host-based printers", have been reverse-engineered. Yes, it's been a huge effort.

2.) In https://github.com/apple/cups/tree/master/filter, you'll find the CUPS generic PostScript and raster (= raw bitmap data) drivers. There is also the code for reading PPD files.

3.) See the introductory text of my answer above.

4.) openprinting.org has a huge database of printer models and open-source print driver solutions for them. If an open-source driver solution exists for a particular printer, I would expect to most likely find it - or a link to it - in there.

  • Not sure what is meant by "filter" in this context. – user10869858 Jan 10 at 9:14
  • For example, with a suitable PPD file, Ghostscript can act as a PS/PDF-to-[printer-specific format] filter for CUPS: the PPD tells CUPS to start Ghostscript with specific options and send PDF or PostScript data to its standard input. Ghostscript will then pass the converted data on its standard output. The data will then be piped either back to CUPS for spooling, or to the port monitor process for sending to the printer. – telcoM Jan 10 at 9:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.