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.

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...

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.

Terrible idea on several levels.

Avoid jetdirect (9100) port like the plague. Partial files? Errors parsing the postscript? Outputting to the jetdirect port will result in printing every bit of that trash out, no questions asked. Walked up to a printer and found Nearly blank pages with one PCL or Postscript line telling you there's an error? That's jetdirect printing for you, and there's no good reason for it. LPD and IPP have actual protocols signaling start and end of jobs, so nothing comes out if something in the process fails, saving paper, toner and frustration. Yeah, you can't just use netcat, but you can easily use lp: lp -h 192.168.0.30 file.ps

Printing raw to a printer without drivers is also a terrible idea, it happens to work some of the time, but leaves you at the mercy of printer defaults. Printing a US Letter page on a printer which defaults to A4 (or vise versa)? Say goodbye to part of your print job. Now, yeah, you could program the correct command sequences into your postscript document, but why would you want to? Plenty of other things used in documents will cause errors if sent to a printer without being sanitized by CUPS (or filters to lpng, or whatnot).

CUPS isn't great. It makes printing so much harder than it needs to be. I absolutely hate having to remember the exact syntax to select B&W on my color printer: lp -o ColorMode=Monochrome It's very difficult to track down how it's mangling your print jobs, when there's a problem and you need to do so. Having to do an old apache style allow,deny reverse polish notation logic to configure who you want to access the printer and admin interface is user-hostile to be sure. And more. But it certainly has made it much easier to go from nothing to up and printing quickly, it's certainly got every feature you could need, and it's certainly reliable. I've done it in the old days, and I certainly don't want to go back to configuring printcaps manually with inscrutable invocation of ghostscript and many other print filters.

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.

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.

My first introduction to the internet was downloading Magic the Gathering card lists as postscript files via FTP and then FTPing them to a postscript printer. Would have been 1994 and they were some sort of Sun machine at LMU. Internet has been all downhill since then.