| 1 | Terminal Emulator Multimedia Standard - Proposed Design |
| 2 | ======================================================= |
| 3 | |
| 4 | Version: 1 |
| 5 | |
| 6 | |
| 7 | |
| 8 | Purpose |
| 9 | ------- |
| 10 | |
| 11 | Multiple standards exist to incorporate image data in text-based |
| 12 | terminals and terminal emulators. Few standards have wide adoption |
| 13 | despite frequent user requests for these features and hardware support |
| 14 | for several of the standards. |
| 15 | |
| 16 | A group including developers of several widely-used terminal emulators |
| 17 | has been working on defining the needs and limitations for a standard |
| 18 | that can be implemented in current-gen terminal emulators. The |
| 19 | discussion has been primarily captured here: |
| 20 | https://gitlab.freedesktop.org/terminal-wg/specifications/issues/12 |
| 21 | |
| 22 | This document collects many of the reported desires and practical |
| 23 | constraints of that discussion into a proposed standard that |
| 24 | encompasses three independent new features: |
| 25 | |
| 26 | 1. A method to transfer multimedia data for immediate display within |
| 27 | the screen cell grid ("Direct Multimedia"). |
| 28 | |
| 29 | 2. A method to transfer multimedia data to a terminal-managed cache, |
| 30 | and later display that data within the screen cell grid ("Cached |
| 31 | Multimedia"). |
| 32 | |
| 33 | 3. A method to assign cell data to different layers with options for |
| 34 | both layer and cell transparency ("Layers"). |
| 35 | |
| 36 | A terminal may implement any combination of these features |
| 37 | independently of each other. If all features are supported, then all |
| 38 | of the design goals outlined in this document can be met. |
| 39 | |
| 40 | The same mechanisms that can put raster-based images on the screen are |
| 41 | also readily generalizable to other media types such as vector-based |
| 42 | images and animations. This document is thus a "multimedia" proposal |
| 43 | rather than a "simple images" proposal. |
| 44 | |
| 45 | |
| 46 | |
| 47 | Acknowledgements |
| 48 | ---------------- |
| 49 | |
| 50 | This proposal has been informed from the following prior work: |
| 51 | |
| 52 | * DEC VT300 series sixel graphics standard: |
| 53 | https://vt100.net/docs/vt3xx-gp/chapter14.html |
| 54 | |
| 55 | * iTerm2 image protocol: |
| 56 | https://iterm2.com/documentation-images.html |
| 57 | |
| 58 | * Kitty image protocol: |
| 59 | https://sw.kovidgoyal.net/kitty/graphics-protocol.html |
| 60 | |
| 61 | * Jexer Terminal User Interface: |
| 62 | https://gitlab.com/klamonte/jexer |
| 63 | |
| 64 | |
| 65 | |
| 66 | Design Goals - Core |
| 67 | ------------------- |
| 68 | |
| 69 | The core ("must-have") design goals are: |
| 70 | |
| 71 | * Be easy to implement in existing terminals and applications: |
| 72 | |
| 73 | - Sacrifice "10%" of potential function to eliminate "90%" of |
| 74 | implementation pain. "Less is more." |
| 75 | |
| 76 | - Be a strict superset of the existing iTerm2 and DEC sixel image |
| 77 | solutions. One should be able to take an existing terminal or |
| 78 | application that emits/consumes iTerm2 or sixel sequences, and |
| 79 | only change the control sequence introducer/termination to achieve |
| 80 | the same effect as a terminal/application that conforms with this |
| 81 | standard. |
| 82 | |
| 83 | * Have no ambiguity. If two terminal or application developers can |
| 84 | read this document and reach different conclusions on what should be |
| 85 | on the screen, then an error exists in this document that must be |
| 86 | corrected. |
| 87 | |
| 88 | - Every feature must be straightforward to validate via automated |
| 89 | unit testing. |
| 90 | |
| 91 | - Every conformant terminal must produce the same output (pixels on |
| 92 | screen) given the same input (terminal font, terminal sequences). |
| 93 | |
| 94 | - Every option must have a defined default value. |
| 95 | |
| 96 | - Erroneous sequences must have defined expected results. |
| 97 | |
| 98 | - Every operation must act atomically: either everything worked |
| 99 | (image is on screen, cursor has moved, terminal state has changed, |
| 100 | etc.) or nothing did. |
| 101 | |
| 102 | * Integrate with existing ECMA-48 / ANSI X3.64 defined sequences: |
| 103 | |
| 104 | - Operations on Tiles/Cells containing text will have the same |
| 105 | effect when applied to Tiles/Cells containing image data. |
| 106 | |
| 107 | - Existing sequences are given new parameters to cover needed |
| 108 | features rather than entirely new sequences introduced. |
| 109 | |
| 110 | * Be straightforward to implement in non-"physical" terminals, |
| 111 | including: |
| 112 | |
| 113 | - Future versions of terminal control libraries such as ncurses and |
| 114 | termbox. |
| 115 | |
| 116 | - Terminal multiplexers that support "headless" terminals (no |
| 117 | physical screen) and "multi-head" terminals (many different |
| 118 | physical screens). |
| 119 | |
| 120 | * Be platform-agnostic, and easy to implement on (at the least): |
| 121 | POSIX, Windows, and web. |
| 122 | |
| 123 | - All features must be available even if the only means of |
| 124 | communication between the application and terminal is control |
| 125 | sequences (e.g. no shared disk, no shared memory, no shared DOM, |
| 126 | etc.). |
| 127 | |
| 128 | * Support graceful fallback: |
| 129 | |
| 130 | - Terminal emulators and physical terminals that do not support this |
| 131 | standard should remain usable with no undefined screen artifacts, |
| 132 | even when the application blindly emits these sequences to those |
| 133 | terminals. |
| 134 | |
| 135 | - This standard must able to be versioned for future enhancements. |
| 136 | |
| 137 | - An application must be able to detect that its terminal supports |
| 138 | this standard, and at what version. |
| 139 | |
| 140 | * Support secure programming practices: |
| 141 | |
| 142 | - Applications must not be able to obtain unauthorized data from |
| 143 | terminal memory, such as: images emitted by other applications |
| 144 | still present in the terminal's scrollback buffer, terminal or |
| 145 | system memory limits. |
| 146 | |
| 147 | - Applications must not be able to compromise the terminal through |
| 148 | denial-of-service such as: excessive memory usage, unterminated |
| 149 | control sequences. Similarly, terminals must not be able to |
| 150 | compromise application through their responses to application |
| 151 | queries. |
| 152 | |
| 153 | - Applications must not be able to manipulate the terminal into |
| 154 | performing an insecure operation such as: reading arbitrary shared |
| 155 | memory regions, reading arbitrary files on disk, deleting |
| 156 | arbitrary files on disk, etc. Similarly, terminals must not be |
| 157 | able to manipulate applications into performing insecure |
| 158 | operations. |
| 159 | |
| 160 | - This standard must be implementable when the terminal has a fixed |
| 161 | maximum memory, such as a kernel-level device driver. |
| 162 | |
| 163 | |
| 164 | |
| 165 | Design Goals - Secondary |
| 166 | ------------------------ |
| 167 | |
| 168 | The secondary ("nice-to-have") design goals are listed below. These |
| 169 | might not all be possible, but will kept in mind: |
| 170 | |
| 171 | * Minimal redundant network traffic for on-screen data that is |
| 172 | repeated: either on screen in multiple places, or in the same place |
| 173 | but refreshed multiple times. |
| 174 | |
| 175 | * Asynchronous notification from terminal to application that the |
| 176 | screen has been changed by outside or user action. Examples: font |
| 177 | change, session detach/attach, user changed image preferences. |
| 178 | |
| 179 | * The ability for a multiplexer to "pass-thru" the image drawing |
| 180 | sequence to its "outer" terminal, with some support for limited |
| 181 | clipping. |
| 182 | |
| 183 | |
| 184 | |
| 185 | Out Of Scope |
| 186 | ------------ |
| 187 | |
| 188 | The following items are out of scope: |
| 189 | |
| 190 | * Bidirectional output. Applications are expected to generate Tiles |
| 191 | and place them on screen where they need. The cursor response to |
| 192 | image sequences are defined as left-to-right-top-to-bottom, |
| 193 | consistent with ECMA-48 / ANSI X3.64 sequences. An independent BIDI |
| 194 | standard is free to apply whatever solution will work for ECMA-48 / |
| 195 | ANSI X3.64 sequences to the sequences described in this document. |
| 196 | |
| 197 | * Capabilities. This standard defines a limited number of new |
| 198 | terminal reports and responses. These are not intended to be used |
| 199 | as a general-purpose capabilities model. |
| 200 | |
| 201 | |
| 202 | |
| 203 | Definitions |
| 204 | ----------- |
| 205 | |
| 206 | Terminal - The hardware, or a program that simulates hardware, |
| 207 | comprising a keyboard, screen, and mouse. |
| 208 | |
| 209 | Application - A program that utilizes the terminal for its |
| 210 | input/output with the user. |
| 211 | |
| 212 | Multiplexer - A special case of an application that simulates one or |
| 213 | more "inner" terminals for other applications to use, |
| 214 | and composes these inner terminals into a combined |
| 215 | screen to emit to one or more "outer" terminals that |
| 216 | obtain input/output from the user. Multiplexers are |
| 217 | thus both applications and terminals. |
| 218 | |
| 219 | X - The column coordinate of a cell. This standard is 1-based (like |
| 220 | ECMA-48): the left-most column of the screen is numbered 1. |
| 221 | |
| 222 | Y - The row coordinate of a cell. This standard is 1-based (like |
| 223 | ECMA-48): the top-most row of the screen is numbered 1. |
| 224 | |
| 225 | Z - The layer that text or multimedia is placed on. This proposal |
| 226 | uses a right-hand coordinate system with (X, Y, Z) = (1, 1, 1) |
| 227 | defined as the top-left corner on the default layer; positive Z |
| 228 | projects "away" from the user and "into" or "behind" the screen. |
| 229 | Rendering the Cells on the screen must produce the same result as |
| 230 | painter's algorithm (see "Layers - Rendering" section below). |
| 231 | |
| 232 | Cell - A fixed-width-and-height rectangle on the screen. The cells of |
| 233 | the screen are arranged in a grid of X columns and Y rows. A |
| 234 | Cell has dimensions of cellWidth and cellHeight pixels. Every |
| 235 | Cell has a coordinate of (X, Y) (or (X, Y, Z) when the terminal |
| 236 | supports the layers feature). |
| 237 | |
| 238 | Tile - One or more contiguous Cells with data to be displayed. The |
| 239 | data can be text or image data, but not both. A Tile has width |
| 240 | of 1, 2, or more, and a coordinate of (X, Y, Z) that is the |
| 241 | same as its left-most (first) Cell's (X, Y, Z). In practice, |
| 242 | Tiles are typically one Cell wide for ASCII and Latin language |
| 243 | glyphs, and two Cells wide for "fullwidth" glyphs as used in |
| 244 | Asian langauges, emojis, and symbols. This standard does not |
| 245 | preclude Tiles from encompassing entire grapheme clusters. |
| 246 | Note that ECMA-48 / ANSI X3.64 operations are performed against |
| 247 | Tiles, not Cells: if a 2-Cell-wide Tile is deleted via |
| 248 | backspace, then the cursor will decrement on screen by two |
| 249 | columns. |
| 250 | |
| 251 | Layer - A screen-sized grid of Cells that have the same Z coordinate. |
| 252 | Layers are drawn to the screen in descending Z order. Layers |
| 253 | may have optional additional attributes such as transparency. |
| 254 | Layer support is an orthogonal (independent) option to |
| 255 | multimedia support. It is acceptable for terminals to support |
| 256 | multimedia without layers and vice versa. |
| 257 | |
| 258 | |
| 259 | |
| 260 | |
| 261 | All Features - Detection |
| 262 | ------------------------ |
| 263 | |
| 264 | Applications can detect support for these features using Primary |
| 265 | Device Attributes (DA) and DECID (ESC Z, or 0x9A). |
| 266 | |
| 267 | Terminals that support this standard will repond with additional |
| 268 | parameter(s): "224" for direct multimedia, "225" for cached |
| 269 | multimedia, and "226" for layers. A recap of the parameters xterm |
| 270 | supports is listed below, with these new feature responses included: |
| 271 | |
| 272 | | VT220 (and higher) Response | Description | |
| 273 | |-----------------------------|--------------------------------------------| |
| 274 | | 1 | 132-columns | |
| 275 | | 2 | Printer | |
| 276 | | 3 | ReGIS graphics | |
| 277 | | 4 | Sixel graphics | |
| 278 | | 6 | Selective erase | |
| 279 | | 8 | User-defined keys | |
| 280 | | 9 | National Replacement Character sets | |
| 281 | | 1 5 | Technical characters | |
| 282 | | 1 6 | Locator port | |
| 283 | | 1 7 | Terminal state interrogation | |
| 284 | | 1 8 | User windows | |
| 285 | | 2 1 | Horizontal scrolling | |
| 286 | | 2 2 | ANSI color, e.g., VT525 | |
| 287 | | 2 8 | Rectangular editing | |
| 288 | | 2 9 | ANSI text locator (i.e., DEC Locator mode) | |
| 289 | | 2 2 4 | Direct Multimedia Version 1 | |
| 290 | | 2 2 5 | Cached Multimedia Version 1 | |
| 291 | | 2 2 6 | Layers | |
| 292 | |
| 293 | |
| 294 | |
| 295 | Direct Multimedia - Summary |
| 296 | --------------------------- |
| 297 | |
| 298 | |
| 299 | |
| 300 | Direct Multimedia - Required Support For Existing Sequences |
| 301 | ----------------------------------------------------------- |
| 302 | |
| 303 | A terminal with direct multimedia feature must support the following |
| 304 | defined xterm sequences: |
| 305 | |
| 306 | | Sequence | Description | |
| 307 | |----------------|-----------------------------------------------------| |
| 308 | | CSI 16 t | Responds with CSI 6 ; cellHeight ; cellWidth t | |
| 309 | | CSI 18 t | Responds with CSI 8 ; rows ; columns t | |
| 310 | |
| 311 | |
| 312 | |
| 313 | Direct Multimedia - New Sequences |
| 314 | --------------------------------- |
| 315 | |
| 316 | |
| 317 | |
| 318 | Direct Multimedia - Error Handling |
| 319 | ---------------------------------- |
| 320 | |
| 321 | |
| 322 | |
| 323 | Direct Multimedia - Cursor Position |
| 324 | ----------------------------------- |
| 325 | |
| 326 | |
| 327 | |
| 328 | Direct Multimedia - Wire Format |
| 329 | ------------------------------- |
| 330 | |
| 331 | |
| 332 | |
| 333 | Direct Multimedia - Examples |
| 334 | ---------------------------- |
| 335 | |
| 336 | |
| 337 | |
| 338 | Cached Multimedia - Summary |
| 339 | --------------------------- |
| 340 | |
| 341 | |
| 342 | |
| 343 | |
| 344 | Pixel data that has scrolled off the displayed screen and into the |
| 345 | scrollback buffer is required to be persistent even if the cache entry |
| 346 | containing that image data has been evicted by the terminal or removed |
| 347 | by the application. |
| 348 | |
| 349 | |
| 350 | |
| 351 | Cached Multimedia - Required Support For Existing Sequences |
| 352 | ----------------------------------------------------------- |
| 353 | |
| 354 | A terminal with cached multimedia feature must support the following |
| 355 | defined xterm sequences: |
| 356 | |
| 357 | | Sequence | Description | |
| 358 | |----------------|-----------------------------------------------------| |
| 359 | | CSI 16 t | Responds with CSI 6 ; cellHeight ; cellWidth t | |
| 360 | | CSI 18 t | Responds with CSI 8 ; rows ; columns t | |
| 361 | |
| 362 | |
| 363 | |
| 364 | Cached Multimedia - New Sequences |
| 365 | --------------------------------- |
| 366 | |
| 367 | |
| 368 | |
| 369 | Cached Multimedia - Error Handling |
| 370 | ---------------------------------- |
| 371 | |
| 372 | |
| 373 | |
| 374 | Cached Multimedia - Cursor Position |
| 375 | ----------------------------------- |
| 376 | |
| 377 | |
| 378 | |
| 379 | Cached Multimedia - Scrollback |
| 380 | ------------------------------ |
| 381 | |
| 382 | |
| 383 | |
| 384 | Cached Multimedia - Wire Format |
| 385 | ------------------------------- |
| 386 | |
| 387 | |
| 388 | |
| 389 | Cached Multimedia - Examples |
| 390 | ---------------------------- |
| 391 | |
| 392 | |
| 393 | |
| 394 | |
| 395 | Layers - Summary |
| 396 | ---------------- |
| 397 | |
| 398 | Layers introduce the concept of a layer "Z" coordinate to the existing |
| 399 | rows ("Y") by columns ("X") grid. Put another way, the |
| 400 | two-dimensional grid of columns-by-rows becomes a three-dimensional |
| 401 | cube of columns-by-rows-by-layers. For this document, the column, |
| 402 | row, and layer coordinates are referred to as X, Y, and Z. This |
| 403 | cartesian coordinate system is right-handed, with the Z axis pointing |
| 404 | "away" from the user "into" the screen. |
| 405 | |
| 406 | An application treats the Z coordinate exactly as it does X and Y |
| 407 | (rows and columns) coordinates: |
| 408 | |
| 409 | * If it attemps to set Z to a value less than 1, then Z is set to 1. |
| 410 | |
| 411 | * If it attempts to set Z to a value greater than the number of |
| 412 | layers, then Z is set to the number of layers. |
| 413 | |
| 414 | New sequences are provided to set and query Z, Y, X, to set and query |
| 415 | the screen cube size, and control visibility of Cells in-front-of |
| 416 | other Cells. |
| 417 | |
| 418 | Operations that act on more than one Cell are defined such to act on |
| 419 | all layers simultaneously by default. |
| 420 | |
| 421 | |
| 422 | |
| 423 | Layers - Number of Layers |
| 424 | ------------------------- |
| 425 | |
| 426 | A terminal is required to provide between 1 and a finite number of |
| 427 | layers. |
| 428 | |
| 429 | The number of layers may be different between the primary and |
| 430 | alternate screens. |
| 431 | |
| 432 | An application may request that the terminal allocate additional |
| 433 | layers. The terminal is free to honor or ignore such requests as it |
| 434 | sees fit. |
| 435 | |
| 436 | The scrollback buffer is permitted, and recommended, to contain only a |
| 437 | "flattened" single layer. |
| 438 | |
| 439 | |
| 440 | |
| 441 | Layers - Terminal State |
| 442 | ----------------------- |
| 443 | |
| 444 | The terminal maintains a complex state at all times. This state |
| 445 | includes variables such as cursor position, foreground/background |
| 446 | color, attributes to apply to the next displayed character, and so on. |
| 447 | The layers feature adds more variables to the state, and these |
| 448 | variables are required to be stored with DECSC (ESC 7) and restored |
| 449 | with DECRC (ESC 8). The new variables are listed below: |
| 450 | |
| 451 | | Mnemonic | Description | Default value | |
| 452 | |----------|-----------------------------|----------------| |
| 453 | | Z | Cursor position Z | 1 | |
| 454 | | MSL | Manipulate single layer | off / disabled | |
| 455 | | TFT | Text foreground transparent | false | |
| 456 | | TBT | Text background transparent | false | |
| 457 | |
| 458 | |
| 459 | |
| 460 | Layers - Required Support For Existing Sequences |
| 461 | ------------------------------------------------ |
| 462 | |
| 463 | A terminal with layers feature must support the standard VT100/VT102 |
| 464 | sequences defined in their respective manuals. |
| 465 | |
| 466 | |
| 467 | |
| 468 | Layers - New Sequences |
| 469 | ---------------------- |
| 470 | |
| 471 | A terminal with layer feature must support the following new |
| 472 | sequences: |
| 473 | |
| 474 | | Sequence | Command | Description | |
| 475 | |-------------------|-------------|----------------------------------------| |
| 476 | | CSI ? z ; y ; x H | CUPZ | Move cursor to (x, y, z) | |
| 477 | | CSI ? z ; y ; x H | SLA | Set layer alpha | |
| 478 | | CSI ? 3 0 0 1 h | DECSET 3001 | Enable Manupulate Single Layer (MSL) | |
| 479 | | CSI ? 3 0 0 1 l | DECRST 3001 | Disable Manupulate Single Layer (MSL) | |
| 480 | | CSI ? l ; h ; w t | RSZCUBE | Resize cube to (layers, height, width) | |
| 481 | |
| 482 | Default parameters and ranges are listed below: |
| 483 | |
| 484 | | Command | Position / Variable | Default Value | Minumum | Maximum | |
| 485 | |---------|---------------------|---------------|---------|-----------| |
| 486 | | CUPZ | 1 / z | 1 | 1 | # layers | |
| 487 | | CUPZ | 2 / y | 1 | 1 | # rows | |
| 488 | | CUPZ | 3 / x | 1 | 1 | # columns | |
| 489 | | SLA | 1 / alpha | 255 | 0 | 255 | |
| 490 | | RSZCUBE | 1 / l | 1 | 1 | varies | |
| 491 | | RSZCUBE | 2 / h | 80 | 1 | varies | |
| 492 | | RSZCUBE | 3 / w | 24 | 1 | varies | |
| 493 | |
| 494 | The terminal must also support the following new queries: |
| 495 | |
| 496 | | Query | Response | Description | |
| 497 | |-----------------------------------------|--------------------------------| |
| 498 | | CSI ? 1 0 0 n | CSI ? z ; y ; x n | Report cursor Z, Y, X position | |
| 499 | | CSI ? 1 8 t | CSI ? 8 ; l ; h ; w t | Report the text area cube layers, height, width | |
| 500 | |
| 501 | |
| 502 | The terminal must support the following new Set Graphics Rendition |
| 503 | (SGR) character attributes commands: |
| 504 | |
| 505 | | SGR Parameter | Description | |
| 506 | |---------------|---------------------------------------------| |
| 507 | | 230 | Set text foreground color to transparent | |
| 508 | | 239 | Set text foreground color to solid (opaque) | |
| 509 | | 240 | Set text background color to transparent | |
| 510 | | 249 | Set text background color to solid (opaque) | |
| 511 | |
| 512 | |
| 513 | |
| 514 | |
| 515 | Layers - Error Handling |
| 516 | ----------------------- |
| 517 | |
| 518 | No additional error reporting is provided for layer feature. |
| 519 | |
| 520 | |
| 521 | |
| 522 | Layers - Rendering |
| 523 | ------------------ |
| 524 | |
| 525 | A terminal with layer feature will display its Cells such that the |
| 526 | screen will appear as if it was rendered in the manner of the |
| 527 | pseudo-code below: |
| 528 | |
| 529 | ``` |
| 530 | for each layer Z, in descending order from maxZ to minZ: |
| 531 | |
| 532 | for each row Y, in ascending order from minY to maxY: |
| 533 | |
| 534 | for each column X, in ascending order from minX to maxX: |
| 535 | |
| 536 | if tile at (X, Y, Z) background color is solid: |
| 537 | draw rectangle of background color with layer alpha |
| 538 | |
| 539 | if tile at (X, Y, Z) foreground color is solid: |
| 540 | if tile at (X, Y, Z) is glyph: |
| 541 | draw glyph with foreground color with layer alpha |
| 542 | else |
| 543 | draw pixel data of tile as red/green/blue/alpha pixels with |
| 544 | layer alpha |
| 545 | |
| 546 | advance X by tile width |
| 547 | next column |
| 548 | |
| 549 | advance Y by 1 |
| 550 | next row |
| 551 | |
| 552 | decrease Z by 1 |
| 553 | next layer |
| 554 | ``` |
| 555 | |
| 556 | A terminal is free to optimize its rendering as it sees fit, so long |
| 557 | as the final screen output looks equivalent to the above method. |
| 558 | |
| 559 | |
| 560 | |
| 561 | Layers - Integration With Existing Sequences |
| 562 | -------------------------------------------- |
| 563 | |
| 564 | Sequences that insert characters/lines, delete characters/lines, or |
| 565 | modify larger regions are changed to act upon multiple layers as |
| 566 | defined below. By default, MSL (Modify All Layers) is off/unset, and |
| 567 | Z is 1, so if the application never changes MSL or Z then these |
| 568 | sequences will produce the same visible output as a terminal without |
| 569 | layer support. |
| 570 | |
| 571 | A terminal is not required to support all of these sequences; however, |
| 572 | for those sequences it does support, if it supports the layers feature |
| 573 | then the sequences must behave as shown below: |
| 574 | |
| 575 | | Sequence | Command | Additional behavior | |
| 576 | |------------|-------------|------------------------------------------| |
| 577 | | BS (0x08) | Backspace | Only current layer affected if MSL=on | |
| 578 | | DEL (0x7F) | Delete | Only current layer affected if MSL=on | |
| 579 | | IND (0x84) | Index | Only current layer affected if MSL=on | |
| 580 | | RI (0x8D | Reverse Index | Only current layer affected if MSL=on | |
| 581 | | ESC # 3 | DECDHL | Cells on all layers always affected | |
| 582 | | ESC # 4 | DECDHL | Cells on all layers always affected | |
| 583 | | ESC # 5 | DECSWL | Cells on all layers always affected | |
| 584 | | ESC # 6 | DECDWL | Cells on all layers always affected | |
| 585 | | ESC # 8 | DECALN | All layers > 1 cleared; Z, MSL, TFT, TBT reset to default | |
| 586 | | ESC 7 | DECSC | Also store Z, MSL, TFT, TBT | |
| 587 | | ESC 8 | DECRC | Also restore Z, MSL, TFT, TBT | |
| 588 | | ESC c | RIS | All layers > 1 cleared; Z, MSL, TFT, TBT reset to default | |
| 589 | | CSI @ | ICH | Only current layer affected if MSL=on | |
| 590 | | CSI J | ED | Only current layer affected if MSL=on | |
| 591 | | CSI K | EL | Only current layer affected if MSL=on | |
| 592 | | CSI ? K | DECSEL | Only current layer affected if MSL=on | |
| 593 | | CSI L | IL | Only current layer affected if MSL=on | |
| 594 | | CSI M | DL | Only current layer affected if MSL=on | |
| 595 | | CSI X | ECH | Only current layer affected if MSL=on | |
| 596 | | CSI M | DL | Only current layer affected if MSL=on | |
| 597 | | CSI P | DCH | Only current layer affected if MSL=on | |
| 598 | | CSI R | DECSTBM | Cells on all layers always affected | |
| 599 | | CSI $ t | DECARA | Only current layer affected if MSL=on | |
| 600 | | CSI $ v | DECCRA | Only current layer affected if MSL=on | |
| 601 | | CSI x | DECSACE | Cells on all layers always affected | |
| 602 | | CSI $ x | DECFRA | Only current layer affected if MSL=on | |
| 603 | | CSI $ z | DECERA | Only current layer affected if MSL=on | |
| 604 | |
| 605 | The VT52 sub-mode commands: |
| 606 | |
| 607 | | Sequence | Command | Additional behavior | |
| 608 | |------------|-------------|------------------------------------------| |
| 609 | | ESC J | ED | Only current layer affected if MSL=on | |
| 610 | | ESC K | EL | Only current layer affected if MSL=on | |
| 611 | |
| 612 | |
| 613 | |
| 614 | Layers - Use With Multiplexers |
| 615 | ------------------------------ |
| 616 | |
| 617 | Layers are inteded to provide a means for multiplexers to pass on the |
| 618 | job of multimedia support to the "outer" or host terminal. The |
| 619 | proposed mechanics of that is outlined in the pseudo-code below: |
| 620 | |
| 621 | ``` |
| 622 | for each inner terminal in descending order from maxZ to minZ: |
| 623 | |
| 624 | emit CUPZ(inner terminal Z, inner terminal Y, inner terminal X) |
| 625 | |
| 626 | draw inner terminal text with standard VT100/VT102/xterm sequences |
| 627 | |
| 628 | for each multimedia sequence emitted by the inner terminal: |
| 629 | emit CUP(inner terminal Y, inner terminal X) |
| 630 | emit multimedia sequences to outer terminal |
| 631 | next multimedia sequence |
| 632 | |
| 633 | decrease Z by 1 |
| 634 | next inner terminal |
| 635 | ``` |
| 636 | |
| 637 | The method above may not be effective for complex multi-terminal |
| 638 | screen layouts, but is hoped to work well for many simple cases. |
| 639 | |
| 640 | |
| 641 | |
| 642 | Layers - Examples |
| 643 | ----------------- |
| 644 | |
| 645 | |
| 646 | |
| 647 | |
| 648 | References |
| 649 | ---------- |
| 650 | |
| 651 | * xterm control sequences: |
| 652 | |
| 653 | |
| 654 | * ECMA-48: |