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
No known key found for this signature in database
GPG Key ID: 5F43400C21CBFACC

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