Some Assembly (and/or Compiling) Required: Epson, Linux, and the ongoing quest for Windows 10

epson100_4596

Despite being “mostly retired” here at Chaos Central, we are still heavily dependent on our computing resources.  Unfortunately, that also includes having at least one working copy of Microsoft Windows, in addition to a plethora of iOS devices  and the workhorse stable of Linux machines and servers.  Of course, the complete enterprise also includes a collection of paper-handling implements, like printers and scanners.

We’ve had a succession of laser printers since the early 1990s: an HP LaserJet2, replaced after 10 years with a LaserJet 1200, and in this century by a succession of Xerox Color Phaser printers.  The latest, a 6500, is on its 3rd set of cartridges.  A set of four “Genuine Xerox” high-capacity cartridges runs just slightly more than the retail price of a new printer, i.e., about $450.  As semi-retirees, that just won’t quite fit the budget, so we tried a 3rd-party set, priced at under $100, which has resulted in faded, muddy colors, absolutely unusable for business purposes, but more or less OK for printing recipes and mostly black-and white documents.  Lessons learned.

We also have gone through a progression of inkjet printers, mostly HP, a Lexmark or two, all with the same marketing principle: the ink costs more than a new printer.  Nevertheless, we keep feeding cartridges into them until they die or can’t color inside the lines anymore.  We currently have several in that condition: since most printers these days combine the functions of printer with scanner, copier, and FAX machine, we have long since consigned our dedicated scanners and FAX devices to the recycle pile.  We gave up our hard-wired telephone connection several years ago and second phone line with the demise of dial-up Internet access, so FAX, for us, is a relic of the 20th century, but the feature seems to come combined with the scanning function.

We do keep the old partially-broken devices around for scanning, though, and even bought a portable scanner to pack in the “on the road” system.  At the office, we used a Raspberry Pi as a scanner-server, to put one scanner on the network, accessible by other Linux systems.  The last of the inkjet printers failed, and with the laser printer quality not suitable for work, we were in the market for yet another inkjet.  Costco had an Epson multi-function system on sale, so it somehow slipped into our cart when we went shopping for bagels and dates, along with a book or two.

Out of the box, the new printer is our first wireless system, and the first Epson since the pin-feed dot-matrix days in the 1980s.  Setup was fairly straight-forward, and, since we have the Windows system we are trying to upgrade, we set that up first.  Despite taking “nearly forever,” that went fairly smoothly, and printed out a test page, because everything is designed to work with Windows: the install program comes on a CD in the box, after all.  The delays were certainly due to all of the updates being installed, not the least of these was the device driver for the new graphics card we hope will convince Microsoft to send us the Windows 10 update eventually–the upgrade status still says, “buy a new machine.”  We might have to wait another month for the update assessment to rerun and detect the driver and/or hardware–unless it has permanently written off our “new” old machine as hopeless.  But, I digress–back to the issue at hand, installing a new printer…

Linux was another issue:  manufacturers don’t publish drivers on their sites, but, thanks to the Common Unix Printing System (CUPS), used by Apple and all other Unix system vendors, Postscript Printer Description (PPD) files are available for almost every printer immediately after it goes on the market.  CUPS is Open Source, and the PPD files are essentially text files describing the printer features and settings (i.e., the “device driver,” a systems term that means the program or collection of functions that understands how to control the hardware device), so it is easy for Unix/Linux vendors to write their own setup systems, and for anyone familiar with the printer specifications to modify the driver to suit themselves, using setup programs they have written.  Of course, one can also modify the driver directly in a text editor, or via an existing setup program, and there lies the crux of our tale…

When I installed the Linux driver package (which essentially just installs the appropriate CUPS configuration file), the test pages and subsequent printouts were faint, with pale colors and grayed-out text.  Whoa!  I knew immediately that this was a function of the PPD file, because the Windows test page and the self-generated status printouts from the printer were normal, sharp, black on white.  A Google search quickly revealed a partial solution: set the print density to “High,” and gave a step-by-step procedure using the Gnome “system-config-printer” graphical printer administration tool.

