# Tasks

## 1. PPD: Farbmodus-Default, Presets und Dokumentation

- [x] 1.1 `assets/Brother HL-4150CDN/ppd/BR4150_2.PPD`: `*DefaultBRColorMode`
      von `Normal` auf `None` ändern, alle eigenen Ergänzungen mit
      `%`-Kommentar (Herkunft/Zweck) markieren.
      Verifikation: `grep -n 'DefaultBRColorMode\|^% Modified' "assets/Brother HL-4150CDN/ppd/BR4150_2.PPD"`
      zeigt `*DefaultBRColorMode: None` und den Kommentar.
- [x] 1.2 PPD: sechs `APPrinterPreset`-Einträge ergänzen (Kombinationen
      color/monochrome × low/normal/high gemäß Tabelle in `design.md`).
      Verifikation: `grep -c '^\*APPrinterPreset' "assets/Brother HL-4150CDN/ppd/BR4150_2.PPD"`
      ergibt 6, und nach einem Build listet
      `lpoptions -p <queue> -l` weiterhin alle Optionen ohne
      PPD-Warnung in `/var/log/cups/error_log`.
      Ergebnis (2026-10-20): Zunächst als einzeilige `key=value`-Strings
      geschrieben – CUPS verwarf alle sechs stillschweigend
      (`_ppdParseOptions()` trennt an Whitespace, `key=value` wurde zum
      *Namen*). Mit libcups-2.4.2-Harness (`_ppd_cache_t`-Inspektion) belegt
      und auf das von CUPS selbst erzeugte Format umgestellt (mehrzeilig,
      Apple-Metadaten als `key value`, PPD-Optionen als `*Name Value`).
      Danach greifen alle sechs im `pstops`-Pfad (siehe 3.x).
- [x] 1.3 PPD: Choice `VividNoCIE` unter `BRColorMode` ergänzen
      (`<</UseCIEColor false /BRColorMode 1>>setpagedevice`) und per
      Testdruck gegen `None` vergleichen; nur behalten, wenn der Ausdruck
      deutlich gesättigter ist.
      Verifikation: `lpoptions -p <queue> -l` zeigt die Choice, die
      Entscheidung (behalten/entfernen) ist im README-Auswertungs-Abschnitt
      notiert.
      Ergebnis (2026-10-20): Testdrucke `BRColorMode=VividNoCIE` (Job 5) und
      `BRColorMode=None` (Job 6) sind **nicht unterscheidbar** → Choice
      wieder entfernt (README/Tabelle bereinigt).
- [x] 1.4 README: Abschnitt „Farben sind blass" (Ursache `UseCIEColor`,
      durchgeführte Testreihe mit `lp -o BRColorMode=…`,
      Ergebnis `None`), Abschnitt „Änderungen an der Hersteller-PPD"
      (welche Einträge ergänzt wurden und warum) und Abschnitt
      „Optionen fehlen im macOS/iOS-Dialog" (nur IPP-Standardoptionen
      sichtbar, PPD-Optionen über `PRINTER_OPTIONS`/CUPS-Web-UI/`lp`).
      Verifikation: die im README genannten `lp`/`lpoptions`-Befehle
      laufen unverändert gegen den laufenden Container.

## 2. entrypoint: `PRINTER_OPTIONS`

- [x] 2.1 `entrypoint.sh`: `PRINTER_OPTIONS` (Standard leer) nach der
      Queue-Erzeugung in Tokens `key=value` zerlegen und jedes per
      `lpadmin -o` setzen, an derselben Stelle wie
      `printer-is-shared`/`-D`/`-d`, bei jedem Start.
      Verifikation: Start mit
      `PRINTER_OPTIONS="BRColorMode=Vivid TonerSaveMode=False"` und
      `lpoptions -p <queue> -l` zeigt `Vivid` und `True` als Default
      (`*Vivid`, `*True`).
- [x] 2.2 Fehler pro Token abfangen, damit `set -eu` den Start nicht
      abbricht, und warnen.
      Verifikation: Start mit `PRINTER_OPTIONS="NoSuchOption=Foo"` erzeugt
      eine Warning-Zeile im Log, der Container erreicht
      „ready: CUPS on 631/tcp" und `lpstat -r` meldet „scheduler is running".
- [x] 2.3 README: neue Zeile in der Env-Var-Tabelle plus Kurzbeispiel unter
      „Environment variables" (inkl. Hinweis `lpoptions -p <queue> -l` zur
      Entdeckbarkeit der Namen).
      Verifikation: das Beispiel aus der Tabelle in einen `podman run`-Befehl
      übertragen, Start und `lpoptions`-Abfrage wie beschrieben.

## 3. Integrationstests am laufenden System

- [x] 3.1 Image neu bauen und Container starten.
      Verifikation: `podman build -t printserver:latest .` endet ohne Fehler,
      das Log enthält „ready: CUPS on 631/tcp, mDNS on 5353/udp".
      Ergebnis (2026-10-20, podman 6.1.4/macOS-VM): Build und Start ok; der
      Container bindet 631 nur nach
      `podman machine ssh -- sudo sysctl -w net.ipv4.ip_unprivileged_port_start=631`
      (rootless VM) – danach „ready".
- [x] 3.2 S/W-Druck aus dem macOS-Dialog (derselbe Farbjob wie zuvor).
      Verifikation: Ausdruck ist schwarz/weiß – vorher kam er farbig heraus.
      Server-seitig verifiziert (2026-10-20): `print-color-mode=monochrome`
      → `<</BRProcessColor 1>>`. Sichtprüfung durch Nutzer (2026-10-20):
      Testseite 2 ist schwarz/weiß. **Bestanden.**
- [x] 3.3 Farbdruck ohne weitere Optionen aus dem Dialog und per
      `lp -d <queue> test.pdf`.
      Verifikation: Ausdruck ist so gesättigt wie der bisherige
      `BRColorMode=None`-Testdruck; `lpoptions -p <queue> -l` zeigt `*None`
      als Farbmodus-Default.
      Verifiziert (2026-10-20): `lpoptions` zeigt `*None`, `pstops` emittiert
      `<</UseCIEColor false>>` auch ohne Job-Optionen. Sichtprüfung durch
      Nutzer: Testseite 1 ist kräftig/gesättigt (nicht mehr blass).
      **Bestanden.**
- [x] 3.4 Qualitätsstufen prüfen.
      Verifikation: `lp -o print-quality=3 test.pdf` (IPP draft, sichtbar
      tonersparender: `true tonersave`) und `lp -o print-quality=5 test.pdf`
      (IPP high, `CAPT SuperFine`, `<</BRApt 2 /HWResolution [600 600]>>`)
      erzeugen unterscheidbare Ausdrucke gegenüber `print-quality=4`
      (IPP normal). Hinweis: IPP-`print-quality` ist 3/4/5 – nicht 2/5.
      Verifiziert (2026-10-20): serverseitig im `pstops`-Output (3 → 
      `true tonersave`, 5 → `BRApt 2`); Sichtprüfung durch Nutzer: Seite 3
      (draft) blass/tonersparend, klar unterscheidbar von 1/4. Seite 1 = 4
      erwartungsgemäß (SuperFine vs. Fine bei diesem Testmotiv optisch
      gleich, serverseitig aber gesetzt). **Bestanden.**

## Workflow follow-up

- Nach Review und grünem Durchlauf die Änderung mit `/opsx-archive`
  archivieren und das Ergebnis prüfen.