proposal to revert color mode default

openspec/changes/revert-colour-mode-default/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-10-20

openspec/changes/revert-colour-mode-default/design.md

@@ -0,0 +1,73 @@
+# Design
+
+## Context
+
+Commit `tpypxmkn` set `*DefaultBRColorMode: None` in the shipped PPD (plus a
+"Modified by this repo" comment), documented the rationale in three README
+sections, and synced a spec requirement *Colour output is saturated by
+default*. Its own message already conceded that a `VividNoCIE` candidate
+printed identically to `None`. The decisive new evidence (see proposal.md —
+Why) is that `None` also prints identically to the **vendor default** `Normal`:
+before/after prints through the container are indistinguishable, while the
+same document through the Mac's local driver is clearly more saturated. The
+washout therefore originates in the server-side PostScript path (no client-side
+colour management), not in the printer's `UseCIEColor` switch, and no
+server-side lever is currently known.
+
+The same commit also added two features that this change does **not** touch:
+the six `APPrinterPreset` entries in the PPD and the `PRINTER_OPTIONS`
+mechanism in `entrypoint.sh`.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Restore the vendor `*DefaultBRColorMode: Normal` so the shipped PPD deviates
+  from Brother's original only where the deviation earns its keep (the
+  presets).
+- Remove every saturation claim from README and spec; document the tested
+  limitation honestly, including the local-driver recommendation.
+- Encode the "no untested PPD deviations" decision at spec level so the
+  change cannot silently regress.
+
+**Non-Goals:**
+- Finding a server-side fix for the saturation gap (needs printer-side
+  investigation and physical test prints).
+- Changing the `APPrinterPreset` mappings, `PRINTER_OPTIONS`, the entrypoint
+  or the Containerfile.
+- Re-testing colour modes on the physical printer — the user already performed
+  the decisive comparison.
+
+## Decisions
+
+- **D1 — Revert the default, don't merely re-document it.** Both defaults
+  print identically, so reverting carries no regression risk, and it restores
+  the "vendor original plus marked additions" property of the PPD. Keeping
+  `None` with corrected docs would leave a deviation whose stated rationale
+  no longer exists.
+- **D2 — Spec delta = REMOVED + ADDED.** A bare removal of the disproven
+  requirement would leave no record of the decision. The ADDED requirement
+  (*Vendor colour-mode default is preserved*) is testable (installed-PPD
+  grep, `lpoptions`) and prevents future untested deviations from becoming
+  the default.
+- **D3 — Rewrite the troubleshooting section, don't patch it.** Symptom stays;
+  the cause section now states the tested facts (`None` vs. vendor default: no
+  difference; `Vivid`: no difference; `BRPrintQuality`/`TonerSaveMode`: no
+  difference) and locates the gap in the conversion path; the remedy becomes
+  "use the local driver for colour-critical output", with the printer-menu
+  hints (Toner Save off, `BRMediaType` matching the media) as the only
+  remaining adjacent levers. The `lpoptions` check now expects `*Normal`.
+- **D4 — Minimal PPD edit.** Exactly two changes: the value line back to
+  `Normal` and the three-line default comment removed. The presets comment
+  block stays, so `diff` against the vendor original shows only the presets.
+- **D5 — Split verification.** Container-side checks (installed PPD default,
+  `BRColorMode` option list, override via `PRINTER_OPTIONS` still working) are
+  automated in the integration task; the colour verdict itself is physical and
+  stays with the user, stated as such in the tasks.
+
+## Risks / Trade-offs
+
+- Someone later re-attempts a "colour fix" by re-deviating the PPD →
+  mitigated by D2 (spec) and the honest README section (D3).
+- Readers of the old README may believe the container solved washout → the
+  corrected sections now say explicitly that it does not; the only behavioural
+  change of this revert is a PPD default that prints identically.

openspec/changes/revert-colour-mode-default/proposal.md

