74 lines
3.8 KiB
Markdown
74 lines
3.8 KiB
Markdown
# 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.
|