simple image display

It would be useful to standardize an escape sequence for displaying images inline in the terminal output. Prior art that I know of includes item2 (https://www.iterm2.com/documentation-images.html). There is the sixel format but that is long obsolete. DomTerm has a more general escape sequence where you can send arbitrary (sanitized) HTML: to display an image: just send an <img ..> element. Any others? For interoperability we should focus on png, jpeg, and gif (including animated) images with the data encoded in base64.

Basic support could be restricted to images starting at the left column, with no further output to the right of the image. (I.e. only block-level images. Inline images could be a less-portable extension.) We can also make it unspecified how many lines are taken by the image: Some terminals may create an image as a single logical line, with a single extra-large character cell. Other terminals may allocate may allocate as many lines and columns as needed for the image to fit. Both should be allowed when using default options. However, using an extra-large character cell is preferable, as it does not require padding to an integer number of lines.

The portable way to erase or replace a previously-drawn image would be to save-cursor before writing the image, and then restore-cursor before replacing it. This may need some special care (hacks?) in case the image caused scrolling.

Is it important to to use an escape sequence that is will safely fallback to plain text on terminals that don't support images? (After all - you probably wouldn't want to send a large image to a terminal that can't handle it.) If so, we need two escape sequences: An initial OSC sequence, followed by optional plain text, followed by a final OSC sequence. The plain text is used on terminals that don't understand the image. It can also be used by screen readers, and as hover text. Some terminals may allow user switching between the text and the image.

The format should be extensible. The iterm2 supports key=value pairs, which is somewhat extensible, but the format of values is restricted. It would be better to use JSON for options.

We could standardize on the iterm2 1337 sequence, but it has some problems. A minor awkwardness is that inline=0 is the default. Another is that extensibility is limited because of the lack of quoting and escaping. A third is the lack of robustness (fallback) on non-supporting terminals.

One possibility (I randomly picked 1338):

OSC 1338;_options_^G plain-text OSC 1338;_base64-data_^G

The options have the form of a JSON object, with the outer { and } removed. Specifically, it can be empty.

Comments?