acdream/docs/research/2026-08-10-retail-ui-text-style.md

# Retail UI text style — font resource, style model, outline pass, SpewBox, acdream gap list

**Date:** 2026-08-10
**Status:** RESEARCH ONLY — no production code changed.
**Trigger:** Campaign CH user-gate round 4 (2026-08-10). The user reports that BOTH the
chat-window transcript text and the on-screen SpewBox text differ from retail in face, size,
colour shade, and "shading" — retail's text carries a heavy black border that ours does not.
User-supplied retail screenshot of the SpewBox showing "You can't jump while in the air":
golden/amber fill, **strong full black outline around every glyph** (a border, not an offset
drop-shadow), bold serif face, horizontally centred at the very top of the viewport.

**Primary sources**
- `docs/research/named-retail/acclient_2013_pseudo_c.txt` (Sept 2013 EoR build, PDB-named)
- `docs/research/named-retail/acclient.h` (verbatim retail struct definitions)
- The installed DATs at `%USERPROFILE%\Documents\Asheron's Call\` read through
  `Chorizite.DatReaderWriter` 2.1.7 — the same reader `DatCollection` uses in production.
  All measurements below were taken with a throwaway scratchpad probe (not committed).

**Headline result.** Retail's outline is not a shadow and not a shader effect. Every retail
`Font` DAT resource ships **two** glyph atlases — a foreground (fill) plane and a background
(outline) plane whose glyphs are the fill glyphs **dilated by 2 px on every side** — plus the
per-font `NumHorizontalBorderPixels` / `NumVerticalBorderPixels` that say how far to inflate
the blit rectangle to capture that dilation. acdream loads both atlases but (a) never enables
the outline pass at any production call site and (b) blits the background plane with the
**un-inflated** rect, so even switching the flag on would draw almost nothing. Both must be
fixed together.

---

## 1. THE FONT RESOURCE (`DB_TYPE_FONT`, `0x40xxxxxx`)

### 1.1 Wire layout — `Font::Serialize @ 0x00443650`

Fields in serialization order (all `Archive::CheckAlignment(4)` then `GetBytes`):

| Offset in stream | Type | Field | Notes |
|---|---|---|---|
| — | — | `DBObj::Serialize` | the DID header |
| +0 | `uint32` | `maxCharHeight` | line height |
| +4 | `uint32` | `maxCharWidth` | used by the fixed-width advance mode |
| +8 | `uint32` | `numCharacters` | |
| +12 | `numCharacters × 11 bytes` | `charDescs` | `esi_1 = numCharacters * 0xb` @ `0x004436df` |
| | `uint32` | `m_NumHorizontalBorderPixels` | @ `0x00443750` |
| | `uint32` | `m_NumVerticalBorderPixels` | @ `0x00443778` |
| | `int32` | `m_BaselineOffset` | @ `0x004437a0` |
| | `uint32` | `m_ForegroundSurfaceDataID` | @ `0x004437c8` |
| | `uint32` | `m_BackgroundSurfaceDataID` | @ `0x004437f3` |

`FontCharDesc` (`acclient.h:4129`, `__unaligned align(1)`, exactly 11 bytes):
`u16 m_Unicode; u16 m_OffsetX; u16 m_OffsetY; s8 m_Width; s8 m_Height; s8 m_HorizontalOffsetBefore; s8 m_HorizontalOffsetAfter; s8 m_VerticalOffsetBefore;`

`Font : DBObj` (`acclient.h:4130`) also holds runtime-only members
(`m_pForegroundSurface`, `m_pBackgroundSurface`, `characterMap`) that are **not** serialized.

**Verified struct offsets** (from `DrawCharacter`'s raw field reads, which cross-check the
header): `Font+0x40 = m_NumHorizontalBorderPixels`, `Font+0x44 = m_NumVerticalBorderPixels`,
`Font+0x60 = m_pBackgroundSurface`. That fixes `sizeof(DBObj) == 0x30` and confirms the
field order above.

### 1.2 So: YES, the resource carries outline data — as a second glyph PLANE

`m_BackgroundSurfaceDataID` is a full second `RenderSurface` of the *same dimensions* as the
foreground, containing the same glyphs at the same `(OffsetX, OffsetY)` **dilated outward**.

**Measured** (scratchpad probe against the installed `client_portal.dat`; alpha bounding box
of each glyph inside its inflated window, i.e. `(OffsetX−hB, OffsetY−vB, W+2hB, H+2vB)`):

| Font | border | glyph | FG bbox in window | BG bbox in window |
|---|---|---|---|---|
| `0x40000000` | 4,4 | `A` (9×8) | `(4,4)-(12,11)` 9×8 | `(2,2)-(14,13)` **13×12** |
| `0x40000000` | 4,4 | `o` (5×5) | `(4,4)-(8,8)` 5×5 | `(2,2)-(10,10)` **9×9** |
| `0x40000001` | 4,4 | `W` (13×9) | `(4,4)-(16,12)` 13×9 | `(2,2)-(18,14)` **17×13** |
| `0x40000025` | 3,3 | `A` (6×6) | `(3,3)-(8,8)` 6×6 | `(1,1)-(10,10)` **10×10** |

The FG glyph always sits at exactly `(hB, vB)` inside the inflated window — i.e. the source
rect for the background plane is offset by exactly `−(hB, vB)` — and the BG glyph is the FG
glyph grown by **+2 px on every side**, uniformly, for every font measured. The border-pixel
value (3–6) is the *margin the atlas reserves*; the actual dilation is 2 px. Inflating the
blit by the full border is therefore correct and harmless (the ring beyond +2 is zero alpha).

Correlating evidence from the full font sweep (`0x40000000`–`0x40000032`, 49 fonts):
**every font that has a background atlas has `border >= 3`, and every font without one has
`border == 0`.** The first glyph row also begins at `OffsetY == vBorder` in bordered fonts
(`0x40000000` VB=4 → glyphs at `OffsetY=4`; `0x40000025` VB=3 → `OffsetY=3`) and at
`OffsetY == 0` in unbordered fonts (`0x40000021`). The margin exists precisely so the
inflated source rect stays in bounds.

All font atlases are `PFID_A8` (alpha-only, value 28 = `0x1C` — see §3.2).

### 1.3 Font inventory relevant to this report

| Font | MaxCharHeight | MaxCharWidth | Baseline | hB,vB | glyphs | fg / bg surface | atlas |
|---|---|---|---|---|---|---|---|
| `0x40000000` | 16 | 16 | 12 | 4,4 | 1050 | `0x06005EE5` / `0x06005EE6` | 1024×312 A8 |
| `0x40000001` | **18** | 19 | 14 | 4,4 | 1050 | `0x06005EE7` / `0x06005EE8` | 1024×361 A8 |
| `0x40000002` | 14 | 15 | 11 | 3,3 | 1050 | `0x06005ECF` / `0x06005ED0` | 1024×214 A8 |
| `0x40000025` | 11 | 13 | 9 | 3,3 | 1050 | `0x06005F08` / `0x06005F09` | 1024×184 A8 |
| `0x4000000E`…`0x40000014` | 24…48 | — | — | 4–6 | 210 | — | the decorative uncial "title" family |
| `0x40000017/18`, `0x40000021/22/23` | — | — | — | **0,0** | 20609 | fg only | CJK/unicode, **no outline plane** |

`0x40000000`/`0x40000001`/`0x40000002` are the same **bold serif** face at 16/18/14 px — the
classic AC UI face. Rendered proof (probe, font `0x40000001`, gold fill, black outline,
inflated bg pass) reproduces the user's screenshot exactly. The `0x4000000E`+ family is the
decorative celtic/uncial display face and is **not** what the user photographed.

### 1.4 How acdream reads it today — and what it drops

`src/AcDream.App/UI/UiDatFont.cs:93` `UiDatFont.Load`:
- reads `MaxCharHeight` → `LineHeight` ✅
- reads `BaselineOffset` → `BaselineOffset` ✅ (stored but never used — see §3.4)
- uploads `ForegroundSurfaceDataId` and `BackgroundSurfaceDataId` ✅
- builds the `char → FontCharDesc` map ✅
- **never reads `NumHorizontalBorderPixels` / `NumVerticalBorderPixels`** ❌

The reader exposes them: `DatReaderWriter.DBObjs.Font` has public fields
`NumHorizontalBorderPixels` and `NumVerticalBorderPixels` (verified by reflection over
`DatReaderWriter.dll` 2.1.7). A repo-wide grep for `BorderPixel` returns **zero** hits.

**Verdict for Q1:** the resource carries a dedicated outline plane plus the two border-pixel
scalars that make it usable. acdream loads the plane but drops the scalars, and therefore
cannot address the plane correctly.

---

## 2. THE TEXT STYLE MODEL

### 2.1 The element property table — `UIElement_Text::OnSetAttribute @ 0x0046a640`

The switch is **biased**: `switch (BaseProperty::GetPropertyName(arg2) - 0x14)` at
`0x0046a674`. Adding `0x14` back gives the real LayoutDesc property ids:

| Property id | Meaning | Handler |
|---|---|---|
| `0x14` | HorizontalJustification (enum) | `SetHorizontalJustification` |
| `0x15` | VerticalJustification (enum) | `SetVerticalJustification` |
| `0x16` | Editable (bool) | `SetEditable` |
| `0x17` | StringInfo — the text | `SetStringInfo` |
| `0x1A` | **FontDID array** | `DoFontReset` |
| `0x1B` | **FontColor array** | `DoFontReset` |
| `0x1C` | *(second DID array — no `OnSetAttribute` case)* | pull-based; see §2.3 |
| `0x1D` | **TagFontColor array** | `DoFontReset` |
| `0x1E` | MaxCharacters (int) | `m_glyphList.m_nMaxCharacters` |
| `0x1F` | NoIme (bool) | `SetNoIme` |
| `0x20` | OneLine (bool) | `SetOneLine` |
| **`0x21`** | **Outline (bool)** | **`SetOutline` @ `0x0046a81c`** |
| **`0x22`** | **OutlineColor (color)** | **`m_curOutlineColor` @ `0x0046a6bf`**, then `DoFontReset` |
| `0x23`/`0x24`/`0x25`/`0x26` | margL / margR / margU / margD (int) | `m_margL` … `m_margD` |
| `0x27` | Selectable (bool) | `SetSelectable` |
| `0x28` | TrimFromTop (bool) | `m_glyphList.m_bTrimFromTop` |
| `0x29` | FitToText (bool) | `SetFitToText` |
| `0xC7` | TruncateTextToFit | — |
| `0xCB` / `0xCC` | LoseFocusOnEscape / LoseFocusOnAcceptInput | — |

> **Correction to an existing acdream comment.** `src/AcDream.App/UI/UiRenderContext.cs:221`
> says the outline flag is "LayoutDesc property 0xd". That is the *switch case index*, not the
> property id. The authored property id is **`0x21`**; the outline colour is **`0x22`**.

### 2.2 Defaults — `UIElement_Text::UIElement_Text @ 0x00468570`

- `m_bitField = 0x300` (`0x00468 5eb`) → **bit `0x10` (outline) starts CLEAR**. Outline is
  opt-in per element.
- `m_curFontColor = RGBAColor_White`
- `m_curTagFontColor = RGBAColor_White`
- `m_curOutlineColor = RGBAColor_Black` (`0x004686cb`, packed from `RGBAColor_Black`)
- `m_eHorizontalJustification = 2`, `m_eVerticalJustification = 4`
- default font from `DBObj::GetByEnum(0x2e /*Font DBObj type*/, 9, 0x18)` with fallback
  `(0x2e, 9, 3)`.

`m_curOutlineColor` has exactly two writers in the whole binary: the ctor (black) and
property `0x22` (`0x0046a6bf`). **UNVERIFIED-adjacent but well-supported:** because no
element in the shipped DATs authors `0x22` on any text that matters here (see §2.5), the
effective outline colour everywhere is **pure black** — matching the user's screenshot.

### 2.3 Font/colour are ARRAYS with a runtime slot index

`UIElement_Text::SetFontDIDHelper @ 0x00466960` does
`vtable->InqProperty(0x1A) → array → element[arg4] → InqDataID → FontLocal::GetGlobalOrLocalFont(did)`.
`SetFontColorHelper @ 0x00466ac0` is the same for a colour array.

- `SetFontDIDNum(n)` @ `0x00468290` → `SetFontDIDHelper(0x1a, &m_curFontObj, n)`
- `SetFontColorNum(n)` @ `0x004682b0` → `SetFontColorHelper(0x1b, &m_curFontColor, n)` **and**
  `SetFontColorHelper(0x1d, &m_curTagFontColor, n)`
- `DoFontReset` @ `0x0046a560` → all three with index **0**
- `AppendStringInfoWithFont(info, fontNum, colorNum)` @ `0x00469de0` sets the slots then appends

So a single element can carry e.g. `0x1B = [white, green, red, yellow]` and code selects the
slot. The DAT sweep confirms multi-entry colour arrays exist
(`[white, green, red]` ×7, `[white, green, red, yellow]` ×2).

`0x1C` is authored as a DID array alongside `0x1D` TagFontColor on every "tag-capable" style
(e.g. style `0x10000372` authors `0x1C = [0x40000000]`, the same DID as its `0x1A`).
**UNVERIFIED:** most likely `TagFontDID` (the font used for the `[General]`-style tag run),
by symmetry with `0x1D` and because it has no `OnSetAttribute` case (pull-based, like
`0x1A`/`0x1B` are for the helpers). Cheapest resolution: grep `InqProperty(0x1c` in a fresh
Ghidra decompile of `GlyphList::AddText`/`UIElement_Text::AddText_Internal`.

### 2.4 State resolution — which colour is live

`UIElement::Initialize @ 0x00462c90`:
1. `SetState(m_desc.m_defaultState)`
2. then iterate `m_desc.m_properties` calling `OnSetAttribute` on each.

`UIElement::SetState @ 0x00464e70` re-derives the effective property collection
(`m_desc.m_properties` ⊕ `state.m_properties` ⊕ `m_instanceProperties`) for the OLD and NEW
state and re-fires `OnSetAttribute` for every property whose value **changed**. So a state
change re-drives font, colour, and the outline flag. If the requested state has no
`StateDesc`, `SetState` falls back to state 0 (the DirectState).

### 2.5 What the DATs actually author

All 101 `LayoutDesc`s live in `client_local_English.dat` only; all fonts live in
`client_portal.dat` (verified per-file — there is no duplicate-definition ambiguity).

**Global sweep for property `0x21`/`0x22`:** outlining is used sparingly and deliberately —
roughly 100 authored `0x21 = true` rows across ~15 layouts, and only **9** authored `0x22`
outline colours in the entire DAT set (values `ARGB(255,17,15,7)` and `ARGB(255,0,0,102)`).
Everything else inherits the black ctor default.

**Layout `0x2100003F` is retail's text style sheet** — 30+ `type 0x0C` style prototypes that
other layouts inherit through `BaseElement`/`BaseLayoutId`. The two that matter:

```
elem 0x10000372  (CHAT TRANSCRIPT STYLE)
  0x14 HJustify      = Enum(2)            -> Left
  0x15 VJustify      = Enum(4)            -> Bottom
  0x1A FontDID[]     = [0x40000000]       -> 16 px bold serif
  0x1B FontColor[]   = [ARGB(255,204,204,204)]
  0x1C               = [0x40000000]
  0x1D TagFontColor[]= [ARGB(255,0,178,0)]   (green)
  0x23 margL = 0, 0x25 margU = 0
  (states) Normal_rollover/Highlight -> white; Normal_pressed/Ghosted -> (51,51,51)
  *** NO 0x21 -> the chat transcript is NOT outlined in retail ***

elem 0x10000377  (SPEWBOX LINE STYLE)
  0x14 HJustify      = Enum(1)            -> Center
  0x15 VJustify      = Enum(1)            -> Center
  0x1A FontDID[]     = [0x40000001]       -> 18 px bold serif
  0x1B FontColor[]   = [white]
  0x23 margL = 0, 0x25 margU = 0
  (state Ghosted) 0x1B -> (76,76,76)
```

The gold + outline family (`0x10000382`–`0x10000388`) uses the decorative display fonts
`0x4000000E`–`0x40000014` with `0x1B = ARGB(255,255,242,127)` and `0x21 = true` — that is the
big centred announcement text, **not** the SpewBox.

### 2.6 The chat window — `LayoutDesc 0x2100006F`

Full tree walked. The transcript is element **`0x10000011`** (not `0x10000010`, which is its
`type 0x03` container panel):

```
/0x10000600/0x10000010/ elem 0x10000011 type 0x00000000 (UIElement_Text)
    base = element 0x10000372 in layout 0x2100003F     <-- the style above
    pos(16,0) size(368x73)
    own DirectState props: 0x23 margL = 2, 0x24 margR = 2, 0x27 Selectable = true,
                           0x51 = true, 0x72 = Enum(0x10000012), 0xCD = Enum(3)
    NO own 0x1A / 0x1B / 0x21 / 0x22
```

**Chat font truth:** face `0x40000000`, 16 px line height, baseline 12, **no outline**,
default fill `ARGB(255,204,204,204)`, tag colour green `(0,178,0)`, left-justified,
bottom-justified, 2 px left/right margin. Per-line colours come from
`ChatInterface`'s colour table stamped onto the glyph runs (already ported — see
`docs/research/2026-08-09-chat-retail-color-table.md`), with `(204,204,204)` as the element
default when a run carries none.

---

## 3. THE SHADOW/OUTLINE PASS

### 3.1 Two whole-string passes — `UIElement_Text::DrawSelf @ 0x00467aa0`

```
var_b0 = 1;
if (m_bitField & 0x10)      // SetOutline(true) / property 0x21
    var_b0 = 0;

if (var_b0 < 2) do {
    ... walk every glyph of the block ...
        if (var_b0 != 0)                        // FILL pass
            DrawCharacter(x, y, font, ch, glyph.color, 0x1000, m_curOutlineColor);
        else if (font->m_pBackgroundSurface == 0)   // OUTLINE pass, no bg plane
            for (j = -1; j <= 1; j++)
              for (k = -1; k <= 1; k++)
                if (k || j)
                    DrawCharacter(x+k, y+j, font, ch, m_curOutlineColor, 0x9000, 0xff000000);
        else                                     // OUTLINE pass, bg plane
            DrawCharacter(x, y, font, ch, glyph.color, 0x7000, m_curOutlineColor);
    ...
    cond = (var_b0 + 1) < 2;  var_b0 += 1;
} while (cond);                                  // 0x00467f6b / 0x00467f6e
```

Consequences:
- outline OFF → the loop runs **once** (pass 1, fill only);
- outline ON → the loop runs **twice**: pass 0 draws the outline for **the whole block**,
  pass 1 draws every fill on top. Fills therefore always sit above every neighbour's outline —
  interleaving per glyph (what acdream would do) lets glyph N+1's outline paint over glyph N's
  fill on tight kerning.
- retail has **two** outline mechanisms and picks by data: bg plane when the font has one,
  otherwise 8 neighbour blits of the *foreground* glyph at ±1 px. This is the same
  data-driven-dispatch shape as `feedback_retail_dispatch_is_data_driven`.

### 3.2 `SurfaceWindow::DrawCharacter @ 0x00442bd0` — flag bits

`DrawCharacter(dst, x, y, font, unicode, fgColor /*arg6*/, flags /*arg7*/, outlineColor /*arg8*/)`

| Bit | Effect | Site |
|---|---|---|
| `0x0001` | fixed-width advance = `maxCharWidth + 1` | `0x00442c2f` |
| `0x0002` | apply `m_BaselineOffset` | `0x00442c6f` |
| `0x0100` | `CopyAlpha` instead of a colour blit | `0x00442c80` |
| `0x1000` | proportional advance `hOffBefore + Width + hOffAfter`, glyph at `x + hOffBefore` | `0x00442c3a`–`0x00442c4a` |
| `0x2000` | **skip** the foreground plane | `0x00442dea` |
| `0x4000` | **draw** the background plane (also needs `m_pBackgroundSurface != 0`) | `0x00442d02` |
| `0x8000` | force the tint path (`SurfaceWindow::Color`) | `0x00442dc1` / `0x00442e65` |

So `0x7000` = bg-plane-only, proportional; `0x1000` = fill-only, proportional;
`0x9000` = fill-glyph tinted with the outline colour, proportional.

Both planes go through
`SurfaceWindow::Color(dst, src, Blit_4Alpha, colour)` whenever the surface format is
`0x1C` (`PFID_A8`) — which font atlases always are — so the A8 coverage is tinted by the
supplied colour. `arg8` tints the background plane; `arg6` tints the foreground plane.
**This is exactly acdream's shader model** (A8 → `(255,255,255,a)`, multiplied by the vertex
tint). The mechanism matches; only the gating and the rect do not.

### 3.3 The rect inflation — `CreateCharRectPair @ 0x00441480`

Foreground call (`0x00442cc0`) and background call (`0x00442d3a`) differ in exactly two
argument slots: the foreground passes `0` and `nullptr`; the background passes
`Font+0x40` (`m_NumHorizontalBorderPixels`) and `Font+0x44` (`m_NumVerticalBorderPixels`).

The body inflates BOTH the source sub-rect and the destination rect symmetrically by those
two values before clamping to the surface bounds:

```
dst.left = X - hB;  dst.top = Y - vB;  dst.right = X + W + hB;  dst.bottom = Y + H + vB;
src.left = Ox - hB; src.top = Oy - vB; src.right = Ox + W + hB; src.bottom = Oy + H + vB;
(then correlated clamping against the surface extents)
```

> BN's regparm reconstruction scrambles the parameter names in this function
> (`edx`/`ebx` come in as unassigned registers), so the *slot mapping* above is inferred from
> the call-site diff, not read literally. It is however **confirmed by measurement**: §1.2
> shows the background glyph's alpha bbox begins at `(hB−2, vB−2)` inside the inflated window
> and is `W+4 × H+4`, i.e. only an inflated rect can capture it, and the foreground glyph sits
> at exactly `(hB, vB)`.

### 3.4 Comparison with `UiRenderContext.DrawStringDat`

`src/AcDream.App/UI/UiRenderContext.cs:226–293`.

| Retail | acdream today | Verdict |
|---|---|---|
| Two whole-block passes (outline block, then fill block) | one loop, outline+fill interleaved per glyph | ⚠️ differs on tight kerning |
| Outline gated by `m_bitField & 0x10` ← property `0x21` | gated by a `bool outline = false` parameter | mechanism present |
| Outline enabled on the elements that author `0x21` | **no production call site ever passes `outline: true`** | ❌ **outline never drawn** |
| Outline colour = `m_curOutlineColor` (black default, property `0x22`) | hard-coded `new Vector4(0,0,0,color.W)` (line 249) | ✅ correct in practice |
| bg source rect = `(Ox−hB, Oy−vB, W+2hB, H+2vB)`, dest inflated to match | bg source rect = `(Ox, Oy, W, H)`, dest **not** inflated (lines 274–279) | ❌ **outline invisible even if enabled** |
| Fallback: 8 neighbour blits when the font has no bg plane | none | ❌ missing (matters for the 0-border fonts) |
| Advance `hOffBefore + W + hOffAfter` | `UiDatFont.GlyphAdvance` — identical | ✅ |
| Glyph at `x + hOffBefore`, `y + vOffBefore`, integer line baseline | identical (lines 247–260) | ✅ |
| A8 × tint | A8 → white+alpha × vertex tint | ✅ |

**Rendered proof** (probe, font `0x40000001`, "You can't jump while in the air", gold on a
grass-toned backdrop):
- `outline: false` (acdream today) → flat glyphs, no border.
- `outline: true`, **not** inflated → visually indistinguishable from no outline; the only
  artifact is a single dark pixel where a descender pokes out. The fill covers the whole
  un-inflated bg rect.
- `outline: true`, **inflated by the border pixels** → the heavy black border the user
  photographed.

**Verdict for Q3:** same mechanism, two independent defects. Enabling the flag alone would
change nothing visible. Both the flag *and* the rect inflation are required.

### 3.5 One more retail detail acdream does not implement

`0x0002` (`use m_BaselineOffset`) — `UiDatFont.BaselineOffset` is loaded and stored but never
read by any draw path. Retail's `DrawSelf` glyph loop does not set `0x0002`, so the transcript
and SpewBox paths are unaffected; leave it. Noted so the field is not mistaken for a gap.

---

## 4. THE SPEWBOX — resolved, not a placeholder any more

**The earlier CH finding that element `0x1000004A` / layout enum `0x10000012` is "absent from
both dats" is WRONG.** It is present. It was missed for two reasons, both mechanical: the
element is a **root** of its layout (so a children-only walk skips it), and its font/colour
live in a **BaseElement in a different LayoutDesc** plus a **named state**, not in its own
DirectState.

### 4.1 Runtime path — `gmSpewBoxUI`

- `gmSpewBoxUI::Register @ 0x004d5dd0` → `RegisterElementClass(0x10000016, Create)`.
- `gmSpewBoxUI::PostInit @ 0x004d5ab0` → `SetShouldEraseBackground(1)`, `SetMouseVisible(0)`,
  `GetChildRecursive(0x10000049)` → the ListBox, reads its property `0x10000028` into
  `m_maxConcurrentItems` (default 1 if absent), `RegisterForGlobalMessage(3)`,
  `RegisterNoticeHandler(0x186b6)`.
- `gmSpewBoxUI::RecvNotice_DisplayFinalStringInfo @ 0x004d60a0` — accepts only
  **`arg2 == 0x1a`** (the client-local / interface-text `LogTextType`) and queues the
  `StringInfo`.
- `gmSpewBoxUI::ListenToGlobalMessage @ 0x004d6090` → on global message 3, `Update`.
- `gmSpewBoxUI::Update @ 0x004d5df0`:
  `UIElementManager::CreateChildElementByEnum(s_pInstance, nullptr, 0x10000012, 0x1000004a)`
  → `DynamicCast(0xC)` → `SetText(trimmed)` → `ResizeTo(listBox.width, h)` →
  `RecalculateGlyphList` → dedup against item 0 → `InsertItem(item, 0)` → delete item
  `m_num-1` when over `m_maxConcurrentItems` → `ScrollToShow(0)`.

acdream's `SpewBoxController` already mirrors the tick source, newest-on-top ordering, and
the 4-item cap correctly.

### 4.2 The authored line template — `LayoutDesc 0x21000011` (client_local_English.dat)

```
/ elem 0x1000004A  type 0x00000000 (UIElement_Text)
    base = 0x10000377 in layout 0x2100003F
    size 450 x 18            <-- exactly Font 0x40000001's MaxCharHeight
    DefaultState = 0x10000002   (its only state)
    [DirectState]      0x14 HJustify = Enum(1)      -> Center
                       0x15 VJustify = Enum(1)      -> Center
    [state 0x10000002] 0x1B FontColor[] = [ARGB(255,255,0,0)]   <-- RED
                       0x21 OUTLINE    = true                    <-- OUTLINE ON
                       0x23 margL = 5
                       0x24 margR = 5
    inherited from 0x10000377:
                       0x1A FontDID[]  = [0x40000001]            <-- 18 px bold serif
    outline colour: NOT authored anywhere -> ctor default = BLACK

/ elem 0x10000048  type 0x10000016 (gmSpewBoxUI)
    size 450 x 72, edges L3 T1 R3 B2, pos (0,0), ROOT of the layout
    (L3/R3 = "centered" per ElementReader.ToAnchors; T1 = top-anchored)
    [DirectState] 0x3B = Bool(false)

/0x10000048/ elem 0x10000049 type 0x00000005 (ListBox)
    size 450 x 72, DefaultState = Ghosted
    0x10000028 MaxConcurrentItems = 4
```

Three independent cross-checks that the font is `0x40000001`:
1. the base style `0x10000377` authors `0x1A = [0x40000001]` directly;
2. the line template's authored height is **18 px** and `0x40000001`'s `MaxCharHeight` is
   **18**;
3. 4 items × 18 px = **72 px** = the authored box height.

**Position is now derived, not guessed.** `0x10000048` is a ROOT element of its layout, so its
parent is the viewport: `pos(0,0)`, `L3/R3` centred, `T1` top-anchored ⇒ a 450×72 block
horizontally centred, flush to the top of the screen. That is exactly what
`SpewBoxController` does today (`TopOffset = 0`, per-frame recentre) — the user-directed
placement turns out to be the authored one. Register row AP-178's position entry can be
retired.

### 4.3 The colour — the ONE unresolved conflict

- **DAT/decomp says:** `ARGB(255,255,0,0)` — pure red — because `DefaultState` is
  `0x10000002` and `UIElement::Initialize` applies that state before the properties. This is
  also *consistent* with retail's chat colour table, where `LogTextType 0x1A` (the only type
  the SpewBox accepts) maps to `colorBrightRed (1,0,0,1)`
  (`docs/research/2026-08-09-chat-retail-color-table.md`, row `0x1A`).
- **The user says:** golden/amber, and pinned yellow `#FFFF3F` live at CH round 1.

**UNVERIFIED — do not "fix" the colour off this document.** Two things could reconcile it,
and I cannot separate them statically:
1. The ListBox (`DefaultState = Ghosted`) may propagate its state to inserted items via
   `StateDesc::m_bPassToChildren` (`UIElement::SetState @ 0x00464ebf`/`0x00464ec6`). If the
   item is moved out of `0x10000002`, `SetState` re-fires `OnSetAttribute` for the changed
   keys and the colour reverts toward the base (white / Ghosted grey) — and the outline flag
   would go with it, which contradicts the screenshot, so this is unlikely but not excluded.
2. A large part of "gold vs yellow" is **the outline itself**. Rendering `#FFFF3F` at 18 px
   with the black border eats the glyph edges and reads distinctly warmer/goldener than the
   same `#FFFF3F` drawn flat. Probe images of `#FF0000`, `#FFFF3F`, `#FFF27F`, `#D2D264` and
   `#FFFFFF` at font `0x40000001` with the correct outline show `#FFFF3F`-with-outline
   matching a "golden/amber" description well, and `#FF0000` matching it not at all.

**Cheapest resolution, in order:**
- (a) Show the user the four probe renders side by side and let them point at one — zero cost,
  and their eye is the acceptance test anyway.
- (b) If that is ambiguous, cdb one-liner against live retail:
  `bp acclient!UIElement_Text::DrawSelf ".if (@@c++(((UIElement_Text*)@ecx)->m_bitField & 0x10)) { .printf \"col=%08x outline=%08x\\n\", @@c++(((UIElement_Text*)@ecx)->m_curFontColor), @@c++(((UIElement_Text*)@ecx)->m_curOutlineColor) }; gc"`
  then trigger a jump-in-air refusal. That reads the live `m_curFontColor` directly.

**Recommendation meanwhile:** keep the user-pinned yellow (it is already a passed user gate),
and land the *face + size + outline*, which are unambiguous. Re-open colour only if the user
still flags it after the outline lands.

### 4.4 Answering "is there ANY on-screen text with authored style"

Yes — the SpewBox line template above is exactly that, and it is the only one of its kind.
The other authored-outline on-screen families are the big centred announcement styles
(`0x10000382`–`0x10000388`, decorative fonts `0x4000000E`–`0x40000014`, gold
`ARGB(255,255,242,127)`), which are a different surface. There is no separate authored
"wait cue"/ECM display-string element — Campaign CH already routed the portal wait cue through
the SpewBox, which the decomp supports (notice type `0x1A` is the only inbound channel).

---

## 5. ACDREAM GAP LIST + FIX PLAN

### 5.1 Where each attribute comes from today

**Chat transcript**

| Attribute | acdream today | Retail | Match? |
|---|---|---|---|
| Face | `0x40000000` — `InteractionRetainedUiComposition.cs:572` (`UiDatFont.Load` default `UiDatFont.DefaultFontId` = `0x40000000`) → `RetailUiRuntime.cs:843` → `ChatWindowController.cs:293` `Transcript.DatFont = datFont` | `0x40000000` via base style `0x10000372` prop `0x1A` | ✅ |
| Size | 16 px (`UiDatFont.LineHeight` = `MaxCharHeight`) | 16 px | ✅ |
| Per-line colour | `UiText.Line.Color` from the ported chat colour table | glyph-run colour from `ChatInterface` | ✅ |
| Default colour | `UiText.DefaultColor = Vector4.One` (`UiText.cs:77`) | `ARGB(255,204,204,204)` | ❌ shade too bright |
| Tag colour | none | `0x1D = (0,178,0)` green + `0x1C` tag font | ❌ missing |
| Outline | never drawn (`UiText.cs:562`, `:605`, `:428`, `:450`, `:471` all call `DrawStringDat` with the default `outline: false`) | style `0x10000372` authors **no** `0x21` | ✅ **correct — chat must stay un-outlined** |
| Margins | `UiText.Padding`, not read from the DAT | element `0x10000011` authors `0x23`/`0x24` = 2 | ⚠️ minor |
| Justification | `HJustify`/`VJustify` from `0x14`/`0x15` (`ElementReader.cs:339+`) | Left / Bottom via base | ✅ (inherited through `Merge`) |

**SpewBox**

| Attribute | acdream today | Retail | Match? |
|---|---|---|---|
| Face | `0x40000025` — `SpewBoxController.cs:121` | **`0x40000001`** (base style `0x10000377` prop `0x1A`) | ❌ wrong font |
| Size | 11 px line | **18 px** line (and the authored line box is 18 px tall) | ❌ far too small |
| Fill colour | `(1,1,0.247,1)` — `SpewBoxController.cs:184` | authored `(255,0,0)`; user-observed gold/yellow | ⚠️ see §4.3 |
| Outline | none | **`0x21 = true`**, colour black | ❌ **the reported "shading"** |
| Position | centred, `TopOffset = 0` — `SpewBoxController.cs:137` | centred (edges L3/R3), top-anchored (T1), root-of-layout ⇒ viewport top | ✅ now *derived* |
| Extent | 450×72 — `SpewBoxController.cs:164-165` | 450×72 | ✅ |
| Max items | 4 | `0x10000028 = 4` | ✅ |
| Margins | none | `0x23`/`0x24` = 5 | ⚠️ minor |

**Shared plumbing**

| Gap | Site |
|---|---|
| `NumHorizontal/VerticalBorderPixels` never read | `UiDatFont.cs:93-127` (`Load`), no field on `UiDatFont` |
| Background sub-rect not inflated | `UiRenderContext.cs:274-279` |
| Outline never enabled | `UiRenderContext.cs:226` default `outline = false`; zero production callers pass `true` |
| Property `0x21` (outline) / `0x22` (outline colour) not imported | `ElementReader.cs:339-386` reads only `0x1A`, `0x14`, `0x15`, `0x1B`; `LayoutImporter.cs:499-560` likewise |
| No 8-neighbour fallback for 0-border fonts | `UiRenderContext.DrawStringDat` |
| Outline drawn per glyph, not per block | `UiRenderContext.DrawStringDat` loop |
| Stale comment: "LayoutDesc property 0xd" | `UiRenderContext.cs:221` |

### 5.2 Fix plan

**Fix 1 — `UiDatFont` carries the border pixels.** Add
`public int BorderX { get; }` / `BorderY { get; }` populated from
`font.NumHorizontalBorderPixels` / `NumVerticalBorderPixels` in `UiDatFont.Load`
(`UiDatFont.cs:93`). Cite `Font::Serialize @ 0x00443650`. Pure additive; no behaviour change
until Fix 2.

**Fix 2 — `DrawStringDat` blits the background plane with the inflated rect.**
In `UiRenderContext.cs:272-280`, when the outline pass runs use
source `(g.OffsetX - BorderX, g.OffsetY - BorderY, g.Width + 2*BorderX, g.Height + 2*BorderY)`
and destination `(gx - BorderX, gy - BorderY, same size)`. Cite
`SurfaceWindow::DrawCharacter @ 0x00442d3a` + `CreateCharRectPair @ 0x00441480`.
**Fixes 1 and 2 must land together** — either alone is a no-op or a regression.

**Fix 3 — restructure `DrawStringDat` into two whole-string passes.** When `outline` is set,
loop the string once emitting only outline quads, then again emitting only fill quads. Cite
`UIElement_Text::DrawSelf @ 0x00467f6b`. Low risk, and it removes the tight-kerning artifact.
Optional in the same commit: the 8-neighbour `±1` fallback when
`font.BackgroundTexture == 0` (cite `0x00467d7e`–`0x00467e14`), needed only if a 0-border font
(`0x40000017/18/21/22/23`, `0x4000001A`, `0x4000001D`–`0x40000020`, `0x40000030/31`) is ever
used for outlined text. Not currently reachable — file it rather than build it if scope is tight.

**Fix 4 — SpewBox: face + size + outline.** In `SpewBoxController.cs`:
- `RetailFontId` `0x40000025` → **`0x40000001`** (three independent cross-checks in §4.2);
- pass `outline: true` for this element's text. Cleanest seam: add
  `public bool Outline { get; set; }` to `UiText` and forward it into the `DrawStringDat`
  calls at `UiText.cs:428/450/471/562/605`, then set `Outline = true` on the SpewBox `UiText`.
- rewrite the class remarks: position and extent are now **authored** (`0x21000011`
  element `0x10000048`), and the font is **authored** (`0x2100003F` element `0x10000377`).
  Retire the AP-178 rows for position and font; keep a colour row pending §4.3.
- optional: 5 px left/right margin from `0x23`/`0x24`.

**Fix 5 — chat transcript default shade + tag colour.** Set the transcript's
`UiText.DefaultColor` to `(204/255, 204/255, 204/255, 1)` from style `0x10000372` prop `0x1B`,
and leave the outline OFF (retail authors none). File the `0x1D` tag colour `(0,178,0)` and
the `0x1C` tag font as a separate follow-up — it needs a per-run tag concept that
`UiText.Line` does not have yet.

**Fix 6 — import `0x21`/`0x22` properly.** Add `Outline` (bool, prop `0x21`) and
`OutlineColor` (colour, prop `0x22`, default black) to `ElementInfo` +
`ElementReader.ApplyCanonicalLegacyProjection` + `LayoutImporter.ReadState`, with the same
"derived wins" merge rule as `FontDid`, and have `DatWidgetFactory` push them onto the built
`UiText`. That makes every authored-outline element in the DAT (~100 rows across 15 layouts)
correct at once instead of one controller at a time. Correct the stale
`UiRenderContext.cs:221` comment to property `0x21`/`0x22` in the same commit.

**Suggested order:** 1+2 (mechanism) → 4 (the surface the user is looking at) → 5 → 6 → 3.
Fixes 1+2+4 alone should reproduce the screenshot.

### 5.3 Divergence-register bookkeeping

- **Retire:** AP-178's *position* and *extent* placeholders (both are authored and already
  matched), and its *font* placeholder once Fix 4 lands.
