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

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.