Print to reMarkable: vom Druckdialog direkt aufs Tablet

Im Repo von rmapi liegt ein Tutorial von 2018. Es verspricht einen Eintrag im PDF-Menü des macOS-Druckdialogs, der jedes Dokument direkt in die reMarkable-Cloud lädt. Acht Jahre später stimmt daran fast nichts mehr: Das verlinkte Repo ist archiviert, die Release-Datei existiert nicht mehr, und den Kern der Anleitung verweigert macOS heute stumm. Der Eintrag im Druckdialog ist trotzdem machbar, und am Ende sogar mehr als das. So geht es 2026, auf einem MacBook mit Apple Silicon und macOS 26.

rmapi installieren

Gepflegt wird rmapi inzwischen von ddvk, das ursprüngliche Repo von juruen ist archiviert. Das aktuelle Release v0.0.34 bringt getrennte Builds für Apple Silicon (rmapi-macos-arm64.zip) und Intel (rmapi-macos-intel.zip) mit. Im Archiv steckt genau eine Datei: das unsignierte Binary.

Die Versionsnummer ist diesmal keine Nebensache. Seit einer API-Umstellung der reMarkable-Cloud im Mai 2026 scheitert v0.0.33 früher oder später an jedem Sync, die Antwort ist ein HTTP 400 ohne weitere Erklärung. Der Fix steckt ab v0.0.34.

Auf einem Apple-Silicon-Mac reichen vier Befehle, das Binary landet in ~/.local/bin:

uname -m
curl -fsSL https://github.com/ddvk/rmapi/releases/download/v0.0.34/rmapi-macos-arm64.zip -o /tmp/rmapi.zip
unzip -o /tmp/rmapi.zip -d /tmp && install -m 755 /tmp/rmapi ~/.local/bin/rmapi
rmapi version

uname -m beantwortet die Architekturfrage: arm64 heißt Apple Silicon, x86_64 heißt Intel-Build. Danach muss ~/.local/bin im PATH liegen, ein Export in der .zprofile genügt.

Beim unsignierten Binary hatte ich mit Gatekeeper-Theater gerechnet. Kam keins. Per curl geladene Dateien bekommen kein Quarantäne-Attribut, xattr -l zeigt eine leere Liste und rmapi version startet ohne Rückfrage.

Mit der reMarkable-Cloud koppeln

Beim ersten Start ohne Argumente fragt rmapi nach einem Einmal-Code:

