Did you ever wonder, how we arrived here, why are there so any formats, protocols and alphabetic abbreviations when it comes to printing?

Let's examine the three main ingredients that shape how we can print from our computers to our printers: the format (the actual format of the data once it reaches the printer), the protocol (how to address the printer you send the data to and how to send the data in the format above so that it reaches the printer) and the transport (what physical solution you send the data over with).

Item #1 — Format

There's no single format. For decades, various manufacturer alliances tried to come up with something universal that everybody can understand and support, and all of them failed, miserably. However, nowadays, there are some emerging solutions that have not yet failed, mostly PWG (IPP Everyhwere). As with everything else, Apple had to have its own way (Airprint or URF), but they didn't invent anything, it's the same as PWG internally, just in a different package. To be impartial, nobody really invented anything, these formats are just a plain bitmap with an ubiquitous compression algorithm, put inside a wrapper describing the details of the print job, that's all.

For a perspective, you have to consider that network bandwidth and printer processing power was much more expensive one or two decades ago. Many printer vendors had some proprietary language that described the printed material in terms of fonts, letters, vector graphics sent over that was interpreted and converted into actual toner or ink placement inside the printer. The most established formats (called PDL or Printer Description Language) were:

• PostScript and PDF — driven by the emerging graphics and desktop publishing industry (and for at least a decade or so meant the only feasible way to produce really high quality, press ready output)
• variants of PCL of Hewlett-Packard — a major manufacturer of laser printers
• variants of ESC of Epson — a major manufacturer of color inkjet printers

The latter two were major hardware players and their languages became some kind of a de facto standard, licensed and used by many other printer vendors as well.

Such an interpreter built into the printer requires a considerable amount of processing power and cannot be easily modified (fixed) once the printer was manufactured and deployed at the user. As networking became commonplace and cheap, as well as manufacturers wanted to sell cheaper printers with faster turnout (this means both less computing power inside and less time and money invested in ironing out bugs in the firmware), came the era of so-called (Windows) GDI printers. Despite the marketing moniker, these have nothing inherently Windows about them. It's true that their vendors usually did practically nothing to support them on other operating systems and only supplied Windows drivers, being the platform for the overwhelming majority of their users, or so they decided, but that's not a technical limitation per se — any operating system could, in theory, create the print data to send to them.

In the case of these printers, the host computer prepares everything as a paper sized large bitmap and sends it over to the printer. Some of these printers are so dumbed down that they don't even have the memory to mirror the received image to put onto their laser drum, so they expect the host computer to send everything already mirrored. Although these formats were usually considered proprietary and the vendors were secretive about them, practically all of them relied on well established bitmap formats. That bitmap was neither JPG nor PNG but other formats typically used in the communication of fax machines because those algorithms provided much better compression with black-and-white documents these printers were mostly used to produce. JPG is particularly unsuited for this purpose, it's intended for real life pictures, not documents. These formats were also proprietary in the sense that each manufacturer tried to come up with a somewhat different way to package the data, with different headers, different external wrappings, still they were very similar internally and there was really nothing special or innovative about them, just the bitmap of the page.

Generating a large bitmap was once frowned upon by professional users wanting quality coupled with speed but today, it's the simplest solution. Back when the GDI printers went that route, it was cutting corners because delegating the task to the user's computer was easier and cheaper for the printer manufacturers than to perform the task in their own hardware. Now when a toaster might have more memory than a desktop computer a decade ago, bitmaps are touted as the "new" innovation again because describing the whole page as an image is the easiest way to be completely independent of more complicated page description formats. And today, we can simply afford the larger memory and bandwidth needed.

So, these new, emerging, so-called driverless solutions (PWG and Airprint) do the same: a bitmap for each printed page. Even Mopria's PCLm format (which, despite the similar name, has absolutely nothing to do with Hewlett-Packard's PCL), although packaged into a specialized PDF, is nothing but a large bitmap in small chunks.

Plain image formats like PNG and JPG are only used in the photo industry with specialized photo printers. PNG files are large because it's a lossless compression, JPG, as already mentioned, is very poor for documents, so it's avoided for general purpose printers.

Item #2 — Protocol

Once you have the printer data generated, you have to send it to the printer somehow, and this is where protocols come in. Established ones are basically all about how to address the printer.

• RAW and LPD — traditional solutions from the Unix/Linux world, RAW it the simplest, no frills, just sending the format above to the printer. LPD can already handle more than one printer attached
• IPP and CUPS — more sophisticated protocols from Unix/Linux, these already can describe what the actual printer is capable of, thus they can make installation mostly or completely automatic
• Samba — sharing devices in the Windows world
• FTP and HTTP — well-known internet protocols adapted to printing
• UPnP — Universal Plug & Play wanted to be the network successor of the previous Plug & Play of mostly USB devices that automatically set themselves up when connected to a computer. Its reputation was severely tarnished when its inherent security problems (more precisely, complete lack of security) appeared in the news but those don't really influence printing inside a local network. Still, it might be completely disabled in corporate environments because of this.
• WSD of Microsoft — Web Services for Devices is really just a fancy name for the various contemporary networking solutions in Microsoft Windows

