Repository navigation
hatch linewidth patch #235
Description
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
Activity
jkseppan commented on Aug 27, 2011
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 commented on Jul 13, 2012
@ddale: Do you know if we can still access the original SF issue?
pelson commented on Sep 2, 2012
@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 commented on Sep 3, 2012
@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 commented on Sep 3, 2012
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 commented on Sep 3, 2012
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 commented on Sep 4, 2012
@efiriring, thanks!
dmcdougall commented on Sep 4, 2012
@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:
This creates a separate branch for your changes.
pelson commented on Oct 18, 2012
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 commented on Nov 14, 2014
Was this feature ever implemented ?
jenshnielsen commented on Nov 14, 2014
I am guessing that the relevant pull request is #1200 Which was not merges so no it doesn't look like it
rodrigob commented on Nov 14, 2014
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 commented on Nov 14, 2014
If you would like to pick it up, that would be great!
rabernat commented on Nov 11, 2015
I just hit this problem. Has it really not been fixed yet?
rodrigob commented on Nov 11, 2015
nope. the PR never made it in.
WeatherGod commented on Nov 11, 2015
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
mdboom commented on Nov 11, 2015
I'm going to reopen this for examination during the style changes. There's sort of two questions here:
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.