Enabling my label printer on bluefin

[murphym18]

Hi, I'm not sure if there is any chance of this information leading to a change in bluefin 🙂. But I ended up layering two packages in order to get my label printer to work:

foomatic
ptouch-driver-foomatic

Anyways, these two packages are FOSS and available in the fedora repos.

I have a Brother QL-800 Label Printer, and all my printer troubles went away once I layered these packages (and did a bit more afterwards).

I'm thinking I'll keep these packages layered and hope for the best when bluefin 45 releases. Of course, I can always remove any extra layers in case of trouble.

And if keeping these packages around seems impractical, then I was thinking I could create a Debian LXC with the equivalent printing packages. Linux handles network printing really well it seems. So I could probably do USB pass-through with incus, and configure bluefin to print to a networked printer.

Anyways, I thought I'd share, in case my solution can help anyone else trying to use a brother label printer on bluefin. 👍

EDIT: To get the QL-800 printer to work There's a bit more to do beyond installing these packages. I documented what I did here: #4949 (comment)

[murphym18]

Here's some detailed information about these two packages:

foomatic-4.0.13-35.fc44
License: GPL-2.0-or-later
Packager: Fedora Project

ptouch-driver-foomatic-1.7.1-3.fc44
License: GPL-2.0-or-later
Packager: Fedora Project

[murphym18]

I wanted to share a bit more detail about how I got the Brother QL-800 label printer to work on Bluefin. This post might be a bit meandering.

I ended up layering the two packages mentioned previously:

foomatic
ptouch-driver-foomatic

ptouch-driver-foomatic contains the Foomatic database definitions for Brother P-touch/QL printers. It also pulls in the actual ptouch-driver CUPS raster driver as a dependency. When setting up the QL-800 or a similar brother Label printer, these packages make the proper driver available, but there's more to do.

At a high-level, I needed to:

1. make sure CUPS was using the right driver and PPD.
2. allow the use of my printer (this is for security)
3. change a few printer settings.

First, I needed to check which driver CUPS was using for my printer. I looked for a .ppd file for my printer in /etc/cups/ppd/

ls /etc/cups/ppd/

I found QL-800.ppd.

Generally, CUPS stores the PPD associated with an installed printer as: /etc/cups/ppd/<queue-name>.ppd.

From there I used grep to see what printer driver CUPS was using:

sudo grep '^\*NickName' /etc/cups/ppd/QL-800.ppd

I got this output:

*NickName: "Generic Text-Only Printer"

This indicated that CUPS was using the wrong driver (Generic Text-Only Printer).

But I installed foomatic ptouch-driver-foomatic so the correct drivers were available. I found them by running:

lpinfo -m | grep -iE 'QL-800|Brother.*QL'

Here's a quote from the lpinfo man page:

lpinfo lists the available devices or drivers known to the CUPS server. The first form (-m) lists the available drivers, while the second form (-v) lists the available devices.

Within the output I found this:

foomatic:Brother-QL-800-ptouch-ql.ppd Brother QL-800 Foomatic/ptouch-ql

This shows that CUPS now has a suitable QL-800 driver available, specifically, foomatic:Brother-QL-800-ptouch-ql.ppd is available.

So I reassigned the existing QL-800 CUPS queue to use that driver. Here's how:

Find the device URI for your printer:

lpstat -v

This will show the printers that CUPS can drive. In the output I found:

device for QL-800: usb://Brother/QL-800?serial=000XXXXXXXXX

Note: the string 000XXXXXXXXX is a placeholder. You're printer will have a different serial number.

Now run the lpadmin command to change the driver. You'll need to specify the printer's URI and the name of the driver from earlier:

sudo lpadmin \
  -p QL-800 \
  -v 'usb://Brother/QL-800?serial=000XXXXXXXXX' \
  -m 'foomatic:Brother-QL-800-ptouch-ql.ppd' \
  -E

The -m option selects the driver/model, while -v sets the device URI. CUPS documents lpinfo -m as the way to list available drivers for use with lpadmin -m.

This command caused /etc/cups/ppd/QL-800.ppd to be regenerated for the QL-800 Foomatic driver.

I could verify the results by running:

sudo grep -E '^\*(NickName|ModelName)' /etc/cups/ppd/QL-800.ppd

I saw this output:

*ModelName:     "Brother QL-800"
*NickName:      "Brother QL-800 Foomatic/ptouch-ql (recommended)"

Now for the homestretch!

Next, I needed to "allow" foomatic-rip to use the PPD for my printer. Why did I need to "allow" the use of the PPD? Basically, Foomatic PPDs can contain shell commands that foomatic-rip executes. Because a malicious PPD could abuse this, Fedora changed foomatic-rip so it refuses to execute any commands unless they've been explicitly allowed. The historical context is documented at fedoraproject.org/wiki/...FoomaticRipRejectsUnknownValues...

Here's how to "allow" foomatic-rip to use your printer's PPD. First, you'll need to run the foomatic-hash tool. This tool does two things. It creates a file for you to review. This file shows you what foomatic-rip will execute. It also creates a hashes file that foomatic-rip can read. This hashes file identifies some commands that foomatic-rip is allowed to execute. If you want to allow your computer to use your printer, then you'll need to copy the hashes file into the directory: /etc/foomatic/hashes.d/.

