Campaign CT slice A1. No behaviour change: this is the capability the rest of
Group A needs.
UiText already drew several differently-coloured runs on one line
(TextRun/RunsProvider, used by the character stat panel) but the path was gated
to OneLine == true, and the chat transcript is multi-line — so a chat line
could only ever be one colour. Retail's is not: a tagged glyph run takes the
element's TAG colour (property 0x1D) while the rest of the line takes the
ordinary one (0x1B), per UIElement_Text::InqGlyphs @0x00468EA0.
LineRunsProvider is a SIDECAR keyed by line index rather than a field on Line.
Roughly fifty files construct Line, and widening its shape would put every one
of them in the blast radius of a chat feature; a line with no runs draws
exactly as before.
The runs fold into the existing datLines list as extra entries at advancing
pen-X, so the S1 outline-then-fill batching is untouched — a multi-colour line
still submits its whole outline pass before any fill, and cannot notch the
descender of the line above.
Two things are deliberately load-bearing:
- RunsMatchLine. Selection, hit-testing and the caret all index into the FLAT
line text, so a run list that disagrees with it would draw one thing and
select another. The draw path verifies the runs say exactly the same
characters and falls back to the flat line if not, rather than trusting the
caller.
- LayoutRuns is pure. The pen-advance is the part that silently mis-renders
if it drifts, so it is testable without a font atlas or a GPU — which also
keeps its tests in the ordinary gate rather than the SystemFont lane.
Solution builds clean; full hermetic gate green, 0 failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
cf41b27c9a