Github user necouchman commented on a diff in the pull request:
https://github.com/apache/guacamole-manual/pull/92#discussion_r210518500
--- Diff: src/chapters/configuring.xml ---
@@ -3009,13 +3009,102 @@ ed272546-87bd-4db9-acba-e36e1a9ca20a
<primary>SSH</primary>
<secondary>color
scheme</secondary>
</indexterm>The color scheme to
use for the terminal
- emulator used by SSH connections.
Each color scheme dictates
- the default foreground and
background color for the
- terminal. Programs which specify
colors when printing text
- will override these
defaults.</para>
- <para>This parameter is optional. By
default, Guacamole will
- render text as gray over a black
background.</para>
- <para>Possible values are:</para>
+ emulator used by SSH connections.
It consists of a
+ semicolon-separated series of
name-value pairs, separated by
+ a colon, that assign default
values to colors in the
+ terminal emulator palette. Note
that programs that specify
+ colors when printing text can
still override these defaults.
+ For example, to use blue text on
white background by
+ default, and change the default
red color to a purple shade,
+ you would specify:</para>
+ <informalexample>
+ <programlisting>foreground:
rgb:00/00/ff;
+background: rgb:ff/ff/ff;
+color9: rgb:80/00/80</programlisting>
+ </informalexample>
+ <para>This format is similar to the
color configuration format
+ used by Xterm, so Xterm color
configurations can be easily
+ adapted for Guacamole. This
parameter is optional. If not
+ specified, Guacamole will render
text as gray over a black
+ background.</para>
+ <para>Possible color names are:</para>
+ <variablelist>
+ <varlistentry>
+
<term><constant>foreground</constant></term>
+ <listitem>
+ <para>Set the default
foreground color.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+
<term><constant>background</constant></term>
+ <listitem>
+ <para>Set the default
background color.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+
<term><constant>color<n></constant></term>
+ <listitem>
+ <para>Set the default
color at index <code><n>
+ </code> on the Xterm
256-color palette. For
+ example,
<code>color9</code> refers to the
+ default red
color.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>Possible color values are:</para>
+ <variablelist>
+ <varlistentry>
+
<term><constant>rgb:R/G/B</constant></term>
+ <listitem>
+ <para>Use a 12-bit color
specified in hexadecimal.
+ The color value is
zero-padded to 24 bits. For
+ example,
<code>rgb:f/0/0</code> specifies the
+ color red.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+
<term><constant>rgb:RR/GG/BB</constant></term>
+ <listitem>
+ <para>Use the 24-bit color
specified in hexadecimal.
+ For example,
<code>rgb:ff/00/00</code> specifies
+ the color red.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+
<term><constant>rgb:RRR/GGG/BBB</constant></term>
+ <listitem>
+ <para>Use a 36-bit color
specified in hexadecimal.
+ The color value is
truncated to 24 bits. For
--- End diff --
A couple of things, here:
- Since the value is always going to be 24-bits, either zero-padded or
truncated, does it make sense to documented four separate ways to specify the
color values, or does it make more sense to just document it as 24-bits, with a
few extra notes (or examples) for what happens if you specify it as 12, 36, or
48 bits? I'm genuinely asking, here - maybe it does make sense to document it
this way? @mike-jumper @jmuehlner, thoughts?
- In either case, whether leaving it split up like this or collapsing it a
bit, it would probably make sense to have some idea of the practical
implications of what the truncating, in particular, does. So, if I specify a
36-bit color value, and it gets truncated to 24-bits, how is that going to
impact the color I've entered?
---
