Selecting or setting hatching patterns?

4 views (last 30 days)
dpb
dpb on 23 Nov 2014
Edited: dpb on 24 Nov 2014
AFAICT there are no predefined hatching patterns to apply to bar or surf patches for distinguishing areas? Seems like a major shortcoming if so.
Problem: Have a series of data which can't find a suitable color mapping that shows enough difference from one series to next that can distinguish the adjacent areas on black/white printing and still have something that looks like anything at all in the figure.
"Jet" or the like is simply too garish to be acceptable to show as is. 'Bone' or 'gray' ' or 'copper' with 8 groups don't have sufficient separation on the black tones using the default even spacing between the 63 levels to distinguish them.
Managed with much effort to modify the scaling to be nonlinear between 1:63 and get a (barely) discernible difference but it's a pita to do and takes trial and error to set the differences.
Surely there's a simple way to add some cross-hatching to an area to make them stand apart but I surely can't find it in the doc's...nor any examples thereof.
I've used Matlab 30 yr nearly but I rarely ever found much call for bar plots and their ilk until now looking at some economics data; everything else has always been more suited to line plots and the like so am rank novice in the area, basically...
ADDENDUM
Searching uncovered this gem from 2009 --
Support recommended some File Exchange postings -- having now essentially wasted almost two hours, it appears there still is no real solution -- a couple of submittals work at least reasonably well for the objects in the graphics axes, but none can handle the corresponding legends.
hatchfill and its derivatives mung on the right patch object but don't manage to get the legend object patches rendered to be visible.
The much older hatch is actually more flexible in many ways in that it doesn't destroy existing colors by turning them black/white but it can't handle the legend at all. The problem is one can't make the legend axis handle the current axes that gca will return and they all end up having to do handle-diving to try to find the proper object to mung on.
It's also HIGHLY inconvenient that for some reason the line primitive will not accept an axes handle--whassup w/ that?
All in all, it reinforces the difficulties of handle graphics when they aren't prepackaged and highlights some obvious shortcomings that just seem (at least to me) incomprehensible they are still missing... :(
If anybody does have any solutions, would appreciate knowing of them; meanwhile, if TMW is listening, "fix it!". It's simply absurd this kind of facility wasn't built in in original release; many other graphics routines have had such, like, since forever...there were CALCOMP routines clear back on the old CDC CYBER in the '60s that did it.
ADDENDUM 2
After way too much effort, finally worked thru the problem in hatchfill to get it to work with legends as well as patch objects on main axes object.
It still has the disadvantage it doesn't allow anything except black/white whereas hatch draws on background existing w/ xor or somesuch; haven't quite deciphered it yet.
hatchfill does better job of rendition for smoothness, etc., hatch is more convenient interface and does leave the background color alone if desired.
Be A_GOOD_THING (TM) if TMW would clean up all the messies and submit a robust solution; even better if would build in some predefined hatching patterns.
UPDATE
Spoke too soon on the fix to hatchfill -- the patch to fix legends turns out to have broken the drawing for areas...not clear as yet why nor how to cure... :(
What a pit(proverbial)a(ppendage)...
FINAL CHAPTER (for now, anyways)...
Solved the issue above regarding legends vis a vis axes patches objects--not clear yet fully the reason for the problem but the solution turns out to be to add yet another conditional in hatchfill when it draws the hatching patterns -- check if the passed object handle is/is not gca; if is, use line on gca; otherwise use plot with the passed handle (which has already been confirmed to be an axes object). Now why line and plot on the gca handle have correct and totally screwed-up results for the patches is something I've not been able to ferret out and don't have time to waste pursuing at the moment.
Posted the patches I made on the File Exchange and perhaps some other poor unfortunate will stumble over this and save a few hours or days and some hair off their head...
Again my assessment overall is gross oversight by TMW.

Answers (0)

Products

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!