Written a shell-script to better handle your printer, because nobody has.
It’s just one horrible idea to interface with printers from Linux in general. EPSON, the company whose eponymous printer (as seen above) is currently used in my household, made an up-front statement in its manual page: Epson does not provide support for Linux drivers. The closest to their support is EPSON’s driver, and epson-printer-utility - a barebone app made in QT4.
Yet, this still pales in comparison to its Windows or Mac counterparts in terms of execution. On Unix, we must refer to CUPS (Common UNIX Printing System), a collection of utilities open-sourced by Apple (surprise!) that in theory should aid me and those in need. If only it was so easy.
After CUPS, I figured out how to manage print jobs through shell (a.k.a. through commands), albeit was devastated (and lobotomized) by a lack of out-of-the-box features. It wouldn’t be until a few more days, having recoursed to Foxit and relived the nuisance of switching to Windows due to urgent demands, that I was persuaded to write my own shell script.
I first lobbied for a proper personal printer in early 2019 during my time prepping for the high school entrance exam. Before this, half of my time would be delegated to cycling 15 minutes to a printer’s, back and forth. Not to mention how my bad memory would aggravate the situation once in a while: I’d leave my USB behind at the photocopy shops, or that the files would get printed incorrectly. As the print load increased over time, it was high time that I deserved an upgrade.
Even thereafter, hardly was printing efficient. Having perused the machine for months, it is still common of me to get it wrong: incorrect format, incorrect layout, ink getting “stuck” mid-printing so the whole job must be restarted,… Soon enough came piles of leftover sheets, half-inked from failed attempts. For a while, I entertained the pitch of a paper recycler. Took it quite seriously, even downloading, and attempting to digest, a research paper on various methods of de-inking, but which I never finished. Three years have passed, and everything has settled with Foxitreader on Windows 10 functioning as intended. Today, my saga with the printer continues, on Ubuntu.
Not all printers support duplex (double-sided printing) by hardware, especially the budget ones. For mine, the EPSON L3110 (which was bought in 2019 but whose origin dates back to the years of Windows XP), the workaround exists in the software. The machine would start the first pass by printing on one side of each sheet - all of which could be from odd-numbered pages for example. The user would then manually flip and reinsert the half-printed sheets so that the other side could be filled with even-numbered pages. This method is not available in CUPS, at least by default.
CUPS is more of a management utility accessed through localhost, a terminal for viewing the queue, plus some admin controls, and whatever settings your printer’s company has to offer. Printing requires control beyond such as you set up your targeted document or image. At that end, you’re still at the mercy of the corporates whether your Linux distro is supported, otherwise not much about your printer appears on CUPS.
On Windows, there need no CUPS where good applications (Acrobat, Foxitreader,…) is a given, or else companies would have lost their only demographic. Just for contrast, beside is the same Epson utility program on Windows. On the opposite end of the spectrum, that is Linux, you have Foxitreader crashing every 10 seconds I entered. Evince barely cares about your need, and neither does Okular. Unless your printer supports full duplex, the default offer is impractical in most situations.
I was first inspired by a project on Sourceforge; unfortunately, it was of little assistance. So far I’ve written the basic functionalities for basic two-sided printing, like defining a range or an option to examine the output by queuing a test job of some initial pages. These are simple enough, but I’d like to go beyond that, at least beyond the confines of shell. Not that it isn’t capable of basic math, but working in shell script is just tedious: not impossible, but involved: deprecated syntax reminiscent of the age of Pascal, stream-editing, documentation here and there but you can’t go on splitting hairs with the syntax forever - but which I’ve been obligated to. The more I dig into shell, the further I walk back to the history of computing. Our lives should get easier, not harder.
Since I’ve taken the matter into my own hand, perhaps there’s more light at the end of the tunnel than what I anticipated, as in the process I’ve developed more programming skills, specifically in furnishing my code. Still, it remains to be seen whether any of my effort will pay off. For now, I dread having to fiddle with shell script ever again.
P/S: Discovered a bug on my site during the uploading process, so I must set the date no further than August. I’ll look into it after having recovered from the days working in shell.