From dcb8fcece4e7923ee3cadb07d22d72cca271f394 Mon Sep 17 00:00:00 2001 From: nick black Date: Tue, 9 Mar 2021 18:25:18 -0500 Subject: [PATCH] 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). --- docs/graphics-protocol.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/graphics-protocol.rst b/docs/graphics-protocol.rst index 60a492b3b..5eadae6bd 100644 --- a/docs/graphics-protocol.rst +++ b/docs/graphics-protocol.rst @@ -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:: _Gf=24,s=10,v=20,o=z;\ 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