[feature] improved multilingual color input

[17o2]

Example

The following YAML input:

cables:
  W1:
    gauge: 0.25 mm2
    length: 0.2
    colors: [tomato, ge, 00FF00, BU]

should be valid, and produce the following output:

Yes, tomato should be an accepted color because it's part of the official HTML color names 🍅

Motivation

Currently, wv_colors.py includes list of german color codes (e.g. ge for gelb=yellow), as well as full english color names, but there is no direct way to use them. It would be nice if German users could directly use the german color codes; the direct HTML color and hex options give unlimited flexibility to anybody who needs it; anybody who does not like abbreviations is not forced to use them, or see them in the output.

My proposal is to allow the following inputs:

• English color codes (RD)
• German color codes (rt)
• HTML color entities (red)
• Hex colors (FF0000)

I've chosen to exclude the # in the hex colors because YAML treats it as a comment delimiter, and \#FF0000 is less readable

The HTML color entities do not cause extra work because GraphViz understands them natively.

Implementation

The implementation should be quite straightforward.
In addition to a cable's colors list, a second htmlcolors list (or similar) is needed. Then, a simple parsing function parses the user's input, checking whether it's included in one of the color codes, and setting the appropriate htmlcolor, i.e. mapping RD to #ff0000 and ge to #ffff00, adding the missing # if a hex color was specified, and simply passing the input if it is neither of these (tomato). If the input is a completely unknown color, it will be rendered black (default GraphViz behavior) but the label will still show the input.

This means that the color parsing would happen in the cable's __post_init__() function, and all the GraphViz code generation would no longer use the translate_color() function, but read straight from the htmlcolors list.

Multicolor wires should be easy to include as well:
Keep allowing four- and six- letter combinations as input (GNYE, gnge, and possibly even 00FF00/FFFF00 and green/yellow) and expand them to a list while parsing.
The rendering code would check if the respective item in htmlcolors is a string (single color) or list (multicolor) and react accordingly.

cables:
  W1:
    gauge: 0.25 mm2
    length: 0.2
    colors: [GNYE, gnge, green/yellow, 00FF00/FFFF00, MysteryColor]

[kvid]

These ideas you present, are great! 👍 I just have a few comments about some details.

German color codes (rt)

By accepting German codes as input, I assume requests for supporting additional languages will arrive. As more languages can be supported, it might be hard to avoid ambiguity unless adding a language prefix (e.g. de.gnge) or a common Harness.input_language.

It is already a small parsing ambiguity for the German color eb as these letters are also valid hexadecimal digits. You might avoid this by requiring uppercase letters for hexadecimal digits and lowercase letters for German color codes, as in your examples, but users might find that very restrictive. You might also decide to interpret 'ebebeb' as a light grey color instead of triple ivory. 😄

This means that the color parsing would happen in the cable's post_init() function, and all the GraphViz code generation would no longer use the translate_color() function, but read straight from the htmlcolors list.

Do you mean that you consider removing the Harness.color_mode as I interpret is a preparation for supporting translated color text? I agree that presenting the colors as specified is a useful default, but I also believe a color translation option can be useful, e.g. when using COLOR_CODES.

[17o2]

German color codes (rt)

By accepting German codes as input, I assume requests for supporting additional languages will arrive. As more languages can be supported, it might be hard to avoid ambiguity unless adding a language prefix (e.g. de.gnge) or a common Harness.input_language.

True. This is an aspect to keep in mind.

It is already a small parsing ambiguity for the German color eb as these letters are also valid hexadecimal digits. You might avoid this by requiring uppercase letters for hexadecimal digits and lowercase letters for German color codes, as in your examples, but users might find that very restrictive. You might also decide to interpret 'ebebeb' as a light grey color instead of triple ivory. 😄

I'm seeing another problem, that hex colors such as 000099 will just be parsed as an int with value 99.
There are two alternatives:

• YAML supports hex values in the format 0x123def
• Use single or double quotes for hex values (which will probably be rarely used) to avoid escaping: "#00FF00" is a valid YAML stirng.

