diff --git a/xep-0392.xml b/xep-0392.xml index 83b1f0f3..fe6953df 100644 --- a/xep-0392.xml +++ b/xep-0392.xml @@ -14,7 +14,7 @@ This specification provides a set of algorithms to consistently generate colors given a string. The string can be a nickname, a JID or any other piece of information. All entities adhering to this specification generate the same color for the same string, which provides a consistent user experience across platforms. &LEGALNOTICE; 0392 - Deferred + Experimental Standards Track Standards Council @@ -23,6 +23,15 @@ colors &jonaswielicki; + + 0.8.0 + 2021-10-26 + jsc + +

Remove Color Vision Deficiency correction algorithms and substitute + them with a better recommendation.

+ + 0.7.0 2019-10-16 @@ -128,7 +137,6 @@

To generate a color from a string of text, the following algorithms are applied in order:

  1. Generate a Hue value from the text.
    2. -
  2. If enabled, apply configured corrections for &cvds;.
  3. If constraints mandate the use of only a small palette of colors, map the angle to the closest palette color. (Such situations could for example be a UI environment with guidelines to only use a specific set of colors or an output device which only supports a limited amount of colors.)
  4. If the output device supports RGB output, Convert the angle to a RGB.
@@ -137,12 +145,10 @@
  • Implementations SHOULD allow the user to turn off any colorization completely.
    • -
  • Implementations SHOULD implement the &cvd; profiles and SHOULD allow the user to choose any of these profiles or to disable the correction.
    • -
  • Implementations MUST NOT share the &cvd; correction settings with other entities.
 -

The algorithms in this document use the &hsluv;⎄ color space. It provides consistent brightness (for a given luminosity) across its entire definition space. There is also widespread library support.

+

The algorithms in this document use the &hsluv; color space. It provides consistent brightness (for a given luminosity) across its entire definition space. There is also widespread library support.

Input: An identifier, encoded as octets of UTF-8 (&rfc3269;).

Output: Hue angle.

@@ -153,20 +159,6 @@
  • Divide the value by 65536 (use float division) and multiply it by 360 (to map it to degrees in a full circle).
    •  - -

    Input: Hue angle.

    -

    Output: Hue angle.

    -

    Note: This algorithm will re-map the angle to map it away from ranges which can not be distinguished by people with the respective &cvds;.

    -

    Note: Some floating-point modulo implementations will return negative outputs for negative inputs. This algorithm assumes that your implementation returns non-negative outputs for all inputs.

    - -

    Add 90 to the angle, take it modulo 180 and subtract 90. Take the result modulo 360 to ensure that it's in the range from 0 to 360.

    -

    Note: the same effect can be achieved by forcing the two most-significant bits of the angle to be equal to the second-most-significant bit before converting to a float in Angle generation. This avoids having to perform a floating-point modulo operation.

    -     - -

    Take the angle modulo 180.

    -

    Note: the same effect can be achieved by setting the most-significant bit to zero before conversion to floating point in Angle generation. This avoids having to perform a floating-point modulo operation.

    -     -

    Use the HSLuv operation hsluvToRgb to convert the Hue angle to a color. The saturation and lightness are to be defined by the implementation (see also the Contrast Ratio considerations).

     @@ -210,19 +202,9 @@     - -

    As outlined above, implementations SHOULD offer the &rgblind; and &bblind; corrections as defined in the Corrections for &cvds; section. Users SHOULD be allowed to choose between:

    -
      -
    • disabling all corrections (skip the Corrections for &cvds; step entirely),
      • -
    • applying one of the &cvd; correction profiles and
      • -
    • disabling colorization altogether.
      • -
    -

    The last option is useful for users with monochromatic view or who find colors distracting.

    -

    Some sources on the internet indicate that people with &cvds; may profit from having larger areas of color to be able to recognize them. This should be taken into consideration when selecting font weights and line widths for colored parts.

    -     - -

    Implementations should adapt the lightness value according to the background on which the color is rendered.

    -     +

    This specification describes the generation of colors for strings. Users with color vision deficiencies may have a lower range of distinguishable colors. Implementations should observe the usual recommendations regarding the use of color in that regard.

    +

    Some users may find a huge variety of colors on their screen distracting. Any implementation making use of this color generation algorithm should support replacing all generated colors with a static, potentially user-configurable, color.

    +

    Implementations should adapt the lightness value according to the background on which the color is rendered in order to achieve a good contrast ratio.

    This specification extracts a bit more information from an entity and shows it alongside the existing information to the user. As the algorithm is likely to produce different colors for look-alikes (see &xep0165; for examples) in JIDs, it may add additional protection against attacks based on those.

    @@ -260,6 +242,15 @@

    For the sake of having more colors available, the given algorithm was chosen which prefers many colors with hue conformance over fewer colors with hue and lightness conformance.

    + +

    An earlier version of this spec included a makeshift algorithm to correct for &cvds;. However, this was considered suboptimal for the following reasons:

    +
      +
    • Any operating system level &cvd; correction is likely to produce better results.
      • +
    • The actual benefit from an accessibility point of view is unclear, given that the &cvd; itself already reduces the dynamic range; if the &cvd; correction algorithm and the &cvd; are not fully in tune about the range reduction, unnecessary additional loss of information may occur.
      • +
    • The algorithms introduced significant complexity on some platforms.
      • +
    +

    Future versions of this spec may re-introduce recommendations if especially the second point can be refuted by credible sources.

    +

    This document requires no interaction with &IANA;.

    @@ -272,58 +263,22 @@     -

    This section holds test vectors for the different configurations. The test vectors are provided as Comma Separated Values. Strings are enclosed by single quotes ('). The first line contains a header. Each row contains, in that order, the original text, the text encoded as UTF-8 as hexadecimal octets, the angle in degrees, the calculated hue in degrees (differs from angle only for CVD-corrected rows), and the Red, Green, and Blue values.

    - - This section holds test vectors. The test vectors are provided as Comma Separated Values. Strings are enclosed by single quotes ('). The first line contains a header. Each row contains, in that order, the original text, the text encoded as UTF-8 as hexadecimal octets, the angle in degrees, the calculated hue in degrees (hue and angle are the same as of version 0.8.0), and the Red, Green, and Blue values.

    + -     - - - - - -

    The used palette can be generated by sampling the RGB cube evenly with six samples on each axis (resulting in 210 colors (grayscales are excluded)). The resulting palette is commonly known as the palette of so-called "Web Safe" colors.

    - - - - - - - - -