@@ -0,0 +1,61 @@
+# Proposal
+
+## Why
+
+Commit `tpypxmkn` changed the vendor PPD default `*DefaultBRColorMode:
+Normal → None` on the theory that the printer's own CIE conversion washes out
+colours, and the spec recorded the result as `Requirement: Colour output is
+saturated by default`. A controlled before/after comparison now shows the
+change had **no visible effect**: prints made after it look the same as prints
+made before it, and both are clearly less saturated than the same document
+printed through the Mac's local driver. The commit itself had already noted
+that a second candidate (`VividNoCIE`) produced no difference from `None`; the
+new comparison extends that to `None` vs. the vendor default `Normal`. The
+washout originates in the server-side PostScript path, not in the printer's
+`UseCIEColor` switch — so the README and the spec currently promise a fix that
+does not exist, and the PPD carries a "modified by this repo" deviation for no
+measurable benefit.
+
+## What Changes
+
+- **PPD** (`assets/Brother HL-4150CDN/ppd/BR4150_2.PPD`): restore the vendor
+  default `*DefaultBRColorMode: Normal` and remove the comment block that
+  justified the `None` deviation. The six `APPrinterPreset` entries stay —
+  they are a separate feature and unaffected by this finding.
+- **README**: correct all three places that repeat the claim — the options
+  table (`Normal` is the default again), *Changes to the vendor PPD* (only the
+  presets remain a deviation), and the troubleshooting section *Colours are
+  printed pale / washed out*, rewritten from "fixed via `UseCIEColor` off" to
+  a documented, tested limitation: `BRColorMode`/`UseCIEColor` settings do not
+  measurably change saturation; for colour-critical output use the local
+  driver.
+- **Spec** (`printserver/cups`): remove `Requirement: Colour output is
+  saturated by default` (its claim is disproven) and add a requirement that
+  the queue preserves the vendor PPD colour-mode default unless explicitly
+  overridden — encoding the revert and preventing another untested deviation.
+
+## Capabilities
+
+### New Capabilities
+
+(none)
+
+### Modified Capabilities
+
+- `printserver/cups`: the requirement *Colour output is saturated by default*
+  is removed and replaced by a requirement that the vendor PPD colour-mode
+  default is preserved.
+
+## Impact
+
+- `assets/Brother HL-4150CDN/ppd/BR4150_2.PPD` — one value line plus its
+  comment restored to the vendor original.
+- `README.md` — three sections (options table, vendor-PPD section,
+  colours troubleshooting).
+- `openspec/specs/printserver/cups/spec.md` — one requirement removed, one
+  added (applied at archive time).
+- Runtime behaviour: only the queue's `BRColorMode` default changes back
+  (`None` → `Normal`); per-job/per-queue overrides via `PRINTER_OPTIONS` or
+  `-o` are untouched, as are the presets and `PRINTER_OPTIONS` itself. No
+  container, entrypoint or discovery changes. Since the two defaults print
+  identically, no user-visible difference is expected from the revert either.

openspec/changes/revert-colour-mode-default/specs/printserver/cups/spec.md

@@ -0,0 +1,24 @@
+# Spec Delta
+
+## REMOVED Requirements
+
+### Requirement: Colour output is saturated by default
+Disproven by before/after test prints: defaulting to `BRColorMode: None`
+(`UseCIEColor` off) produced no visible difference to the vendor default, and
+the saturation gap to the local driver persists (see proposal.md).
+
+## ADDED Requirements
+
+### Requirement: Vendor colour-mode default is preserved
+Unless explicitly overridden — through `PRINTER_OPTIONS` at startup or a
+per-job option — the queue SHALL use the vendor PPD's colour-mode default
+(`BRColorMode: Normal`). The shipped PPD SHALL not deviate from the vendor
+default in this value.
+
+#### Scenario: Default colour mode equals the vendor PPD default
+- **WHEN** a colour job is printed without any colour-mode options and `PRINTER_OPTIONS` does not set `BRColorMode`
+- **THEN** the queue's colour mode is the vendor default `Normal`
+
+#### Scenario: An explicit override still wins
+- **WHEN** the container is started with `PRINTER_OPTIONS` containing `BRColorMode=None`
+- **THEN** the queue default is `None` instead of the vendor default `Normal`

openspec/changes/revert-colour-mode-default/tasks.md