Both would take care of the "triple german ivory" edge case ;-)

This means that the color parsing would happen in the cable's post_init() function, and all the GraphViz code generation would no longer use the translate_color() function, but read straight from the htmlcolors list.

Do you mean that you consider removing the Harness.color_mode as I interpret is a preparation for supporting translated color text? I agree that presenting the colors as specified is a useful default, but I also believe a color translation option can be useful, e.g. when using COLOR_CODES.

Let me think about the implications some more.

[SnowMB]

From a user perspective I would prefer to specify some colors on my own, but not necessary use other names for it.

For example the default green is far to bright in my opinion. Also when having striped / banded colors the defaulted ones might not go well with each other (for example yellow / green).

I would therefore propose to split naming of the color from the actual color name / hexcode. The user could than use a color name and optionally provide a hexcode to define the color. If nothing is provided we can still use common namings to provide a default color.

Next I would define on global or wire level which color naming scheme to use to avoid ambiguities. I think it would be pretty straight forward to say something like color_naming_scheme=DIN47100 for english or color_naming_scheme=DIN47100_GER for german somewhere in the yaml.

In fact your color_code attribute somewhat already does that. But I would still give the possibility to overwrite the provided colors and restrict lookup for color names to the given scheme.

That gives 3 scenarios:

1. only color_code is given: Like now auto generate wire colors based on the names and numbering of the provided scheme
2. color_code and colors attribute are given: use the given strings from colors as color names for actual coloring and restrict lookup to scheme defined in color_code
3. color_code and color_value (optionally colors as well) attributes are given: use values from color_value as color value for drawing the wire (either as hex or lookup in color_scheme). Here we might introduce a placeholder to define just some colors and not all of the cable

With this 3 settings everything is fully configurable and the user can use his own translation until there is a default. Also he could use different naming for multicolor (YEGN, YE-GN, YE/GN,...).

To make it less verbose when using multiple wires we can also give the user the possibility to define his own color_code in a separate color_code structure (and maybe overwrite the default ones) that he than can use in his cables.

[17o2]

@SnowMB
You raise some interesting points, but I'm afraid it starts getting somewhat complicated...

From a user perspective I would prefer to specify some colors on my own, but not necessary use other names for it.

My own guess is that most users just want to enter a color name, have it work in a predictable way, and have a nice looking output. The use of HTML names and hex codes should probably be the exception, for when someone really really needs a lavender blush colored cable.

For example the default green is far to bright in my opinion. Also when having striped / banded colors the defaulted ones might not go well with each other (for example yellow / green).

This tells me we need to tweak the pallette to get the colors to look right. I agree that the GNYE combo is not the best at the moment. And there are some color combinations that just always look terrible, both on-screen and in real life... red and blue striped cables, ugh!

My initial proposal, of making the existing colors attribute a bit more flexible, tries to follow the KISS principle to make the user experience hassle free :)

[17o2]

Do you mean that you consider removing the Harness.color_mode as I interpret is a preparation for supporting translated color text? I agree that presenting the colors as specified is a useful default, but I also believe a color translation option can be useful, e.g. when using COLOR_CODES.

@kvid
You are corrrect, when using predefined color codes, the user should be able to select how they should be translated into text. The YAML file would need a parameter to specify whether to display English code, German code, full English, or hex.

Obviously some translation requests might come in, but that's nothing that wv_colors.py can't handle, and it's an easy way that users from all around the world can contribute to the project :)

[kvid]

For example the default green is far to bright in my opinion. Also when having striped / banded colors the defaulted ones might not go well with each other (for example yellow / green).

This tells me we need to tweak the pallette to get the colors to look right. I agree that the GNYE combo is not the best at the moment. And there are some color combinations that just always look terrible, both on-screen and in real life... red and blue striped cables, ugh!

If we make the current GN darker (as I think is a good idea), e.g. #00AA00, I suggest using LG (light green) for the brighter #00FF00 as also used in #120 (comment). Is this the correct issue for color value changes?