Why so many? As you can see from the description, this has both historical reasons — all started in a previous era where computers were scarce, used by professionals and arrived to another world where everything should be automated and should just work out of the box. Also, we had different operating systems and platforms and they all provided their own solutions.

Most of these can handle more than one printer at the same time, so apart from an address like an IP address to send your data to, they also need an extra name to differentiate between the actual printers. This extra identifier has different names like queue, folder, path but basically, each simply denote a printer attached. The protocol can also provide authentication where only specific users are allowed to send a print job.

Put simply, while Format was the format of data the printer receives in the end, Protocol can be seen as the format of the data en route to the printer. It usually has various metadata elements like who sends the job, where from, where to, when, in what format, plus the actual print payload.

Item #3 — Transport

In order to reach the printer, you need to have some physical means of communication between the originating machine and the printer. This can be a network, internal or across the globe, WiFi (also as simply a standard network that happens to use WiFi, but also as a special WiFi Direct mode when the host and the printer communicate directly, using the same WiFi signals but in an ad hoc way, independent from the usual network operation), Bluetooth or USB.

In the introduction, we promised three main ingredients. Those are already enough once you have your connection established to a specific printer, but to achieve that, you need some initial steps, too.

Item #0 — Discovery

Once upon a time, there was no outside help. You connected your printer directly to your computer, and before the proliferation of unified operating systems like Windows, Linux or macOS, there was no universal support for printing, either. Each application needed to generate the print data itself in order to support various printers. First Epson with dot matrix printers, then Hewlett-Packard with laser ones, this usually meant PCL, ESC and maybe, for programs with more sophisticated printing needs (think about early graphics and desktop publishing) PostScript. Back then, PDF was not yet a thing — it only came later and remained a closed, proprietary format for some time.

The arrival of Windows and Mac made it possible to make printing universal among the applications: if the operating system knew how to print, applications could use its services to prepare and send what to print. This was the time when printer drivers first appeared but you still had to set up your printer the old way, you connected it, you knew the format, you offered the driver that came with it to your operating system.

The thought of making this easier was there from the beginning but even if the printer could identify itself somehow, the operating system could only arrive with so many printer drivers and once deployed, there was no easy way to add more or to replace old ones if bugs were found and fixed by the manufacturer. It's not suprising that real attempts at automatic printer identification and setup only became feasible with the spread of universal internet access — what meant not only widespread access to new drivers but also masses of less experienced users.

Printer discovery was even then obvious with a direct connection like USB, but other, network based scenarios really need something where the host can just ask "who can print around me?" and the printers can reply "I can and look, these are my parameters to do so".

Just like with all the above, you have quite a few competing solutions and neither one is inherently much better than the others. There are "zero configuration" options like ZeroConf, Bonjour, Avahi, UPnP, WSD that all rely on the host sending out standardized query packages over the network, with devices replying back if they support the service in question. They use different addresses, ports and message formats (with additional names and abbreviations like mDNS, DNS-SD, SSDP, WS-Discovery), but they all do essentially the same. Also, larger share systems like IPP/CUPS on Linux and Samba on Windows have their own mechanisms to share devices. Wireless, local WiFi Direct and Bluetooth just as well (but internally, no surprise, they use the same network discovery solutions as above).

How this all comes together

You have two basic scenarios. If you have a relatively modern printer in a contemporary environment, chances are it understands one of the modern, bitmap-based, therefore "driverless" formats and also responds to the standard discovery requests. These will be Mopria (PCLm), IPP Everywhere (PWG) or Apple (Airprint). These are completely equivalent in capabilities, so whether a particular printer supports one or all of them is purely a marketing decision, nothing else. If they want to lock you into one ecosystem, they can, but they can just as well allow you to use all of them. At any rate, your host computer or mobile device will ask for the printer, they will reply back, you will send one of these modern formats, and that's all.

In this scenario, you probably won't need the services of NetPrinter, modern Android already has this built-in. But you still might find the app useful if the printer manufacturer forces you to subscribe to some unnecessary cloud service in order to just print. Besides, it has way more features that just plain printing...

But if you have an earlier printer or more complex networking layouts, you'll have to identify each of the solutions supported from the three ingredients. The printer determines all of that: the format understood is obvious — it can only accept what it can process. It might have a network (Ethernet or WiFi) or some direct physical connection (this used to be parallel or serial, USB these days). A direct connection doesn't leave room for any protocols but if it's network capable, it will provide at least RAW but usually a bunch of other protocols as well.

However, a direct physical connection can be connected to a device that offers up the printer for the whole network: this is what print servers do. These can be dedicated devices (they connect to the network and have output connections for one or more attached printers), can be part of a network switch or router (these orchestrate the network traffic themselves but can offer an USB connection for printers), or you can use a computer connected to the network to act as one (actually, NetPrinter itself offers this functionality in its server mode).

To make that task less daunting, we have quite a few resources to help you with. Apart from the discovery built into the app itself, that really tries everything possible to discover, locate and identify your printer, you also have detailed set up guides (or a quick one just for advanced users), as well as a format selector that helps identify your printer's format by manufacturer and model.