Is there a reason to not use mcolors._check_color_like(color=color) as is done in set_color?

Looks like set_color changed since the original PR. I completely missed that and will change it.

This should not be here as it is a continuation of the previous line.

Please do not remove empty lines.

I don't think this is enough. This will just draw a solid line in the background and doesn't look good if you set an alpha on the line. I think you'll need to unwrap the dash pattern and do the inverse dashed pattern.

Good point! It also strikes me that the dash cap style can cause some issues here. But I guess that one can probably live with that having a round dash cap style with alpha gives a less than ideal result?

The option would be, I guess, to introduce an "inverted" round cap style. Also, projecting caps will require a bit of extra work here, but should be more easily doable since one knows the additional overlap (linewidth/2).

So my initial attempt at this failed badly because I assumed that offset would add an extra "gap" to the start of the sequence, when in fact it seems to remove a section from the start instead. I couldn't find this documented anywhere: this docstring links to a "blue book" that might help, but that pdf seems to be only available on certain high security systems.

I've sanity checked this by adapting the linestyle demo, plotting with and without an initial offset of 1, so I know it works for a variety of dash styles:

It also turned out that the line underneath was problematic even without setting the alpha: the previous test image showed outlines around the lines which disappeared when I updated the main code:

I couldn't find this documented anywhere

I was under the same impression as you. That is clearly something that can be documented more clearly. Although now that I know it, I can sort of understand what offset means, and explain this line in the code:

I opened #23220 to track this.

when in fact it seems to remove a section from the start instead. I couldn't find this documented anywhere: this docstring links to a "blue book" that might help, but that pdf seems to be only available on certain high security systems.

https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf page 667

The offset operand can be thought of as the “phase” of the dash pattern relative to
the start of the path. It is interpreted as a distance into the dash pattern (measured
in user space units) at which to start the pattern. Before beginning to stroke a
path, the stroke operator cycles through the elements of array, adding up dis-
tances and alternating dashes and gaps as usual, but without generating any out-
put. When the accumulated distance reaches the value specified by offset, it begins
stroking from the starting point of the path, using the dash pattern from the point
that has been reached. Each subpath of a path is treated independently; the dash
pattern is restarted and the offset reapplied at the beginning of each subpath.

I'm not sure this should get an alias. It doesn't seem obvious to me what "oc" means at first glance.

Thanks, I had wondered if this is high profile enough to warrant an alias.

We can always add one later.

I think "Striped" with a d sounds better, but that is just a personal preference. Might be regional dialect?

"Stripey" feels more natural to me but I don't have a strong opinion. Since the original PR and the issue used "striped" that's at least 3 votes to 1!

I think this is a fact of the way this is implemented with two separate lines, so the renderer doesn't know they are meant to be the same object and so then it blends the transparencies.

Another option for the striped lines may be to do something similar to the multi-colored line example...
https://matplotlib.org/stable/gallery/lines_bars_and_markers/multicolored_line.html

The multicolored line is somewhat different from dashes because it assigns values/borders in data coordinates. I.e. you can zoom in to one color segment. With dashes however, we don't want the users to zoom in to a single dash. The dash size is independed of the data coordiantes.

Anyway, I've proposed to decleare this feature experimental so that we still have the freedom to come up with a different implementation.

Interestingly, remove_text does not apply to legend. (Should be investigated at some point).

Still, I propose not to pick up text in the reference image. Do you want the legend entries as a test that the lines are drawn correctly there? If not remove the legend, if yes use label=' '.

@oscargus asked for the legend so I guess he wanted to check the legend lines are drawn correctly.

Correct! Completely happy without text!

TL;DR I think we should go with gapcolor.

I'm very sorry for going back and forth, but I just realized how this parameter fits into the whole color story.

Seeing this makes me wonder whether second_color is actually a good name Because for

    ax.plot(x, y, linestyle='o', color='orange', second_color='blue',

color affects the marker but second_color does not. This is a certain asymmetry.

Actually the color mechanism is somewhat complicated:

Observations:

• color is a global parameter that can affect multiple visual parts. The behavior is reaonable: Color all visible parts with this color". (It's correct that this does not apply to the additional marker face of half-filled markers, because that would make them fully filled.)
• Conceptually the gapcolor (I call it like this for now) is similar to markerfacecoloralt - it should and isn't affected by color.
• We don't have an explicit linecolor parameter. That's also ok. Think: We start with a base color and one can optionally change all marker parameters on top of this.

When only thinking about the line part color + second_color is a perfectly good API. However, taking the whole picture into account, it's not specific enough. IMHO the name has to contain the visual part that is addressed. My suggestions in order of preference:

• gapcolor
• second_line_color (very clear, but very long).
• linecoloralt (rhymes with markerfacecoloralt, but a bit awkward to have ...alt without a linecolor and I don't think we need to add that).

Way too late to change I know, but I don't think it would be bad to have a linecolor alias b/c in the marker+line case, is kinda confusing that the line color is color but the markercolor is markerfacecolor + markeredgecolor (also that there's no markercolor)

I think if we had second_line_color then a user might expect there to be a line_color. Someone (@efiring I think) mentioned that “alt color” has problematic meaning in some places.

So gapcolor also seems best to me.