- **Add:** a row for the chat transcript's missing tag-colour/tag-font (`0x1D`/`0x1C`) until
  Fix 5's follow-up lands.
- **Add:** a row for the missing 8-neighbour outline fallback if Fix 3's optional half is
  deferred.
- **Keep, rewritten:** the AP-178 *colour* row — now "authored `(255,0,0)` for state
  `0x10000002`; acdream ships the user-pinned yellow pending the §4.3 resolution."

---

## Appendix — probe method (reproducible)

A throwaway .NET 8 console referencing `Chorizite.DatReaderWriter` 2.1.7 + `SixLabors.ImageSharp`,
run against `%USERPROFILE%\Documents\Asheron's Call`. It (a) sweeps `Font 0x40000000`–`0x40000040`
printing every serialized field plus the fg/bg `RenderSurface` dimensions and format,
(b) walks every `LayoutDesc` root and child recursively across all four DATs printing each
`ElementDesc`'s `BaseElement`/`BaseLayoutId`, `DefaultState`, and every `StateDesc` property
(DirectState **and** named states) by id, (c) measures per-glyph alpha bounding boxes in both
atlases inside the inflated window, and (d) composites sample strings with the retail two-pass
model to PNG. Nothing was written into the repo tree. The three walk features the earlier CH
sweep lacked — **root elements**, **`BaseElement`/`BaseLayoutId` inheritance**, and
**named-state properties** — are exactly what turned `0x1000004A` from "absent" into fully
specified.