Enter one-time code (go to https://my.remarkable.com/device/browser/connect):

Den achtstelligen Code holst du dir unter my.remarkable.com/device/browser/connect, er gilt nur wenige Minuten. Danach meldet sich die Cloud-Shell mit deinem Account.

Ältere Anleitungen nennen ~/.rmapi oder ~/.config/rmapi/rmapi.conf als Ablageort der Zugangsdaten. Auf dem Mac stimmt beides nicht. Das Go-Binary folgt os.UserConfigDir und legt die Datei unter ~/Library/Application Support/rmapi/rmapi.conf ab. Dort stehen Device- und User-Token im Klartext. Setz die Rechte auf 600 und halte die Datei aus Backups heraus, die du weitergibst.

chmod 600 ~/Library/Application\ Support/rmapi/rmapi.conf

Der Funktionstest braucht keine Shell-Sitzung: rmapi ls listet die Wurzel des Tablets.

Der Weg von 2018 scheitert stumm

Das alte Tutorial baut an dieser Stelle einen Automator-Workflow. Ich wollte ihn mir sparen: macOS akzeptiert in ~/Library/PDF Services/ auch ein simples ausführbares Shell-Skript, und der Eintrag erscheint danach im PDF-Menü des Druckdialogs.

Klingt nach dem kürzesten Weg. War es keiner.

Der Klick auf den Eintrag tut: nichts. Keine Fehlermeldung, keine Logzeile, nichts im Unified Log. Ruft man dasselbe Skript von Hand auf, lädt es brav hoch. Seit Big Sur laufen PDF-Services unter printtool in einer Sandbox, und die führt schlichte Skripte gar nicht erst aus. Der Menüeintrag bleibt Deko.

Ein Druck-Plugin aus Automator, notfalls ohne Automator

Funktioniert hat am Ende das, was das Tutorial von Anfang an wollte: ein Automator-Druck-Plugin. In Automator heißt das: neues Dokument vom Typ Druck-Plugin, Aktion Shell-Skript ausführen, Übergabe der Eingabe auf als Argumente stellen, speichern unter Print to reMarkable. Das Skript darin ist kurz:

for f in "$@"; do
  "$HOME/.local/bin/rmapi" put "$f"
done

Wer Automator nicht öffnen mag: Das gespeicherte Druck-Plugin ist nur ein Ordner Print to reMarkable.workflow in ~/Library/PDF Services/ mit zwei Dateien darin, Contents/Info.plist und Contents/document.wflow. Beides ist XML und lässt sich von Hand schreiben. Entscheidend sind drei Werte im document.wflow: die Aktion com.apple.RunShellScript, inputMethod 1 für die Übergabe als Argumente und der workflowTypeIdentifier com.apple.Automator.printWorkflow.

Testen lässt sich das Plugin ohne einen einzigen Druckdialog:

automator -i test.pdf ~/Library/PDF\ Services/Print\ to\ reMarkable.workflow

Eine Umbenennungs-Logik wie im alten Tutorial braucht das Skript nicht mehr. printtool übergibt die temporäre PDF bereits unter dem Titel des Druckjobs. Aus Testdruck reMarkable.txt wird Testdruck reMarkable.pdf, und genau so heißt das Dokument später auf dem Tablet.

Der Testdruck

Zehn Seiten aus TextEdit, Cmd+P, unten links PDF, Print to reMarkable:

Vom Klick bis zur OK-Zeile im Log vergehen keine zehn Sekunden, dann liegt das Dokument auf dem Tablet. Das Skript im Plugin loggt nach ~/Library/Logs/print-to-remarkable.log, so bleibt jeder Upload nachvollziehbar.

Chrome druckt am PDF-Menü vorbei

Fertig war ich damit trotzdem nicht. Chrome bringt einen eigenen Druckdialog mit, und dort gibt es kein PDF-Menü. Wer aus dem Browser aufs Tablet will, braucht einen echten Drucker im System. Auch der steckt schon in macOS: ippeveprinter, ein kleiner IPP-Server, der für jeden Druckjob ein Kommando ausführt.

#!/bin/bash
# ~/.local/libexec/rmapi-ipp-print
LOG="$HOME/Library/Logs/print-to-remarkable.log"
NAME="${IPP_JOB_NAME:-Druckjob}"
WORK="$(mktemp -d)"
cp "$1" "$WORK/$NAME.pdf"
{
  echo "--- $(date '+%Y-%m-%d %H:%M:%S') IPP-Drucker: $NAME"
  "$HOME/.local/bin/rmapi" put "$WORK/$NAME.pdf" && echo "OK"
} >>"$LOG" 2>&1
rm -rf "$WORK"

Der Stolperstein steckt im cp “$1”: ippeveprinter übergibt das Dokument als Dateiargument, nicht über stdin. Mein erster Versuch las von stdin und lud eine leere Datei hoch, die Cloud quittierte das mit einer Prüfsumme aus lauter Nullen und der Meldung unable to validate. Auch hier trägt der Jobtitel den Dokumentnamen, er kommt über die Umgebungsvariable IPP_JOB_NAME herein.

Gestartet ist der Server mit einer Zeile:

/usr/bin/ippeveprinter -p 8632 -f application/pdf -c ~/.local/libexec/rmapi-ipp-print -r off reMarkable

-f application/pdf sorgt dafür, dass CUPS jeden Job als fertiges PDF anliefert, -r off unterbindet die Bonjour-Ankündigung im Netz. Für den Dauerbetrieb steckt der Aufruf bei mir in einem LaunchAgent unter ~/Library/LaunchAgents, damit er bei jedem Login startet.

Fehlt noch die Druckerwarteschlange. Admin-Konten stecken in der Gruppe _lpadmin, sudo braucht es deshalb nicht:

lpadmin -p reMarkable -E -v ipp://localhost:8632/ipp/print -m everywhere -D "reMarkable Cloud"

Ab jetzt taucht reMarkable Cloud überall auf, wo macOS Drucker anbietet, Chromes eigener Dialog eingeschlossen. Der erste echte Druck aus dem Browser war ein heise-Artikel mit gut zwölf Megabyte, ein paar Sekunden später lag er auf dem Tablet.

Beim Testen war mein Laserdrucker übrigens offline. Aufgefallen ist es nicht: Der nützlichste Drucker in diesem Menü braucht gar kein Papier. Wenn ein reMarkable auf deinem Schreibtisch liegt, bau dir die beiden Einträge. Mehr als ein Binary, ein Einmal-Code und zwei kurze Skripte stecken nicht dahinter.

Links

• rmapi (gepflegtes Repo): github.com/ddvk/rmapi
• Release v0.0.34 mit den macOS-Builds: github.com/ddvk/rmapi/releases/tag/v0.0.34
• Die API-Umstellung vom Mai 2026, an der ältere Versionen scheitern: Issue #62 und PR #63
• ippeveprinter in der CUPS-Dokumentation: man ippeveprinter
• Das Original-Tutorial von 2018: docs/tutorial-print-macosx.md
• Kopplungs-Seite für den Einmal-Code: my.remarkable.com/device/browser/connect