KittyPatch/kitty
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Add some notes to graphics protocol docs

Browse Source 
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
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
docs/graphics-protocol.rst
View File

@ -194,15 +194,16 @@ Compression
~~~~~~~~~~~~~
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=z``. For example::
``o`` key. Currently, only RFC1950-style zlib based deflate compression is
supported, which is specified using ``o=z``. For example::
<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
payload is now compressed using deflate. The terminal emulator will decompress
it before rendering. You can specify compression for any format. The terminal
emulator will decompress before interpreting the pixel data.
payload is now compressed using deflate (this occurs prior to base64-encoding).
The terminal emulator will decompress it before rendering. You can specify
compression for any format. The terminal emulator will decompress before
interpreting the pixel data.
The transmission medium