On my primary system, I ended up opening the configuration file in a text editor (when you have the Source, use it) and selecting the “Normal” print density, rather than “High,” noting that whoever submitted the PPD file to the CUPS repository had left the print density setting in “Draft,” hence the faded appearance.  One could sympathize with the developer for testing in “Draft” mode to save ink, but the final step should be to reset to “Normal” and retest, as a courtesy to users who are not system developers or administrators, and to the Epson help desk, who won’t have a clue how to solve this problem.  In the Linux help forum article I found, the user had contacted Epson, with the usual ineffective “help” rendered to Linux users, which is usually less useful than the ineffective help rendered to users of closed systems like Windows, iOS, and OS/X–they were told to reinstall the driver, update the driver (i.e., download a fresh copy–of the one you just downloaded), and buy the special Epson paper. None of these “fixes” addressed the underlying problem: the driver default settings were simply not what most people wanted, and the settings were not intuitively obvious, but buried several layers deep in the configuration and used obscure descriptions.  Here’s what the file (the pertinent 9 lines out of 1200, anyway) and the graphical utility look like:

*OpenUI *MediaType/Media Type: PickOne
*OrderDependency: 20 AnySetup *MediaType
*DefaultMediaType: PLAIN_NORMAL
*MediaType PLAIN_HIGH/plain papers-High: "<>setpagedevice"
*MediaType PLAIN_NORMAL/plain papers-Standard-Vivid: "<>setpagedevice"
*MediaType PLAIN_DRAFT/plain papers-Standard: "<>setpagedevice"
*MediaType PLAIN_SUPERDRAFT/plain papers-Draft: "<>setpagedevice"
*MediaType LETTERHEAD_HIGH/Letterhead-High: "<>setpagedevice"
*MediaType LETTERHEAD_NORMAL/Letterhead-Standard-Vivid: "<>setpagedevice"

The original setting in the /etc/cups/ppd/WF-3640-Series.ppd file was “PLAIN_DRAFT.”

In the Gnome system-config-printer utility, the Media Type is set in the “Printer Options” screen, down in the middle of a menu, between what might be interpreted as “extremely advanced” and “void your warranty.”  Of course, “plain-papers-Standard-Vivid” doesn’t really translate to “NORMAL” in the minds of most users, unless they ignore the “Vivid” and assume “Standard” is what it means.  Programmers don’t often think about what gets presented to the user or how the users will interpret what they present.

system-config-printer "Printer Options" window on Linux Mint 17 MATE desktop
system-config-printer “Printer Options” window on Linux Mint 17 MATE desktop

The next issue is getting the scanner to work on Linux. For this, it appears, even though there is an iscan package available for “Network” connection, the printer/scanner itself does not support this: the device needs to be connected to a computer via the USB connection. Since our now preferred network appliance building tool is the Raspberry Pi computer, and the utilities and drivers are only packaged for RedHat-Fedora-CentOS and Debian-Ubuntu-LinuxMint variants, it is necessary to build the software from source. Of course, in both the binary packages and the source configuration files, some, but not all, the prerequisite packages and libraries are checked in the pre-processing, so the build process is a trial-and-error affair, tracking down and installing missing packages and header files (-dev or -devel packages for the libraries).

So far, an afternoon of trial builds has come up against a brick wall, finally, with at least one more library version to track down.  And, even if it does work, there is no guarantee that the Iscan system plays with the Xsane server software we currently use to provide network scanning services to all the Linux computers from one scanner.  However, the new Epson multi-function machine will scan directly to PDF and write onto a USB drive or SD memory card, which may be a better groupware solution than the user moving back and forth from the scanner to his or her workstation between pages.  The old HP scanner only produced image files (PNG or JPEG), which had to be embedded in a document file using LibreOffice or Scribus to convert to PDF.

So it goes, just another day at Chaos Central.   Always a new way to do old things, and problems to solve just to stay in one place.  After we got back from Idaho last week, the fan on my big laptop wouldn’t spin up, so it shut down from overheating.  I pulled the back off, spun the fan by hand, blew in it to see if it spun easily, wiggled the wires; did this a couple times, and it started working.  Naturally, we had to go out and buy something new to break in…