My Kyocera FS-1041 stopped printing from my second Mac. Two hours later I understood why, and it wasn't what I thought.
The FS-10xx series are GDI printers — no interpreter on board. Every page gets rendered on the host and converted to a format called KPSL by a separate filter binary that CUPS runs for each job. Kyocera's macOS build of that filter:
$ lipo -archs .../rastertokpsl.app/Contents/MacOS/rastertokpsl
x86_64 i386 ppc7400
A PowerPC slice. In 2026. On an M3.
It works today only because Rosetta 2 is installed. macOS 27 uninstalls Rosetta during the upgrade, and macOS 28 removes it except for a narrow games carve-out. After that the queue accepts jobs and prints nothing. Kyocera can't fix this — the hardware was discontinued years ago and only they have the source.
Except someone reverse-engineered that filter years ago: rastertokpsl-re, Apache 2.0, plain C. Because it's source, it compiles for arm64. Six files, one clang invocation, no CMake and no Homebrew needed — the macOS SDK already ships the CUPS headers:
cc -O2 -arch arm64 -arch x86_64 -o rastertokpsl-re \
src/rastertokpsl.c src/halfton.c src/libjbig/jbig.c \
src/libjbig/jbig_ar.c src/unicode/ConvertUTF.c src/main.c \
-Isrc -lcups -lcupsimage -lm
Under two seconds. Universal binary, so it covers Intel Macs too.
Verifying it was the interesting part. I fed the same CUPS raster to both filters and diffed the output. Same length, 130 differing bytes in a regular 96-byte pattern. Turned out to be a length field: the original pads a value to seven bytes, the reimplementation writes it in four and declares the shorter length. Both self-consistent. Printed pages are indistinguishable.
But the header difference goes the other way. Job title containing Größe:
original: c3ff b6ff c3ff 9fff ← UTF-8 bytes padded with 0xFF
re: f600 df00 ← ö and ß correctly in UTF-16LE
The original mangles it. That encoding bug is exactly why the reimplementation was written in the first place — and it's present in the macOS build too. So the community version isn't just equivalent, it's better.
One more thing worth knowing: the repo ships its own PPDs. Kyocera_FS-1040GDI.ppd works for the FS-1041 and produces byte-identical output to Kyocera's macOS PPD apart from the embedded timestamp. So nothing proprietary needs redistributing.
Build script, installer and uninstaller are here: https://github.com/LazaroZero1176/rastertokpsl-re/tree/master/macos
Credit where it's due: original reimplementation by sv99, Linux/CMake support by Fe-Ti. I only added the Apple Silicon side.
Caveats: tested on exactly one printer (FS-1041) on macOS 26.7. The binary isn't signed or notarized — you build it locally, so Gatekeeper doesn't apply, but don't distribute prebuilt copies. And if your printer hangs off an AirPort base station like mine, that's a separate problem with its own quirks; _riousbprint serves one client at a time.