Here's what I ran:

cd /tmp
sudo foomatic-hash \
  --ppd /etc/cups/ppd/QL-800.ppd \
  ql800-review \
  ql800-hashes

This foomatic-hash command creates two files:

1. ql800-review (this is a human-readable file)
2. ql800-hashes (this is a machine-readable file for foomatic-rip)

I looked at ql800-review and everything looked fine. So I opted to allow the use of my printer by running:

sudo mkdir -p /etc/foomatic/hashes.d
sudo cp ql800-hashes /etc/foomatic/hashes.d/ql800

After that, the QL-800 was mostly working.

I did run into some minor settings issues. The driver was using the wrong media type, so I changed it to labels:

sudo lpadmin -p QL-800 -o MediaType=Labels

Before making this change, the printer's red error light would blink whenever I'd try to print a label.

I also opted to change the "Print Quality" to Fast:

sudo lpadmin -p QL-800 -o PrintQuality=Fast

But this is a personal preference. The default value of PrintQuality=High also works, but it's slower. To be honest, I didn't see much difference in quality.

Note: This setup uses the legacy CUPS PPD/driver model. CUPS currently supports it, but PPD-based printer drivers are deprecated. This guide therefore describes a working Fedora/Bluefin setup as of Sept 2026... But changes are coming. Linux printing is evolving. I hope to share more about that later.

[murphym18]

@castrojo I've been doing some research into the maintenance implications of adding these packages to bluefin.

After getting this working, I'm less convinced that adding Foomatic and legacy printer drivers to the Bluefin image is the right long-term solution. But it might be a good present day solution. The current setup works, and it's likely going to work for the time being. But it relies on CUPS's deprecated PPD/filter driver architecture. This now requires auditing and allowlisting Foomatic commands. The end user experience is kinda messy. (My previous post probably gives a directionally representative picture of what the user goes through)

