# Dynamically Redefinable Character Set (DECDLD)

> Load the glyphs of a soft character set, which can then be designated like any other.

- **Sequence:** `DCS Pfn ; Pcn ; Pe ; Pcmw ; Pss ; Pu ; Pcmh ; Pcss { Dscs Sxbp1 ; … ; Sxbpn ST`
- **DEC STD 070:** [§10, ch. 4 Down Line Load (Font File), p. 5](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n943/mode/1up)
- **VT220:** [§4.16 Down-Line-Loadable Character Set](https://vt100.net/docs/vt220-rm/chapter4.html#S4.16)
- **VT510:** [DECDLD—Dynamically Redefinable Character Sets](https://vt100.net/docs/vt510-rm/DECDLD.html)

DECDLD is a [device control string](https://control-codes.page/esc/dcs/index.html.md) that loads glyphs into a
*dynamically redefinable character set* (DRCS), a soft font. The parameters
say which font buffer to load, the first character in it to load, the size
of the character cell, and whether the set has 94 or 96 characters. The
string starts with `Dscs`, the intermediate and final bytes that will name
the set when it is designated with [SCS](https://control-codes.page/c0/so/index.html.md), and then gives one
sixel bitmap per character, separated by `;`. DEC STD 070 defines DECDLD in
its DRCS extension, chapter 4, from
[p. 5](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n943/mode/1up),
for level 2 and above.

DEC STD 070 is explicit about what DECDLD leaves alone: "The DECDLD control
does not clear the screen", though characters from the set that are already
on the screen may change to the new glyphs. Its notes on
[p. 6](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n944/mode/1up)
say which resets keep the loaded set: "A Soft Reset function (DECSTR) does
not erase font files loaded by the DECDLD command", and RIS does.

xterm accepts DECDLD at level 2 and above
([`misc.c`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/misc.c#L5374-L5378)),
but in a default build it does nothing with it. Its `parse_decdld` exists
only in a trace build, where it writes the glyphs to the trace log and loads
nothing; every other build defines it away
([`misc.c`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/misc.c#L4481-L4593)):

```c
#define parse_decdld(p,q)	/* nothing */
```

and soft fonts are off unless xterm is configured for them
([`ptyx.h`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/ptyx.h#L608-L609)).
So a default xterm consumes DECDLD and loads nothing, and the cases follow
it, as the [sources](https://control-codes.page/sources/index.html.md) page explains. The case runner sees which characters are in the cells and not how
they are drawn, so the cases check what can be seen that way: that the
string is consumed, and that the screen is left as it was.

## Not in libghostty-vt

libghostty-vt has no soft fonts. Its DCS handler in `dcs.zig` recognizes
tmux control mode, XTGETTCAP (`DCS + q`) and DECRQSS (`DCS $ q`), and drops
every other device control string, DECDLD included. Both cases pass because
dropping the string is all they can observe.

## Validation

### DECDLD-1: The font is not displayed

Input, one step per line:

```text
\eP1;1;1{\x20@~~~~~~~~/????????;????????/~~~~~~~~\e\\   # two glyphs
X
```

Expected screen:

```text
|X____|
cursor 1,2
reply none
```

### DECDLD-2: The screen is not cleared

Input, one step per line:

```text
AB
\eP1;1;1{\x20@~~~~~~~~/????????\e\\
C
```

Expected screen:

```text
|ABC__|
|_____|
cursor 1,4
```

---

This is the Markdown version of <https://control-codes.page/dcs/decdld/>. On that page every validation case runs live in libghostty-vt, the terminal emulation core of Ghostty, compiled to WebAssembly.

The validation cases are written in the notation described in <https://control-codes.page/notation/index.html.md>.