Fixing broken CAPT printing after ICU update

The setup

We are still using my wife’s old Canon LBP6300dn - it’s old, but it’s a laser printer, we have one backup toner in reserve and I can’t justify buying a new printer when this one works fine.

The printer is connected to our home network and a CUPS server running Arch Linux shares that printer to all other devices, so I don’t have to install old printer drivers on every device that wants to print.

Unfortunately, these printer drivers are so old that they work only with old 32-bit dependencies as far as I know and have researched. That includes stuff like libxml2, as it not only needs to be 32-bit, but also the legacy version 2.13.

For these purposes I used the lib32-libxml2-legacy package, after a update to libxml2 version 2.14 or 2.15 broke printing.

The problem

This workaround with lib32-libxml2-legacy worked so well and without problems that I completely forgot about it. After a server update a few weeks ago, I noticed that printing wasn’t working although I got no error messages in CUPS.

The error was only visible when trying to manually invoke some of the filters provided by the capt-src AUR package. This package compiles and installs the Canon Linux printer drivers for our model and provides a custom daemon for communicating with the printer using the proprietary CAPT protocol from Canon and translating that in a way that CUPS can use this printer.

So, when running something like captmon, I got the following error message:

libicuuc.so.76 not found.

That’s it. Not very helpful. Reinstalling capt-src did not work and I didn’t see a quick way to install icu76. I let that problem rest for a few days.

The red herring

Today I looked into the printing problems again and installed icu76 from the AUR, but that did not solve my problem. I looked at ldd /usr/bin/captmon and sure enough, the library was still missing. I then noticed that all shared libraries are 32-bit variants and thought I’d have to somehow provide that.

So I went ahead, downloaded multilib/lib32-icu from the ABS, adapted everything to build version 76.1 and built the package.

Only then did I wonder “what actually depends on lib32-icu?” and looked at what pacman -Qi lib32-icu gave me: lib32-libxml2-legacy.

This whole lib32-icu76 endeavour was a red herring. Grepping through the source of the printer driver, that made sense: icu is never used directly anywhere in the source, but libxml2 is.

The actual solution

I rebuilt the lib32-libxml2-legacy package, installed it and checking ldd captmon verified that it now needed the 78.2 variant of icu and that it found this library in the /usr/lib32 directory.

Restarting CUPS for good measure and printing a test page then verified that the printer works once again!

Conclusion

Printing on Linux with old printers is going to get more and more difficult, especially if they are using proprietary protocols like CAPT and don’t support stuff like AirPrint or IPP Everywhere.

Sometimes, I’d really like to get another laser printer that has something like that, but then again: we maybe need to print 20 pages a year. Our current toner is still far from running empty and we still have that backup toner! Spending money on a printer just to configure it more easily seems silly to me.

Nevertheless, the driver situation is starting to worry me. Who knows how long I can coax the proprietary drivers into working well?

I looked into captdriver, as it sounded promising, but it seems that I’d have to reverse engineer the CAPT communication between my server and my printer to add the required operations to that. I might do that as a side project, so maybe I won’t need to have those proprietary drivers anymore.

For now, I’m happy that this problem is solved - at least until the next lib32-icu update.