Proposal

Why

While verifying the revert-colour-mode-default change, an operational check found a divergence for one PPD option: after the entrypoint applies PRINTER_OPTIONS="BRColorMode=None TonerSaveMode=True", the queue shows BRColorMode ... *None (consistent everywhere) but TonerSaveMode ... *False even though the queue's PPD copy at /etc/cups/ppd/<queue>.ppd contains *DefaultTonerSaveMode: True. The rejected tool option lpadmin -p <queue> -o TonerSaveMode=True (config-only, immediately surfaced) reproduces the same split. TonerSaveMode is the option that the APPrinterPreset entries use to implement the "draft prints with toner saving" behaviour recorded in the spec, so a queue default that only half applies undermines one of the documented scenarios.

The current spec (Queue defaults are configurable at runtime → Options are applied on start) is written as a configuration check ("the queue defaults include TonerSaveMode=False") and is satisfied by the settings file alone, so it does not pin down whether a job actually receives TonerSaveMode=True. That gap is why the divergence went unnoticed. This change turns the requirement into an observable one — the emitted job — and makes whatever the investigation finds explicit in the spec instead of leaving the contradiction undocumented.

What Changes

Investigate the TonerSaveMode split during apply: determine whether a job with the queue default TonerSaveMode=True actually emits the toner-save PostScript (statusdict/tonersave → true) or silently falls back to the PPD default False, and record the root cause in the design/tasks notes.
Spec (printserver/cups): replace the configuration-only Options are applied on start scenario with an observable job-level scenario; add a scenario that pins down what a job whose queue default conflicts with the PPD default must emit. Add the TonerSaveMode observable to the colour-mode requirement's scope (BRColorMode only) so the two are not conflated.
Tests (tests/): add a job-level integration test that applies the documented PRINTER_OPTIONS="BRColorMode=Vivid TonerSaveMode=False" example, submits a job with the bundled sample, and asserts the emitted PostScript carries UseCIEColor true (Vivid) and statusdict ... tonersave ... false (TonerSaveMode) — i.e. the queue default wins over the PPD default in the output. If the investigation shows it cannot win, the test instead asserts the honest current behaviour and the spec records the limitation.
README: state what PRINTER_OPTIONS queue defaults do to a job, with the verified example output, and note any option-specific caveat found.

No change to entrypoint.sh plumbing is planned: it already calls lpadmin -o <option> for every validated key=value pair, and its warning path for unusable entries stays as is. A code change happens only if the investigation identifies a server-side cause that is fixable in the image.

Capabilities

New Capabilities

(none)

Modified Capabilities

printserver/cups: the runtime queue-default requirement becomes job-observable, and a scenario covers a queue default that conflicts with the PPD default.

Impact

openspec/specs/printserver/cups/spec.md (requirement text at sync time; the delta lives in this change).
No project test suite exists yet (AGENTS.md: no build/test/lint config) — this change introduces the first one, a self-contained tests/test-queue-defaults.sh that drives podman/podman exec, so the verification is reproducible instead of an ad-hoc shell session.
README.md — PRINTER_OPTIONS documentation gains the verified job-level behaviour.
assets/Brother HL-4150CDN/ppd/BR4150_2.PPD — the six APPrinterPreset entries that set *TonerSaveMode are the client that exercises the option; they stay unchanged.
entrypoint.sh — unchanged unless the investigation finds a server-side cause.
Out of scope: the colour saturation limitation documented by revert-colour-mode-default (no server-side lever is known, and none is proposed here).

4.1 KiB Raw Permalink Blame History