[feature] Adding banded multicolor wires

[SnowMB]

Splitting out from #96 as requested:

I'm looking for a way to produce a banded output for two color wires. #96 introduced two colors by showing the second color as stripe along the wire.

I think with a banded representation it is easier to distinguish the colors and looks more visually appealing.

Here is an example (taken from #96):

I've just play around with the .gv files and the dot language.

Todo:

• Styling the representation in the Wire- Node (should be easy to do)
• Finding a way to make the size of the color bands consistent. In my example every wire has exactly 10 bands (10% of the edge per band) which results in longer bands when the wire gets longer. Maybe using style="dashed" can be used. But I think it's not as visually appealing as the example above.
• Making sure that the way I got graphviz to draw multiple edges on top of each other is actually working as intended and not just a bug in my version of graphviz dot - graphviz version 2.44.0 (0) which might be fixed later
• Integration into the WireViz python scripts

[formatc1702]

Cables will probably require a new attribute to specify what style the user wants:

multicolor: lengthwise  # current look
multicolor: rings       # proposed new look

Since ethernet cables, for example, are striped lengthwise, whereas DIN 47100 specifies rings.

This raises another question, whether the colors should be split 50/50, or whether the second color defines thin rings over a base color?
The wires I have lying around here have around a 3/1 ratio of base to rings, the following picture has around 2/1 ratio.

[SnowMB]

This raises another question, whether the colors should be split 50/50, or whether the second color defines thin rings over a base color?
The wires I have lying around here have around a 3/1 ratio of base to rings, the following picture has around 2/1 ratio.

Arbitrary ratios are possible. But the yaml might grow very verbose if everything has to be specified. Maybe use 50/50 as starting point and add arbitrary values later if someone needs them? I think for the documentation purpose it might not be so important to exactly match the wire 😄

In the mean time I also encountered 3 color wires, which also should be possible.

[aakatz3]

Are there any thoughts on how to actually implement this? I assume we'd lose the outlines on the wires, as I didn't see any way to actually pattern the lines/paths in graphviz. Ideally, this could be done wiht a primary/secondary/(possibly tertiary) color, with the dashed connectors, but that didn't seem to be an attribute that could be specified.

Also, as a side note: there are different styles of banding, such as diagonal stripes instead of vertical stripes, though those are usually seen in UTP/STP cables.

[SnowMB]

Are there any thoughts on how to actually implement this?

Ideally there would be a way to layout the graph and ask graphviz how long the edges are, than fractions for the coloring could be computed and the graph could be redrawn with colors.
Otherwise I am not sure yet. With a solid color and a style="dashed" edge on top we can achieve 2 colors but not more. Maybe using solid for color 1, dashed for color 2 and dotted for color 3? I have to check how this looks. 🤔

I assume we'd lose the outlines on the wires

If we can reliably draw multiple edges on top of each other you can draw a wider black edge in the backround and the colors on top like my example, so this would not be an issue.

Also, as a side note: there are different styles of banding, such as diagonal stripes instead of vertical stripes, though those are usually seen in UTP/STP cables.

I don't think, that there are actually diagonal bands. For me it looks more like a twisted stripe. 😝

[SnowMB]

So playing with the table for the wire I got some banded rendering inside the wire node and can match the dimension of the edge with a little bit trial and error. This also got me thinking of possibilities to improve the rendering of the existing multicolor stripe method. (instead of rendering 3 distinct wires for singlecolor to match multicolor width just play around with penwidth attribute of edges and height attribute of the table rows. I also would use the border attribute instead of drawing extra table rows for top and bottom borders.

For the time being I think in this particular case the differences in wire length and resulting band width are still ok. But I can see that mixing very long with very short wires can look ugly. I will start digging into the python scripts the next days to make a test implementation with the existing limitations so that you can try it out.

[formatc1702]

How would your striped wires look if you made them the same thickness as the current single-color ones (see example gallery)?

I added in a feature that pads single-color wires to match the thickness of the current lengthwise striped ones, but only if there are any multicolor wires present at all, since I find the thinner style more appealing.

Could you attach a new render?

[SnowMB]

Sure this is an easy to change detail 😄

Here you go:

[myself248]

This raises another question, whether the colors should be split 50/50, or whether the second color defines thin rings over a base color?

Both styles are in use. Banded coloring may be 50/50 or may be unequal to differentiate "major" versus "minor" colors on each wire.

In the 25-pair code, for instance, each wire has a major and minor color, and it is paired with another wire that has the same two colors but flipped in dominance. So it's essential to be able to show the difference, but the precise ratio is not important and can be chosen for visual effect. (Something like 70/30 vs 30/70 is probably adequately distinct, without reducing the minor color's visibility too much. Overly-small pips of color could be problematic on a printer with poor registration.)

In my personal experience in telecom, some manufacturers use stripes, some use bands, and anyone reading the diagram should have no trouble mentally translating between the two. But it might be nice to be able to pick the visual style to match the wire in use.

There are also 3-band codes in use, for instance ICEA method 5, which is explained quite well here: https://www.buyawg.com/pdf/wire-cable-methods-of-color-coding.pdf

In this case, it's again important to differentiate the base (major) color from the tracers. (Look at wires 22 and 23 for instance.) I'm not personally experienced with this code but I've run across it in catalogs, so I don't know if there's a standard for the proportions.

[Appended by @kvid 2024-09-16]: It seems the PDF linked above disappeared some time before 2023-12-24, but this archived version from 2018-08-27 might be identical to what @myself248 referred to in 2021.

[robotskirts]

Adding this cable I had to work with which featured different quantities of banding.

[tobiasfalk]

https://forum.graphviz.org/t/multicolor-edges-coloring-style-schemata/2438

[kvid]

@tobiasfalk wrote:

https://forum.graphviz.org/t/multicolor-edges-coloring-style-schemata/2438

Where steveroush links to: https://gitlab.com/graphviz/graphviz/-/issues/1069#note_1364067228

As far as I can see, up to now, the only suggestion is using stroke-dasharray for SVG output that can set the dash/gap lengths and a repeated pattern of those. However, only one color is used, so you still need to stack edges to obtain multicolored wires, I guess.

[tobiasfalk]

@kvid Yea, I think this is pretty much on hold until Graphviz implements some more advanced style definition, or someone finds some other way to hack this together with just one edge.
I would also say a solution where multiple edges are overlapping are not really good and would lead to more problems than solution, I saw this with using the edge inside the table for the wire.

[tobiasfalk]

I have acheaft this with some SVG editing, as with my Idea in #423 one could implement this.

<svg width="477pt" height="203pt"
 viewBox="0.00 0.00 477.00 203.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<defs>
    <linearGradient id="myGradientA" x1="0" x2="20" gradientUnits="userSpaceOnUse" spreadMethod="repeat" gradientTransform="rotate(0)">
      <stop offset="0"    stop-color="#F00000" /> 
      <stop offset="25%"  stop-color="#F00000" />
      <stop offset="25%"  stop-color="#00aF00" />
      <stop offset="50%" stop-color="#00aF00" />
      <stop offset="50%"  stop-color="#0000aF" />
      <stop offset="75%" stop-color="#0000aF" />
      <stop offset="75%"  stop-color="#0FFFFF" />
      <stop offset="100%" stop-color="#0FFFFF" />
    </linearGradient>
    <linearGradient id="myGradientB" x1="0" x2="20" gradientUnits="userSpaceOnUse" spreadMethod="repeat" gradientTransform="rotate(35)">
      <stop offset="0"    stop-color="#F00000" /> 
      <stop offset="25%"  stop-color="#F00000" />
      <stop offset="25%"  stop-color="#00aF00" />
      <stop offset="50%" stop-color="#00aF00" />
      <stop offset="50%"  stop-color="#0000aF" />
      <stop offset="75%" stop-color="#0000aF" />
      <stop offset="75%"  stop-color="#0FFFFF" />
      <stop offset="100%" stop-color="#0FFFFF" />
    </linearGradient>
  </defs>

<!-- X1&#45;&#45;W1 -->
<g id="edge5" class="edge">
<title>X1:e&#45;&#45;W1:w</title>
<path fill="none" stroke="#000000" stroke-width="2" d="M39.5,-49.75C103.29,-49.76 119.28,-48.01 183.5,-48"/>
<path fill="none" stroke="url('#myGradientA')" stroke-width="2" d="M39.5,-51.75C103.5,-51.75 119.5,-50 183.5,-50"/>
<path fill="none" stroke="#000000" stroke-width="2" d="M39.5,-53.75C103.72,-53.74 119.71,-51.99 183.5,-52"/>
</g>
<!-- X1&#45;&#45;W1 -->
<g id="edge7" class="edge">
<title>X1:e&#45;&#45;W1:w</title>
<path fill="none" stroke="#000000" stroke-width="2" d="M39.5,-25.25C103.12,-25.29 119.08,-22.04 183.5,-22"/>
<path fill="none" stroke="url('#myGradientB')" stroke-width="2" d="M39.5,-27.25C103.52,-27.25 119.48,-24 183.5,-24"/>
<path fill="none" stroke="#000000" stroke-width="2" d="M39.5,-29.25C103.92,-29.21 119.88,-25.96 183.5,-26"/>
</g>

[tobiasfalk]

[tobiasfalk]

Problem with this, it does not follow the path, but bot is consistent in the X axis (left tot right)

[tobiasfalk]

a gradiant alog the path seams not posble, simply because of the limitations of SVG,

[tobiasfalk]

One solution is similar to the multiple dashes overlapped but this time not done in GraphViz but in SVG.

<path fill="none" stroke-dasharray="10 30" stroke="#0fffff" stroke-width="2" d="M39.5,-51.75C103.5,-51.75 119.5,-50 183.5,-50"/>
<path fill="none" stroke-dasharray="0 10 10 20" stroke="#00aa00" stroke-width="2" d="M39.5,-51.75C103.5,-51.75 119.5,-50 183.5,-50"/>
<path fill="none" stroke-dasharray="0 20 10 10" stroke="#F00000" stroke-width="2" d="M39.5,-51.75C103.5,-51.75 119.5,-50 183.5,-50"/>
<path fill="none" stroke-dasharray="0 30 10 0" stroke="#0000aF" stroke-width="2" d="M39.5,-51.75C103.5,-51.75 119.5,-50 183.5,-50"/>

[tobiasfalk]

The drawback of stroke-dasharray is that it would lead to ugly transactions at the Wire Box, the following example uses the output of #412 and manually stitched the paths of the three edges together:

In this regard the linearGradient method is better, here the colors are consistent, but therefore they do not follow the direction of the wire/edge and the color does not start at either end of the wire, it this case one can see this as a mask that lets a Pattern of Vertical lines through, the following example uses the output of #412 and the first wire X1:1/X2:1 manually stitched the paths of the three edges together and X1:2/X2:2 not stitched together:

[tobiasfalk]

In the first, sticking together or not does not change anything.

[limitedAtonement]

I would love to see something released even if it's ugly ;-)