# 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.