Add some notes to graphics protocol docs

Clarify that RFC1950-style zlib-wrapped deflate (as opposed
to RFC1951-style raw deflate) payloads are sent in the
graphics protocol, and that base64 encoding follows
compression (implied by remarks elsewhere, but go ahead and
make it explicit here).
This commit is contained in:
nick black
2021-03-09 18:25:18 -05:00
parent 958ccadc09
commit dcb8fcece4

View File

@@ -194,15 +194,16 @@ Compression
~~~~~~~~~~~~~ ~~~~~~~~~~~~~
The client can send compressed image data to the terminal emulator, by specifying the The client can send compressed image data to the terminal emulator, by specifying the
``o`` key. Currently, only zlib based deflate compression is supported, which is specified using ``o`` key. Currently, only RFC1950-style zlib based deflate compression is
``o=z``. For example:: supported, which is specified using ``o=z``. For example::
<ESC>_Gf=24,s=10,v=20,o=z;<payload><ESC>\ <ESC>_Gf=24,s=10,v=20,o=z;<payload><ESC>\
This is the same as the example from the RGB data section, except that the This is the same as the example from the RGB data section, except that the
payload is now compressed using deflate. The terminal emulator will decompress payload is now compressed using deflate (this occurs prior to base64-encoding).
it before rendering. You can specify compression for any format. The terminal The terminal emulator will decompress it before rendering. You can specify
emulator will decompress before interpreting the pixel data. compression for any format. The terminal emulator will decompress before
interpreting the pixel data.
The transmission medium The transmission medium