Bye CUPS: Printing with Netcat

While the article is correct, it omits most of the actual function of CUPS. Many printers are capable of accepting various types of documents directly over the network, with postscript, HP PCL, and PDF being commonly supported---and ASCII pretty much universally supported.

The problem is that few printers support _all_ of these standards. Postscript, for example, is surprisingly complex to implement in practice, which leads to a lot of inexpensive network printers actually lacking postscript support. Further, printers are very slow at rasterizing, and so while support for PDF rasterization is very common you probably don't want to use it. You can easily see a minute per page for printing modest PDFs. In-printer PDF rasterization is also of very uneven quality, and I have seen issues like completely broken kerning in documents due to the printer's poor handling of embedded fonts.

One of the key functions of something like CUPS is to address this problem: CUPS standardizes the format of all printed documents to something that is well-supported by the printer, and performs much of the rasterization ahead of time on the much faster print server. This saves time and improves reliability since you don't need to figure out if a given document is supported by the printer. For most printers these days some variant of PCL is the preferred language for jobs, as it's simpler and easier to implement than Postscript. It also presents fewer security concerns.

Of course the other major problem CUPS solves is the management of the queue, including across multiple users. That's an important feature but not one that matters in a lot of home situations. That said, if you don't use a printing system you can and will run into annoying situations where you cannot print a document because you are waiting for the previous one to complete sending, which often gets blocked on the printer's memory space or rasterization.

Hah. I had a similar moment of enlightenment with FreeBSD when somebody explained that you can just cat a wav file into /dev/audio (or /dev/dsp? forget the exact name). And that you can produce white noise by catting /dev/random to the same destination. With no barrier to the sound card like that, I was free to experiment with programming dfferent noise algorithms and figuring out how digital audio works. I eventually did things the proper way with OSS and finally sndio on OpenBSD, but direct, universal interfaces like files invite that initial exploration and help you get things done quick and easy.

netcat is also a secret weapon around the house. My girlfriend runs macOS, but it's way more reliable to just nc files to each other over wifi than deal with all the cloud and airdropping bullshit.

The point of CUPS and of server middleware in general like PulseAudio and what not is when multiple clients all want to send output streams to the same sink. Just sending the stream directly to a device with no middleman works fine provided 1) the stream is encoded in a way the device understands, and 2) no one else is trying to use it at the same time. For a shared network resource like a printer, unless you live alone and are the only user on your LAN, betting no one else is sending a job to the printer at the same time might be a rough bet.

Even when it works, there might be downsides, as some other comments are alluding to. The long print time one mentioned is likely because while you're lucky that your printer understands how to transcode pdf to ps in order to print a pdf, the onboard processor on the printer is much weaker than whatever you have on your computer. Also beware that if you're doing this on a radio network, I don't think netcat can encrypt the traffic. So don't be printing your credit card statements this way.

FWIW, the Internet Printing Protocol (and IPP Everywhere in particular) make printer setup in CUPS far, far easier, but distributors seem reluctant to encourage it. I wrote about my experiences with IPP back in June (https://lwn.net/Articles/857502/). I expect to never have to hassle with printer drivers again...

I used to do this at home all the time (from Linux though): networked printer with its own IP address and then good old netcat. I'd do it with PostScript files and send them to HP LaserJet 4M+: not only do these beauties speak PostScript natively, they can also be made to display the infamous "PC LOAD LETTER" message.

I'd try to find these printers used then I'd upgrade them: more RAM, more fonts, adding a network card inside the printer etc.

I still have several of these printers in a garage, some of them have printed more than 300 000 pages. They probably still work: some things were that good back then.

And, yup, there's something feeling magical when netcat'ing a .ps file (or another format) directly to the printer.

So, network equivalent of piping text to the parallel port?

I immediately tried it...

Aaand this is how I made my printer spit out dozens of garbage pages with just one to two lines of gibberish on each (the PDF source code, admirably giving up the page at each occurrence of the corresponding char)...

If you have a single host, and a single printer, or your printer itself is both network-enabled and can manage its own print spool, direct TCP/IP printing may indeed work for you.

The value of CUPS is that it enables the CUPS-serving computer to run as a print server. This means not only print drivers (document format support --- typically plain text, Postscript, and one or more PDL (printer definition languages) & PCL (Printer Control Language), but status on the printer, queue management, job control, and access control. Note that if your printer is generally available on your local WiFi network, you might want to give more thought to that last element.

If those are overkill for you and your printer Just Works with generated output, then yes, you can get by without the complexity.

Note that you can also often telnet directly to the printer port.

Be aware of what you're trading off, though, and whether or not you actually need what CUPS, or direct network access, offers.