Sorry - incoherent typing fingers. That should have read "You can't win this one by re-ordering".
If I may comment on two aspects of your sample plot...
1) The ordering of x/y/major/minor is only an issue, indeed only detectable, because you have assigned different colors to the different grid lines. Is there really a need to do this?
2) The grid and the normal axis tic marks and labels are all drawn at the same time by the program, so it would be difficult to order the subcomponents relative to each other. But I see that the sample plot uses "set [x|y]zeroaxis" rather than the default axis tics and labels. That is a separate set of commands and indeed could be given a "front|back" property separate from the grid properties. Let's see if that relatively simple addition solves much of the ugliness.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you please post your script next time? It's very hard to see anything on that jpeg.
This script here is trying to cause trouble, and I'm not sure all of it is worth fixing. Tics and their labels should arguably all stay on top of any part of the grid.
And here's a small patch that redraws the axis tic labels after drawing the grid lines, but only if the grid is active. If the grid is active that means the labels are drawn twice, but that shouldn't hurt in practice.
As said, my script was just trying to cause as much trouble as possible ;-). Before trying to reproduce th OP's plot, i've hardly ever used more that a simple "set grid" command.
The one thing that really should get fixed imo is that explicit ticlabels always land behind the grid, as opposed to "normal" ticlabels. Makes them kind of useless here. I guess it'd be easy to just print them last, instead of first.
The rest (first creating all tic positions, and then plotting all grid lines, tics, labels in the right/customisable order) would require rewriting a large portion of axis.c, right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Changing the order of the grid lines would take a substantial reorganization. I remain unconvinced that better support of different colors for x/y major/minor grid lines is important enough to worry about. The issue of tic labels being over-written is more serious. There is already a command "set tics {front|back}" but it turns out that internally that is treated as an alias for "set grid {front|back}". So currently you cannot move the tic labels in front of the grid. But that much is fixable.
So here is a revised patch, slightly bigger than the first one but only because it touches more files. This patch doesn't change anything about how the grid itself is drawn (including labels) but it implements "set tics front" as a new operation that redraws all the tics and tic labels in front of everything else. That actually makes it match the current documentation! It still leaves duplicate copies of the labels produced by the current grid-drawing operation, but I suppose that can be cleaned up later if it causes a problem.
Looks very good with "set tics front", but the "back" setting should still leave the tics in front of the grid, i guess. It's not a grave matter though, imho, because ticlabels should nearly always be on top. Labels that are cut in half by plot lines just look stupid.
Perhaps "set tics front" should be made the default for 5.1?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps "set tics front" should be made the default for 5.1?
I suppose. But this is only relevent if you move the axis tics into the middle of the plot, right? If you are going to issue the extra command anyhow, it's not much burden to add the "front" part: set tics axis front
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you have assigned different colors to the different grid lines. Is there really a need to do this?
Yep, it helps to accentuate scale and make nice graphs.
Here's the better sample:
unset border
set tics front
set grid nopolar
set grid xtics mxtics ytics mytics
set grid back lt 1 lc rgb 'magenta' lw 4, lt 1 lc rgb 'cyan' lw 4
set key opaque box
set zeroaxis lt 1 lc rgb 'black' lw 3
set mxtics 3
set mytics 3
set xtics 2000 axis font 'sans:Bold,14'
set ytics 2000 axis font 'sans:Bold,14'
set xrange [-10000:10000]
set yrange [-10000:10000]
plot 7500*sin(x/5000) lw 4 lc rgb 'red'
Using multiplot to sort out the grid's depth order is not actually very complicated, see below. You just plot one empty graph with the mtics on, and then the real graph with mtics off. Or you simply plot it twice, then you don't even have to fix the axis ranges beforehand.
set multi
unset border
set xrange [-10000:10000]
set yrange [-10000:10000]
set xtics 2000 axis font 'sans:Bold,14'
set ytics 2000 axis font 'sans:Bold,14'
set grid xtics mxtics ytics mytics
set grid back lt 1 lc rgb 'magenta' lw 4, lt 1 lc rgb 'cyan' lw 4
set mxtics 3
set mytics 3
plot -1e8 notitle
set grid xtics nomxtics ytics nomytics
set key opaque box
set zeroaxis lt 1 lc rgb 'black' lw 3
set tics front
plot 7500*sin(x/5000) lw 4 lc rgb 'red'
unset multi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can win this one be re-ordering. Someone will always want one order, someone else another.
This seems like a rare requirement in any case.
Maybe use multiplot in full-screen mode, drawing the grid in one dummy-run plot and then turning it off for the real plot?
What kind of re-ordering?
Who wants a grid to overlap tic marks? Show me that fool :-)
Multiplot solution looks like a crutch, to be honest.
Last edit: arbitrary-dev 2015-11-09
Sorry - incoherent typing fingers. That should have read "You can't win this one by re-ordering".
If I may comment on two aspects of your sample plot...
1) The ordering of x/y/major/minor is only an issue, indeed only detectable, because you have assigned different colors to the different grid lines. Is there really a need to do this?
2) The grid and the normal axis tic marks and labels are all drawn at the same time by the program, so it would be difficult to order the subcomponents relative to each other. But I see that the sample plot uses "set [x|y]zeroaxis" rather than the default axis tics and labels. That is a separate set of commands and indeed could be given a "front|back" property separate from the grid properties. Let's see if that relatively simple addition solves much of the ugliness.
Can you please post your script next time? It's very hard to see anything on that jpeg.
This script here is trying to cause trouble, and I'm not sure all of it is worth fixing. Tics and their labels should arguably all stay on top of any part of the grid.
Here's a script and the resulting figure showing it is not so bad, really. Can you use this as a starting point and highlight any remaining problems?
And here's a small patch that redraws the axis tic labels after drawing the grid lines, but only if the grid is active. If the grid is active that means the labels are drawn twice, but that shouldn't hurt in practice.
As said, my script was just trying to cause as much trouble as possible ;-). Before trying to reproduce th OP's plot, i've hardly ever used more that a simple "set grid" command.
The one thing that really should get fixed imo is that explicit ticlabels always land behind the grid, as opposed to "normal" ticlabels. Makes them kind of useless here. I guess it'd be easy to just print them last, instead of first.
The rest (first creating all tic positions, and then plotting all grid lines, tics, labels in the right/customisable order) would require rewriting a large portion of axis.c, right?
Changing the order of the grid lines would take a substantial reorganization. I remain unconvinced that better support of different colors for x/y major/minor grid lines is important enough to worry about. The issue of tic labels being over-written is more serious. There is already a command "set tics {front|back}" but it turns out that internally that is treated as an alias for "set grid {front|back}". So currently you cannot move the tic labels in front of the grid. But that much is fixable.
So here is a revised patch, slightly bigger than the first one but only because it touches more files. This patch doesn't change anything about how the grid itself is drawn (including labels) but it implements "set tics front" as a new operation that redraws all the tics and tic labels in front of everything else. That actually makes it match the current documentation! It still leaves duplicate copies of the labels produced by the current grid-drawing operation, but I suppose that can be cleaned up later if it causes a problem.
Looks very good with "set tics front", but the "back" setting should still leave the tics in front of the grid, i guess. It's not a grave matter though, imho, because ticlabels should nearly always be on top. Labels that are cut in half by plot lines just look stupid.
Perhaps "set tics front" should be made the default for 5.1?
Perhaps "set tics front" should be made the default for 5.1?
I suppose. But this is only relevent if you move the axis tics into the middle of the plot, right? If you are going to issue the extra command anyhow, it's not much burden to add the "front" part:
set tics axis frontNo, it really shouldn't. This is still a plotting program, not a word processor. As such, any default that obscures data would be just wrong.
Yep, it helps to accentuate scale and make nice graphs.
Here's the better sample:
Last edit: arbitrary-dev 2015-11-10
Using multiplot to sort out the grid's depth order is not actually very complicated, see below. You just plot one empty graph with the mtics on, and then the real graph with mtics off. Or you simply plot it twice, then you don't even have to fix the axis ranges beforehand.
The "set tics {front|back}" change is now in cvs for 5.0 and 5.1