# Sources > The documents each sequence page cites, and how the citations link to them. Every sequence page lists where the sequence is defined. Each citation names the section and the printed page, and links straight to that page of a scan. Some sequences are missing from some of these documents, and that is informative too: CBT and CHT are not in DEC STD 070, and nothing here defines the window title except xterm. ## ECMA-48 *Control Functions for Coded Character Sets*, 5th edition, June 1991. This is the standard that defines the control functions themselves and their encoding: what `CSI Pn D` means, independent of any terminal. Ecma contributed this edition to ISO/IEC to become the third edition of ISO/IEC 6429. Its names sometimes differ from the ones terminals use: CUB is *Cursor Left*, ED is *Erase in Page*, HT is *Character Tabulation* and RI is *Reverse Line Feed*. Read it [at the Internet Archive](https://archive.org/details/ecma-48-5th-edition-june-1991). Ecma also publishes it [on its own site](https://ecma-international.org/publications-and-standards/standards/ecma-48/). ## DEC STD 070 *Video Systems Reference Manual*, Rev H, December 1991. This is Digital's internal standard for its VT terminals. For each control function it gives the format and the default, the state the function touches, notes on the edge cases, and an algorithm in pseudo-code. It is the most precise of these on behavior at the margins. Every citation here is to section 5, *Character Cell Display*, whose pages are numbered `5-1` onwards, except DECALN, which appears only in Appendix D, *Documented Exceptions*. Read it [at the Internet Archive](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381). It was marked *Digital Internal Use Only*. This scan is bitsavers'. ## VT220 Programmer Reference Manual Digital's programmer manual for the VT220, second edition, August 1984 (EK-VT220-RM-002). The VT220 is the terminal libghostty-vt identifies itself as, and this manual describes the level 2 functions it has: the C0 and C1 controls, character sets, modes, editing and erasing, reports and resets. It groups related functions into one section, such as *Cursor Positioning* or *Erasing*, so a page cites the section rather than a page of its own. VT100.net [reproduces it online](https://vt100.net/docs/vt220-rm/), and the sequence pages link to the section there. ## VT510 Video Terminal Programmer Information Digital's programmer manual for the VT510, first edition, November 1993. This is what a programmer outside Digital was told. It describes the terminal as it was built rather than as the standard required, and gives the control characters in one table rather than one by one. VT100.net [reproduces it online](https://vt100.net/docs/vt510-rm/), and the sequence pages link there. ## VT330/VT340 Programmer Reference Manual, Volume 2 *Graphics Programming*, second edition, May 1988 (EK-VT3XX-GP-002). The VT330 and VT340 were Digital's graphics terminals, and this volume is the one about their graphics: ReGIS in its first thirteen chapters and sixels in the fourteenth. The sixel, ReGIS and DECSDM pages cite it, since none of the documents above describes either. VT100.net [reproduces it online](https://vt100.net/docs/vt3xx-gp/), and the pages link there. ## xterm Where the documents above say nothing, a page may cite what xterm does. Those citations link to its source, [xterm-snapshots](https://github.com/ThomasDickey/xterm-snapshots) at the tag `xterm-411a`, and to its own [Control Sequences](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html) document. esctest2, the test suite for xterm's behavior, is cited by test name. ## The Support table Each sequence page ends its prose with a table of the terminals this site has examined, and whether each has the sequence: *Yes*, *Partly*, or *No*, with a note. The VT220 and the VT510 are judged by their manuals alone, so *No* there means the manual does not describe it; both manuals set out everything the terminal receives. The VT340 appears only on the graphics pages, judged by its graphics manual. xterm is a default xterm, as everywhere on this site, and libghostty-vt is what the cases show. ConEmu is judged by its [list of the sequences it supports](https://conemu.github.io/en/AnsiEscapeCodes.html), and Konsole, which documents none, by its source, on the OSC and graphics pages. Others, such as kitty or iTerm2, appear where a page draws on their documentation. The Version column says what each was checked against: the edition of a manual, the release or commit of a terminal's source, or the release its documentation described when it was read. libghostty-vt's is the Ghostty revision the cases run against. A row whose version says *run in a VM* was measured rather than read: every case on this site was run in that terminal in a virtual machine, and the row follows from the results. *Run as a library* is the same for an emulator that is a library, pyte, xterm.js run headless, alacritty_terminal or VTE, whose screen can be read directly. Only the cases that show the function working as specified, and that could be checked in full, count, so a terminal that differs from xterm where terminals may legitimately differ is not marked down for it. *Yes* means it passes all of them, *Partly* some, *No* none, and the link leads to the results. ## When the sources disagree They often do, and so do they with what terminals actually do. Where DEC STD 070 and xterm disagree, the cases follow xterm, bugs included, and the page says what DEC STD 070 asks for instead. That is Ghostty's own policy: the first of the principles it states for its terminal features is xterm compatibility, because "xterm is the de facto standard for terminal emulation. If xterm does something, we should do the same thing" ([Ghostty's features page](https://ghostty.org/docs/features#terminal-%28vt%29-features)). "xterm" here means a default xterm: built by `configure` with no options, running with its default resources, which makes it a VT420. That includes what it ignores. Where a default xterm ignores a function, because its parse table drops the sequence or because the function is built only into a non-default configuration such as `--enable-status-line` or `--enable-dec-locator`, the cases expect the function to be ignored, and the page describes what DEC STD 070 or ECMA-48 would have it do. If libghostty-vt implements such a function, its cases are known differences. ## How the links find a page The Internet Archive numbers the pages of a scan from 0, whatever is printed on them. ECMA-48's printed page *N* is the scan's page *N* + 13. DEC STD 070 is a binder of separately numbered sections, so each citation also records its page of the PDF, and the scan's page is one less than that. Each linked page was checked against the scan. --- This is the Markdown version of . On that page every validation case runs live in libghostty-vt, the terminal emulation core of Ghostty, compiled to WebAssembly.