From: Ethan A M. <sf...@us...> - 2017-10-25 20:18:50
|
On Wednesday, October 25, 2017 12:47:37 PM PDT Achim Gratz wrote: > Achim Gratz writes: > > I don't really know what I'm doing, but this patch seems to fix this > > issue. I don't know if it causes a regression somewhere else. > > I#ve got a PM from Ethan about my patch, but my answer did not seem to > have reached him. I was deferring action because of the freeze on cvs/git commits, but I was planning to include a fix for this in 5.2.1 tarball even it doesn't hit the source repository until the cvs->git conversion completes. > One concern was about my patch ignoring the axis range. If I'm reading > the code correctly, that was taken care of a few lines earlier in the > code when start was getting set to just below the min of the axis. The code is confusing, but it is easy enough to test what happens. What I see is that with your patch "as is" the first x-axis tic mark does not change as I gradually extend the lower end range on x. I added a while loop to push the start point for tic generation back past the lower limit. Note that the tic placement code will simply ignore tics that are out of range, so placing the start point a bit lower than strictly necessary does not hurt. > THe other question was about what this is trying to achieve: This is > about specifying a log series with undefined start and end, working on > an axis which has later been set up to have a defined range whose ends > do not coincide with the major tics. Since the axis can start before > the first major tic inside its range, you must define the start to be > the first correct position just outside the axis min or the minor tics > that still lie inside the range are not visible. Right. I'll send you a copy of the patch and/or a preliminary tarball offline if you like. Ethan > Regards, > Achim. |