@@ -0,0 +1,58 @@
+# Tasks
+
+## 1. PPD auf Vendor-Default zurücksetzen
+
+- [ ] 1.1 `assets/Brother HL-4150CDN/ppd/BR4150_2.PPD`: `*DefaultBRColorMode:
+      None` auf den Vendor-Wert `*DefaultBRColorMode: Normal` zurücksetzen und
+      den dreizeiligen „Modified by this repo"-Kommentar über dem Default
+      entfernen. Die sechs `APPrinterPreset`-Einträge und ihr Kommentarblock
+      bleiben unverändert.
+      Verifikation: `grep -n 'DefaultBRColorMode' 'assets/Brother HL-4150CDN/ppd/BR4150_2.PPD'`
+      zeigt genau `*DefaultBRColorMode: Normal` ohne vorangehenden
+      „Modified by this repo"-Kommentar; `grep -c 'APPrinterPreset'` ergibt
+      weiterhin 6; `jj diff` enthält ausschließlich diese Änderungen.
+
+## 2. README korrigieren
+
+- [ ] 2.1 Optionstabelle („Colour mode | `BRColorMode`"): Werte auf
+      `Normal` (default), `Vivid`, `None` ändern.
+      Verifikation: `grep -n 'BRColorMode' README.md` zeigt in der Tabelle
+      „Normal (default)" und nirgends mehr „None (default)".
+- [ ] 2.2 Abschnitt *Changes to the vendor PPD*: den ersten Aufzählungspunkt
+      (Default-Wechsel mit CIE-Begründung) entfernen, die Einleitung auf die
+      verblebende eine Abweichung (Presets) anpassen und den
+      Verweis auf den Troubleshooting-Abschnitt entsprechend korrigieren.
+      Verifikation: Abschnitt listet nur noch die Presets; `grep -n 'DefaultBRColorMode' README.md`
+      findet den Ausdruck nur noch in der Troubleshooting-Sektion (falls dort
+      referenziert).
+- [ ] 2.3 Troubleshooting-Abschnitt *Colours are printed pale / washed out*
+      umschreiben (Design D3): Symptom bleibt, Ursache nennt die getesteten
+      Fakten (`None` vs. Vendor-Default ohne sichtbaren Unterschied, ebenso
+      `Vivid`, `BRPrintQuality`, `TonerSaveMode`), die Lücke liegt im
+      serverseitigen PostScript-Pfad gegenüber der Farbverwaltung des lokalen
+      Treibers; Abhilfe: farbkritische Ausdrucke über den lokalen Treiber,
+      Drucker-Menü-Hinweise (Toner Save aus, `BRMediaType`) beibehalten;
+      `lpoptions`-Check mit Erwartung `*Normal`; weder „produces saturated
+      output" noch `expect *None` stehen mehr.
+      Verifikation: `grep -n 'saturated output\|expect \*None' README.md`
+      ohne Treffer; die im Abschnitt stehenden Befehle laufen gegen den
+      laufenden Container aus 3.1.
+
+## 3. Integrationstests (podman, lokal)
+
+- [ ] 3.1 Image bauen und Container starten: installierte PPD im Image hat
+      `*DefaultBRColorMode: Normal`, `lpoptions -p <queue> -l | grep BRColorMode`
+      listet `Normal`/`Vivid`/`None`, Startup endet mit `ready`.
+      Verifikation: `podman exec printserver grep 'DefaultBRColorMode' /usr/share/cups/model/BR4150_2.PPD`,
+      `podman exec printserver lpoptions -p <queue> -l | grep BRColorMode`,
+      `podman logs printserver | grep 'ready'`.
+- [ ] 3.2 Override-Pfad: Container mit `PRINTER_OPTIONS="BRColorMode=None"`
+      starten → Queue-Default ist `None`; danach Testcontainer verwerfen.
+      Verifikation: `podman exec printserver lpoptions -p <queue> | grep BRColorMode`
+      enthält `BRColorMode=None`.
+- [ ] 3.3 Physischer Farbtest (durch Nutzer, kein Automationspfad): Testdruck
+      über die Container-Queue mit Normal-Default — erwartet: identisch zu den
+      Ausdrucken vor/nach tpypxmkn, also weiterhin weniger gesättigt als der
+      lokale Treiber (belegt die Limitation, die README und Design D3
+      dokumentieren).
+      Verifikation: Nutzerbestätigung im Review vor `/opsx-archive`.