OpenPrinting's intended replacement appears to be Printer Applications. These are printer-specific services. They expose a standard IPP interface to CUPS over the network while keeping the messy specifics outside of CUPS itself. The problem is that these printer applications don't exist yet (for fedora), so the most straightforward solution is to layer these packages. (this adds maybe 642KiB for foomatic and 215KiB for ptouch-driver-foomatic). (Side note: there might exist an experimental Printer Application that supports the Brother QL-800 label printer. It's a snap. See: snapcraft.io/lprint and www.msweet.org/lprint/).

Still, I'm thinking the best future solution for bluefin is to have end-users deploy Printer Applications as podman quadlets (if this ever becomes possible). That way, Bluefin's image could remain driverless. Basically, the host could access all printers using IPP Everywhere, AirPrint, or driverless IPP. And as of now it's looking like there are gonna be two common types of Printer Applications. Some will be native Printer Applications, where somebody takes the "legacy" driver and ports/wraps it cleanly using PAPPL. The other way is less clean... like putting some crusty service inside a container and exposing a clean HTTP API 🤣. The internals may still be crusty (they will still run the CUPS driver and filter code), but the host doesn't need its dependencies (so this is still an improvement).

The other problem is that there are certain printers that are holdouts. These holdouts are modern enough to still be sold brand new, but they don't implement driverless IPP. OpenPrinting specifically notes label printers as common holdouts. They don't implement IPP Everywhere-style printing. In addition to label printers, certain industrial and vertical printers are common holdouts too. These printers still have FOSS drivers and they still work great on Linux.

If you're still open to adding foomatic and ptouch-driver-foomatic, then it might be a good idea to add a comment linking back to this post... I think one day (probably years from now) these packages are going to stop working. When that day comes, it might be best to just drop them from Bluefin. 🙂. To the best of my knowledge, these are rather minuscule and benign packages. They will help anyone trying to use a brother label printer. Otherwise they won't cause any issues to anyone else except for taking up a tiny amount of space.

Anyways, I'm really no expert in these matters, and I'm still learning. So I'm very sorry if I messed up any details.

Edit: here are a few reference links:

• Tutorial and Design Guidelines for Printer/Scanner drivers in Printer Applications
• OpenPrinting - Our principal achievements This article is super cool! It covers the history of printing on Linux and it provides so much context for why things are they way they are. 😄

Also, I've been updating this note as I find more information. I added that link to lprint. I re-worked some phrasing, and grammar.

[castrojo]

The problem is that these printer applications don't exist yet (for fedora), so the most straightforward solution is to layer these packages.

We have an entire factory now we just need to know what to package.

[murphym18]

So I got the QL-800 label printer to work using a quadlet. The OpenPrinting folks have made a Printer Application that wraps the existing foomatic and ptouch-driver-foomatic code (they threw the legacy drivers for many other printers in there too).

So I think there's maybe a path forward where nobody needs to layer anything in Bluefin to support legacy printers, or label printers like the QL-800

Here's my quadlet ghostscript-printer-app.container file:

[Unit]
Description=OpenPrinting Ghostscript Printer Application
After=network-online.target
Wants=network-online.target

[Container]
ContainerName=ghostscript-printer-app
Image=ghcr.io/openprinting/ghostscript-printer-app:latest
AutoUpdate=registry

SecurityLabelDisable=true

Network=host
Environment=PORT=8000

Volume=ghostscript-printer-app.volume:/var/lib/ghostscript-printer-app
Volume=/dev/bus/usb:/dev/bus/usb:ro
PodmanArgs=--device-cgroup-rule="c 189:* rmw"

[Service]
Restart=on-failure

[Install]
WantedBy=multi-user.target

Here's the associated ghostscript-printer-app.volume file:

[Volume]
VolumeName=ghostscript-printer-app

I needed to run these as root-full containers because they access USB devices. I also needed to disable security labels, since the container needs access to my USB printer and I don't think it's a good idea to try and relabel USB devices.

With that in mind, here's how I installed the quadlet:

sudo cp ghostscript-printer-app.container /etc/containers/systemd/
sudo cp ghostscript-printer-app.volume /etc/containers/systemd/
sudo systemctl daemon-reload
sudo systemctl start ghostscript-printer-app

From there I needed to go to: http://localhost:8000/ to setup the Printer Application. I added the QL-800 as a printer, then I made some configuration changes. In particular I needed to update the media size, and I set the Print Quality to Fast.

After that, I ran into some odd behavior with gnome and LibreOffice where neither could auto-configure my printer as expected. But I was able to print from my phone (iOS) and from http://localhost:8000/ (by clicking the "test print" button). So overall the printer application was working.

To fix the issue in gnome, and to enable printing from applications such as LibreOffice I needed a work-around. Here's what I did:

I ran this command to find the URI for my Printer:

ippfind -l

ippfind detects the printer application using mDNS-SD and it prints a URI for each printer. For example, it prints something like: ipp://<host>.local/ipp/print/<PRINTER NAME>.

Once I found the URI for the QL-800, I could run a command to make the printer available to applications running on my laptop. Here's the command:

sudo lpadmin -p <PRINTER NAME> -E -v 'ipp://<HOST>.local:8000/ipp/print/<PRINTER NAME>' -m everywhere

The printer name, and the URI both come from the ippfind output.

After that, I could print labels from LibreOffice and it's mostly fine.

In some ways the IPP printer standard doesn't perfectly line up with the native PPD variables and capabilities. So I don't have as many options in the Printer > Properties dialog. In fact, there are no useful options in the Properties dialog. The only thing you can do is ruin your settings by making configuration changes that don't work 😆. Using the layered foomatic ptouch-driver-foomatic packages, there were a few useful options such as Print Quality. These options were accessible from Gnome Settings and from within the LibreOffice print dialog. When using the Printer Application, I'll need to make these adjustments by going to http://localhost:8000/ Instead

So it's still early days. But it did work. I made a few test prints and it was about as good as before. This setup also enables me to print from my phone (which is pretty handy).

That said, I've really not tested this very much. But it's pretty cool that I got a printer application deployed in a quadlet. I'll leave this on my system and continue to test it. I also think the LPrint Printer Application might be a promising alternative. It might be possible to deploy that in a quadlet too.

In my previous post I said:

And as of now it's looking like there are gonna be two common types of Printer Applications. Some will be native Printer Applications, where somebody takes the "legacy" driver and ports/wraps it cleanly using PAPPL. The other way is less clean... like putting some crusty service inside a container and exposing a clean HTTP API 🤣. The internals may still be crusty (they will still run the CUPS driver and filter code), but the host doesn't need its dependencies (so this is still an improvement).

My limited understanding is that LPrint is more like a clean PAPPL Implementation. And the ghostscript-printer-app is more like a crusty service running inside a container 😆 (but I'm Incredibly thankful for both projects ❤️). As of now, ghostscript is actually working on my system. And if I find an OCI image for LPrint, I'd love to check it out.

[castrojo]

Thanks for looking into this: Image=ghcr.io/openprinting/ghostscript-printer-app:latest

This seems like the important bit, we just need to ship good quadlets for these? Adding all the crappy drivers in Bluefin won't work, but quadlets are a few lines of text. Maybe we can autoconfigure GNOME when the container comes up or something?

[castrojo]

LOL try the snap on a dakota VM, I'd love to see if all the printer snaps work.

[castrojo]

I talked to TillK:

What you referred to with the link are OCI container images, to be run using Docker. The Snaps and these OCI images are containerizing the same software. We provide the 2 formats for more reach. Note that the OCI images are not tested or adapted for cloud-native environments. I wanted to run a GSoC project for that, but the candidate ended up going with a project at another org.

The Printer Application's primary functionality is not a web service but emulating a driverless printer. The web service is the admin interface for the Printer Application.

Sounds like we're the first! Let's get these into shape and ship them? Please file an issue in projectbluefin/common and then dump all your analysis there. We should send agents to inspect the snaps and your notes.

Then we can just ship this entire stack and drop all of the image specific packages, etc!

[castrojo]

Ok till told me what needs to happen I am starting planning work, thanks!