Skip to content

Brand orange is #FF9E00 on screen, #FC9E00 in print

Status

Accepted — 2026-07-21, during SPEC-157 review Pass 2. Ratified by the brand owner. This record exists because the divergence is repo-wide and had already been re-litigated once as a review finding (P2-C3); without a durable decision it will be "fixed" back and forth on every future contrast pass.

Context

Two files claimed different canonical values for the same brand color:

  • plugins/core-standards/skills/visitrans-design-system/colors_and_type.css locks #FF9E00 and is contrast-tuned against it (the anthracite ramp, the --vt-orange-900 text tint, the WCAG derivations in its comment block).
  • configs/visitrans-cd-tokens.yaml and the print path — visitrans_cd, mermaid-diagrams-branded, c4-diagram, document-converter-branded — carry #FC9E00 (RGB 252,158,0 / CMYK 0,38,100,0), which visitrans_cd enforces at 0% tolerance for print reproduction.

The bootstrap Angular template shipped #FC9E00, so every generated product UI inherited an orange the design-system ramp was not tuned against. The same split exists for the action magenta: screen pure #FF00FF, print #E6007E.

This is not a mistake to reconcile to a single value. #FC9E00 is the correct print/CMYK orange; #FF9E00 is the correct screen/emissive orange (the CMYK-derived value reads muddy on a display). Both are canonical — for different media.

Decision

Theme polarity is a surface property (SPEC-157's thesis); brand-color rendering is a medium property, resolved the same way.

  • Screen (web/UI, Angular/PrimeNG, all ui_kits, all preview specimens, the bootstrap product template): orange #FF9E00, magenta #FF00FF.
  • Print/CD (Word, PDF, LaTeX, mermaid, c4, anything governed by visitrans_cd): orange #FC9E00, magenta #E6007E. Unchanged — do not touch.

Only these two colors diverge. Every other token resolves identically in both media.

Implementation

The token YAML keeps its print values under colors.primary / colors.action (so the print path is byte-unchanged) and adds a small colors.screen override group. Resolution is split in scripts/design_system/tokens.py:

  • _resolve_color() — symbolic resolution for the print path; skips the screen group deliberately, so a screen override can never re-color a diagram.
  • get_screen_color() — returns the screen override when present, else the shared print value. Consumed only by generate_css_variables.py and generate_primeng_preset.py.

Both screen generators now emit #FF9E00 / #FF00FF; tokens.py --mermaid and both brand_colors.py still emit #FC9E00 / #E6007E. Verified 2026-07-21.

Consequences

  • A single grep for #FC9E00 across the repo is expected to hit the print skills and the explanatory comments — it is no longer a defect signal on its own. The test to run is: does the screen generator output carry #FF9E00, and does the print generator output carry #FC9E00.
  • Any new screen surface must read --vt-orange / --vt-magenta (or call get_screen_color), never the raw colors.primary hex.
  • If the brand book itself is ever revised to unify the values, this record is the place to reverse the split.