## UPDATE (2026-09-10): Root cause confirmed — libcupsfilters ABI mismatch, NOT the cups-browsed migration

After further diagnosis the page-drop is caused by `libcupsfilters 2.2.1-2`, not the cups-browsed/cups-pdf removal. **Downgrading `libcupsfilters` to 2.1.1-4 fixes it perfectly** (user-verified). See full evidence below the original report.

### The real cause

`omarchy update` runs `pacman -Syu`, which pulled a **cross-major** upgrade:

```
libcupsfilters     2.1.1-4  ->  2.2.1-2     (upgraded by the update, both attempted 4.0.3 installs)
pdfio              1.6.5-1  (new dependency of 2.2.x)
cups-filters       2.0.1-2  (UNCHANGED — left mismatched against libcupsfilters 2.2)
hplip              3.26.4-1 (UNCHANGED)
cups               2:2.4.19-1 (UNCHANGED)
```

The known-good state pairs `cups-filters 2.0.1-2` with `libcupsfilters 2.1.1-4`. The update swapped the library for a new major without bumping the filter front-end that links against it.

### Evidence

1. Both 4.0.3 installs (09-09 and 09-10) did `libcupsfilters 2.1.1-4 -> 2.2.1-2`; the working 4.0.1 snapshot had 2.1.1-4.
2. CUPS page log says `total 2` (both pages rendered) but the printer ejects only one sheet. The hp backend ends cleanly (`read pjl job_end: 1`), so CUPS didn't abort — the renderer emitted data for one physical page.
3. **Single-variable fix:** `sudo pacman -U /var/cache/pacman/pkg/libcupsfilters-2.1.1-4-x86_64.pkg.tar.zst` + `sudo systemctl restart cups` → same 2-page job prints both sheets correctly. Zero other changes, and **cups-browsed stayed installed + the omarchy cups-files override stayed active** during the successful test — so neither of those is the cause.

### Suggested fix (updated)

Pin or cap the dependency so `pacman -Syu` cannot pull libcupsfilters 2.2.x underneath cups-filters 2.0.1-2 (e.g. `<2.2`), until a matching cups-filters release exists. Add a 2-page USB-HPLIP print to CI smoke tests and assert the page count. The libcupsfilters 2.2.x family replaced its PDF pipeline with pdfio — this is an ABI/behavior regression for the old cups-filters front-end.

### Workaround (applied, verified)

```
sudo pacman -U /var/cache/pacman/pkg/libcupsfilters-2.1.1-4-x86_64.pkg.tar.zst
sudo systemctl restart cups
# plus IgnorePkg pin so updates don't re-break it
```

---

_Original report below (the cups-browsed theory it presents was disproven by the isolated downgrade test; retained for history):_

## Summary

`omarchy update` (4.0.1 → 4.0.3) runs migrations `1787815267` and `1788009111`,
which remove the `cups-pdf` and `cups-browsed` packages and install
`cups-pk-helper`. After that, printing from Firefox to a manually-added local USB
printer (HP LaserJet P2055dn, HPLIP `hp` backend, PCL3) prints one correct page,
then literal `%@PJL` garbage followed by endless blank pages. `lp` jobs print
cleanly. Restoring the pre-update snapshot (cups-browsed/cups-pdf present) makes
Firefox print perfectly with zero config changes.

## Claimed behavior vs reality

PR #8951 states migration 1788009111 "leaves manually-added IPP and USB printers
untouched". That is not what happens here: a manually-added USB printer becomes
unusable *specifically* with browser printing after cups-browsed is removed.

## Environment

- Omarchy 4.0.1-1 → 4.0.3-1 (snapshot-restored to 4.0.1-1 after the break)
- hplip 1:3.26.4-1 (identical before/after — hplip is NOT the variable)
- cups 2:2.4.19-1, cups-filters 2.0.1-2 (identical before/after)
- Device: `hp:/usb/HP_LaserJet_P2055dn?serial=S2AR673`
- Driver: PCL3 (hpcups)

## Symptom detail

- First page correct, then `%@PJL ...` bytes + blank pages.
- CUPS filter chain exits cleanly (pdftopdf, universal, gs ps2write, ppdFilter all
  0; `PAGE: 1` logged).
- hp backend reads printer `pjl status: 10023`/`10007` mid-job — printer drops out
  of the expected language mode and treats the rest of the stream as empty/PCL.
- 20-page stress print via `lp` during the broken state: 20/20 clean. So it's
  Firefox/session-specific, not raw data.

## Ruled out (superseded — see UPDATE section)

- hplip version (same in both states)
- PCL3 vs PostScript driver (both PPDs, both hp/usb backends — both break for Firefox)
- filter chain (all exit 0)
- printer hardware (power-cycle + 20-copy pass)
- custom data (raw PS probes via `lp` garble too)

## Workaround applied

```
IgnorePkg = cups-browsed system-config-printer cups-pk-helper cups-pdf
```

in `/etc/pacman.conf`, plus `/usr/local/bin/fix-hp-printer.sh` that re-adds the
queue (PCL3 PPD, hp backend) and restarts cups.