hatch linewidth patch

[ddale]

Original report at SourceForge, opened Tue Feb 22 17:26:22 2011

The pdf backend uses a 0.1pt linewidth for hatch marks, which, depending on scaling and ultimate output, can make them impossible to see. I haven't looked at any non-pdf backends (pdf seems to be the only one that implements a writeHatches function), and I don't know if the rc var name is reasonable, but this seems like the beginning of a fix everyone can enjoy.

SourceForge History

• On Tue Feb 22 17:26:22 2011, by jcmdev0: File Added: 402433: hatch_linewidth_svn.diff

[jkseppan]

I can't access the patch: clicking on the "Original report" link shows a page displaying the error message "Error - The Tracker has been disabled for this group".

[pelson]

@ddale: Do you know if we can still access the original SF issue?

[pelson]

@jcmdev0 : Are you the original author of this. I am interested to know if you have still got the diff you provided. Sadly we lost it in the migration from sourceforge to github. If not, we will have to close this issue. Thanks.

[jcmdev0]

@pelson: I don't think I have the patch file any more. I think I remember enough of what it looked like to try to cook it up again real quick.

[jcmdev0]

I don't see a way for me to add a patch to this issue on github? I made a fork that has a hatch width change for the ps and pdf backends: https://github.com/jcmdev0/matplotlib

[efiring]

Make a pull request from your fork, and in that pull request reference the present issue number as #235; that should automatically make a link from here to the PR. If it doesn't, you can refer to the pull request from here, and that will link the two. Also, if you haven't already, see http://matplotlib.org/devel/index.html.

[jcmdev0]

@efiriring, thanks!

[dmcdougall]

@jcmdev0 You can only have one pull request per branch. So you won't be able to submit another pull request while the changes on your master branch are still waiting to be merged. If, in the future, you'd like to have more than one pull request open at a time you can do the following:

git checkout -b my_new_feature master
# hack hack hack
git commit -a
git push origin my_new_feature

This creates a separate branch for your changes.

[pelson]

Now that @jcmdev0 has made the PR, I will close this obsolete issue.

@jcmdev0 : Thank you ever so much for dragging this back into life. The move to GitHub has been a real good change, but it did have some negative side effects (this issue being a good example of that), so your work is greatly appreciated!

[rodrigob]

Was this feature ever implemented ?

[jenshnielsen]

I am guessing that the relevant pull request is #1200 Which was not merges so no it doesn't look like it

[rodrigob]

Any chance of having this issue re-opened ? What stopped a merge last time (other than git issues) ?

Just got bitten by this bug while creating a last minute figure for a deadline (had to edit exported SVG by hand !),

[tacaswell]

If you would like to pick it up, that would be great!

[rabernat]

I just hit this problem. Has it really not been fixed yet?

[rodrigob]

nope. the PR never made it in.

[WeatherGod]

Looking over the PR, it looks like tests were failing and the PR was
incomplete anyway. There are some fundamental issues with how hatching is
implemented that made it difficult to complete. There is no one place for
hatching to be taken care of, and we even have a place where hatching is
implemented in some C++ code, so it doesn't get any direct access to
rcParams. Hatching might need an overhaul first before this feature can get
added.

On Wed, Nov 11, 2015 at 11:52 AM, Rodrigo Benenson <notifications@github.com

wrote:

nope. the PR never made it in.

—
Reply to this email directly or view it on GitHub
#235 (comment)
.

[mdboom]

I'm going to reopen this for examination during the style changes. There's sort of two questions here:

1. What is the right default width for hatchlines? I'd argue the current default is not ideal (and it's also not the same across backends).
2. Exposing that as a parameter both in the hatch specifier and an rcParam

I'd say resolving (1) is critical for 2.0 while we're changing other style things. (2) would also be really nice, but could be punted on if we can't get it done.