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.
> 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.
That's interesting. Back in the day (of HP LaserJet 4L and similar), I learned that rasterizing on the PC and sending to the printer was very slow because printers had slow connections and little memory. The resolution was also limited and it looked blocky. The rule was to never print "as bitmap" if you could avoid it. OTOH printing "flat" postscript was very fast and yielded much better quality. I think the printers allowed loadable fonts and often had some of the standards (Times, Arial) pre-loaded.
The big issue is that, back when, printed documents were much simpler. Printers offer a set of embedded fonts that makes it very quick and easy to print simple text documents, if you are okay with one of the printer's embedded fonts. You just need to send a couple commands to set up the font parameters and then the text. PCL and moreso Postscript also give you some vector drawing capability that makes printing line art in vector format very efficient.
But the nature of printing has changed! People now want to print things in all kinds of arbitrary fonts, which requires either rasterizing to print resolution (which is a lot, 300-600dpi) or sending the printer all the outlines as vector instructions. Postscript and PCL take different approaches to this and sometimes different print stacks do as well. And then add graphics, and 99% of documents you encounter these days provide all graphics in raster format in the first place. The result is that something, either the host or the printer, needs to take a raster graphic (which can even just be little icons) and interpolate them to whatever dot pitch the printer is using. That tends to be the real killer... that interpolation can take a printer a very long time. Usually there's some way in the PCL (exposed via the printer driver) that you can tell the printer to interpolate to a lower DPI which will speed things up, but make your images look worse.
Unfortunately sending 600dpi graphics over the network can still be kind of slow and does contribute to the "Receiving Data..." and time to first page even with modern printers and drivers. Most laser printers have a pretty poor TTFP anyway, though, so it's not too big of a deal.
I suppose if you have a printer that doesn't support PostScript or PDF then you could pipe the output through GhostScript. This is what CUPS is relying on anyway.
Right, there's no magic pixie dust in CUPS that you can't manually reproduce using a concoction of software packages, command line incantations and maybe some scripts. But then you're just re-implementing CUPS, manually.
Is there any guide on how to make a Linux-based print server which would be autodetectable by all the major OSes? I feel like we need a dedicated print server for our office (where there are many computers running Ubuntu, Windows and MacOS) because the printer doesn't work reliably enough. I have never actually seen such a scenario in the wild - people seem to always connect to network printers directly (they also used LPT and USB printers shared via the standard means of Windows in the past).
It's very much non standardized. The standard is PPD, so you'd want a parser for that at the very least, perhaps a user interface too, and before long you want something similar to CUPS.
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.