And sure enough, this works! Just tested on my new printer.
Edit: added footnote
1. The chief maintainer - not the only maintainer, between 2007-2019
extension link: https://chromewebstore.google.com/detail/Read%20on%20reMarka...
On macOS I think it either recognized my printer or I had to select it from a list. I don't remember which for sure. It was a few years ago.
On Linux my Brother printer is not on the list. Brother offers a deb and rpm packages which may be obsolete for all I know. Then you have to install it manually. But in my case it never offered double sided printing.
For years I am using a crutch in terms of Android driver and Brother's own app. This despite being offered by the producer doesn't offer double sided printing either. It doesn't even give ability to print in grayscale.
I don't know what lifting "real" is doing here, but lpd(8)[0] (line printer daemon) is what we used to use, and printcap(5)[1] to configure. It was general enough that you could make a music playlist system out of it[2].
[0] https://man.netbsd.org/lpd.8
[1] https://man.netbsd.org/printcap.5
[2] https://patrick.wagstrom.net/weblog/2003/05/23/lpdforfunandm...
They claim that modern printers implement IPP and that should be the preferred protocol for printing. In IPP, printers advertise capabilities and are able to handle different high-level printing requests.
cupsd[873]: Printer drivers are deprecated and will stop working in a future version of CUPS. See https://github.com/OpenPrinting/cups/issues/103
You are (like so many other people) confusing IPP the protocol with IPP the driver, which is honestly not your fault and a terrible naming mistake.
And like you mentioned, people have way older printers because if all you do is print monochrome and mostly text, a printer from 2004 doesn’t lack much aside from AirPrint / Mopria. Which is why I suspect CUPS will not deprecate at least PPD drivers.
So yes, CUPS itself will only support IPP without any printer-specific driver. Since mobile phones also only directly support IPP this sounds like a reasonable decision.
Ah, yes. Thanks for pointing that out! I wonder how much more secure that will make things for those who have to use legacy printers.
> Since mobile phones also only directly support IPP
Technically AirPrint is not IPP Everywhere, they use a different raster format and some different glue. For example my Brother printer supports AirPrint but fails ~50% of the IPP Everywhere self-certification tests. But that’s splitting hairs.
> As for printer drivers, those few printers that "need" them can migrate to standalone applications/services using the CUPS API to provide an IPP Everywhere-compatible Printer instance. PAPPL provides a convenient framework for easily creating these applications and porting existing CUPS raster drivers, and the following printer applications are already available or (in the case of Gutenprint) under development:
[...]
> ps-printer-app: PAPPL-based PostScript printer application that supports all CUPS/PostScript printers via PPDs and includes all of the Foomatic and HPLIP drivers.
So drivers will still be supported in a sense, just not directly by the CUPS daemon.
If you install the specific driver it generally should have parity with their Windows / macOS driver though.
But you should in theory also be able to do this without any Brother-specific driver since pretty much all modern printers speak IPP for mobile device compatibility.
Very much IS there in the background.
See http://localhost:631/printers on your OS X machine.
> Web Interface is Disabled
> The web interface is currently disabled. Run “cupsctl WebInterface=yes” to enable it.
But I cannot remember if I disabled that.
Its ok, you're not going mad. ;)
They disabled it by default as part of security hardening a few releases back. Probably around the same time they stopped shipping PHP and other stuff.
CUPS is still running the printing in the background, its just the web UI that's been disabled. IIRC.
"You're overwhelmed, Freeze was underwhelmed. Why isn't anyone ever just whelmed?" https://youtu.be/UdBcnRFN4Vg
https://support.brother.com/g/b/midlink_productcategory.aspx...
What's perhaps more surprising, my macbook had an inbuilt driver for generic epson printers and it worked. It was not very good, it printed as graphics but it was there for some reason.
Not sure about modern inkjet and laser printers though. An inkjet Epson I used to have once did support raw ESC/P codes though, but it was 20 years ago.
It's similar to the terminal emulation situation: despite being decades old, the VT100 has become a de-facto terminal command set due to its popularity.
Once you've established that you can print basic text, you can expect that the printer's escape codes will work.
It's probably expecting ESC/P or PCL. Laser printers also usually wait for a formfeed before they will process a page.
[0] I'm assuming PCL is most likely supported, and I remember having worked with an EPSON dot-matrix printer (i.e. probably using ESC/P) in 8-bit days and that it didn't require special commands to print basic text.
It would be possible to write a PostScript program that emulates ESC/P (or PCL), although then you would have to send an entire page (or a page break) before the page would be printed, unlike the old dot-matrix line printers that you can print one line at a time, PostScript can only print one page at a time.
That buffer could have several random programs' outputs in it, all just dumped as simply as possible to /dev/lp0 (or lpt1 or whatever), and it works.
A LaserWriter can't do these things.
You could usually set a timeout to eject the page if no data had been received for a while.
>A LaserWriter can't do these things.
The LaserWriter could emulate a Diablo printer which would do the same thing. It wouldn't accept PostScript then though.
https://retrohacker.substack.com/p/bye-cups-printing-with-ne...
PDF includes pretty much all the printer needs, like pagesize, colour palette, font information, etc.
It's not the greatest format in the world... But everyone can shove in one of dozens of PDF parsing libraries without a lot of effort. So it happened.
I can't attest to whether piping directly to the device works, but I routinely do stuff like
lpr -o raw -P $SOME_CUPS_PRINTER < $SOME_FILE
More recently I dusted off that particular skillset in order to print a bunch of labels for my kitchen. ZPL really ain't that bad of a language; sure beats trying to write PostScript or PCL by hand :)
https://x.com/normankev141/status/1146547923758538755?t=oZrj...
text of tweet: So I bought a networked printer recently and as you do decided to try connecting to it a few different undocumented ways. I tried telneting to it. It turns out that whatever you type, it prints typewriter style. That was a pleasant and hilarious surprise. #internetofshit
> So, if I plug a USB printer into a computer, and ls > /dev/usbXXX, will it print today? Does that still "just work"?
Both of the following worked for me:
printf 'hello\f' > /dev/usb/lp0
printf 'hello\f' | nc -N $printer_ip 9100
Neither of the above involve CUPS. Using the `lp`/`lpr` executable like in other comments requires the printer to be registered with CUPS first.
For `ls >`, the printer expects DOS line endings. `\n` just moves to a new line without "returning the carriage", so you need to pipe through `sed 's/$/\r/'` or use `nc -C`.
With the USB connection, you can print multiple times to build a single page and it won't come out until you provide the form feed. With the TCP connection, the page will be printed when the connection is closed.
In modern Linux distros, lp/lpd are usually shims provided for backward compatibility, but it doesn't have to be that way. For example FreeBSD seems to provide support for lpd without for cups [1], although I don't see any real advantage in doing that.
The software on their website was a Windows executable .exe file that seemed outdated even 10 years ago. To complete the last few steps, the printer network connection had to be set up once again, even though I had already previously connected it. Each attempt would take around 10-20 minutes, only to fail. The network errors and troubleshooting steps were incredibly generic and unhelpful. The worst part, until that point, was that the printer shipped with outdated firmware, and I did an online firmware update via the printer itself, confirming that the printer's Internet connection had indeed already been established. Rebooting the printer did not help. It turned out that, despite only just downloading the Windows executable that same hour from the Epson website, they were shipping an old version .exe, with some bug that causes the network setup to not be detected. However, it never prompted me to update. Only after restarting the Windows computer, and then re-opening the .exe, did some update trigger, and it allowed me to finish setting through to the last step of the installer to download the rest of the bloat and let the printer appear in the list of available printers on the network on the computer.
I then did a test print via an iPad. Took about 15 seconds.
For PostScript printers, there was a filter application (provided by Adobe) that would turn plain text (without the %! magic) into PostScript.
$ sudo apt-get install cups-bsd
Many commented that it still works... This brought back good memories of sending native PostScript files to an HP LaserJet 4M+'s IP address, over the LAN, using netcat. Amazing stuff.
The gotcha of course is when the shit hits the fan: it can quickly degenerate into pages upon pages of garbage getting printed.
On the plus side back when things were, and still are, simple like that, typically just turning the printer of and terminating the command and you'd be good to go. As opposed to, say, weird spoolers/cache sometimes relaunching print jobs people thoughts were long gone.
This is still a thing... I was setting up a modern Brother laser printer in FreeBSD (Brother only supplies Linux "PPDs" which run a bunch of binary blobs with Ghostscript and weird stuff) and figured it was easy enough so I did it remotely. Could only watch helplessly on the security camera as the printer spit out every page in it's paper cassette covered in junk... Remote stop commands did nothing.
For those who want to look into the horse's mouth, USB printing device class:
https://www.usb.org/sites/default/files/usbprint11a021811.pd...
"Printers have two different types of commands: those that transfer data, and those that control the USB interface or printer interface. The host prints something on a printer by delivering data on the Bulk OUT endpoint. This data may take the form of PostScript, HP PCL, or any other PDL. This data may also be encapsulated in a PCP, such as IEEE 1284.1, or something that is vendor-specific. In addition, the data may also be simple text, or it may be a proprietary PDL."
The rest of the spec makes it very clear that this is intended to work exactly like a standard parallel port at the "application layer". Use the bulk OUT endpoint to write data to the printer, and the bulk IN to read data from it. There is a status request that returns the same signals (out of paper, etc.) that a parallel port has.
If I do that with an EPSON and send it EPSON MX-80 escape codes -- does it still work?
ESC/P and ESC/P2 which followed are backwards-compatible and based on the MX, so likely yes.
One of the things that this person does is simply echo to /dev/lp0.
Which is all you did back in the day. Shove text down the interface, and the printer printed.
Now, while we have very fancy modern printers, they're still printers with a long legacy. Even back in the day, early HP laser printers worked like this. Shove data down the wire, and it printed (Courier 10, 66 lines per page). Only the Apple Laserwriter didn't really do this (I don't think) because it was an exclusively PostScript printer. Instead, you shoved PostScript down the wire.
As the printers evolved, the language that was sent to them got more complicated. But even so, they still had a long line of backward compatibility.
So, if I plug a USB printer into a computer, and ls > /dev/usbXXX, will it print today? Does that still "just work"?
If I do that with an EPSON and send it EPSON MX-80 escape codes -- does it still work? It wouldn't surprise me either way, but I'm just curious if someone knows. They're very black boxy today (to me anyway).
(Anyone else remember the joys of getting reports to fit on pre-printed, multi-copy NCR forms? What fun that was!)