Skip to content

[WiP] ENH: Add a “loose” version of the dashed line styles #8048

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

afvincent
Copy link
Contributor

@afvincent afvincent commented Feb 8, 2017

Rationale

Several tickets pointed out that the defaults dashed line styles have a “frequency” that is too high (#7991), especially when using a “dotted” style for grid lines (#6515). This PR aims at introducing a “loose” version of these dashed line styles, in the spirit of what had been suggested in #7087 . Coupled to sane defaults (still to be found/discussed), “casual users” (or myself :) ) could have access in an easy fashion to “less frequently” dashed lines. And “power-users” could even tweak these additional dash patterns in their matplotlibrc file to get a fast & easy access to supplementary dash patterns.

PS: not sure if it belong to the “API Changes” flag, so feel free to remove if it does not…

Implementation

Three new rcParams are added: lines.dashed@loose_pattern, lines.dashdot@loose_pattern and lines.dotted@loose_pattern. Currently, they are similar to the rcParams lines.dashed_pattern, lines.dashdot_pattern and lines.dotted_pattern but with off inks parts that have been tripled in length. This specific value can of course be discussed.

One can now use these three new line styles by adding “@Loose” after the line style “ID string”. Here is for example the case for loosely dotted lines:

  • ax.plot(…, linestyle="dotted@loose")
  • ax.plot(…, linestyle=":@loose")
  • ax.plot(…, ":@looseob") # MATLAB-style (yes, it starts to become verbose/hard to read…)

Feel free to suggest anything better than using the suffix “@Loose” to specify that one wants a loosely dashed line style.

Still to be done

  • update the Line2D docstring in matplotlib.lines
  • update the test test_linestyle_variants in tests/test_lines.py (I do not really understand how this test works: it looks like an image test but does not have the @image_comparison decorator)
  • show this new functionality somewhere in the documentation
  • optional (could be done in a further PR): add a new line style variant “dashdotdot”/“-..” (and its “loose” variant)

Example

A small example of what it does currently looks like:

Script source:

import matplotlib.pyplot as plt

fig, ax = plt.subplots(num="Testing named line styles", figsize=(9.6, 6.4))

for ii, ls in enumerate(['-', 'solid',
                         '--', 'dashed',
                         '-.', 'dashdot',
                         ':', 'dotted',
                         '--@loose', 'dashed@loose',
                         '-.@loose', 'dashdot@loose',
                         ':@loose', 'dotted@loose'
                        ]):
    ax.plot([ii, ii + 1], linestyle=ls,
            color='tab:red' if 'loose' in ls else 'tab:blue', label=ls)

    # MATLAB-like all in one line style
    if any(special_char in ls for special_char in ('-', '.', ':')):
        allinone_ls = ls + ">k"
        ax.plot([-ii//2, -(ii//2 + 1)], allinone_ls, label=allinone_ls)

ax.legend(loc='lower center', bbox_to_anchor=(0.5, 1.02), ncol=7,
          columnspacing=1)
fig.subplots_adjust(top=0.85)  # make space for top legend

for ext, dpi in (('.png', 100), ('.pdf', None)):
    fig.savefig(fig.get_label().replace(" ", "_") + ext, dpi=dpi)

Edit: typo…

@afvincent afvincent added this to the 2.1 (next point release) milestone Feb 8, 2017
@afvincent afvincent mentioned this pull request Feb 8, 2017
@QuLogic
Copy link
Member

QuLogic commented May 28, 2017

Seems this didn't get much traction; maybe a post on the list might garner some views? Now that line width clipping is gone, what is your current stance on this change?

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Aug 29, 2017
@afvincent afvincent modified the milestones: v2.2, v3.0 Feb 2, 2018
@afvincent
Copy link
Contributor Author

Huh, sorry @QuLogic, just notice your post now... (The notification is likely to have sunk in my inbox 🐑)

I still think that this could be an interesting feature, but it needs to be better formalized before going any further. I think that it might be worth giving a shot at the the devel-list to try getting traction. I am also wondering about a trick that @anntzer made in #10244 .

For the moment, simply re-milestoning it for 3.0, with the hope that I will manage to find time to be a bit more active on this in the next few months...

@tacaswell tacaswell modified the milestones: v3.0, v3.1 Jul 9, 2018
@jklymak jklymak modified the milestones: v3.1.0, unassigned Feb 9, 2019
@jklymak
Copy link
Member

jklymak commented Feb 9, 2019

Feel free to re-assign the milestone if you get back to this...

@jklymak jklymak marked this pull request as draft July 23, 2020 16:43
@story645 story645 modified the milestones: unassigned, needs sorting Oct 6, 2022
@github-actions
Copy link

github-actions bot commented Apr 6, 2023

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Apr 6, 2023
@anntzer
Copy link
Contributor

anntzer commented Apr 18, 2023

I think the main question here is just whether we can find a reasonably syntax for user-specified dashes. My guess is "yes, as long as we don't try to support them in the plot shorthand syntax" (which is carefully designed to minimize confusion between color/marker/linestyle, but even then the introduction of the data kwarg made things awkward as the shorthand can also be data kwarg entries).
If we only want to support linestyle="user-speficied", we can always consider having a rcParams["lines.custom_dash_patterns"] = {"name1": [...], "name2": [...]} (or even rename that more generically to lines.dash_patterns and move the three standard patterns into the dict as well). (Note that this doesn't need anything too bad on the matplotlibrc side; we can easily support that syntax e.g. with ast.literal_eval.)

So closing for lack of activity, but I think there are ways to revisit this if there's interest.

@anntzer anntzer closed this Apr 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants