octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rudimentary tick positions


From: Shai Ayal
Subject: Re: rudimentary tick positions
Date: Tue, 5 Feb 2008 07:39:44 +0200

On Feb 5, 2008 12:03 AM, Michael Goffioul <address@hidden> wrote:
> On 2/4/08, Shai Ayal <address@hidden> wrote:
> > attached is a patch for rudimentary tick position calculations. It is
> > a translation of Tom Holroyd's python code which he posted to this
> > list some weeks ago (Tom, I hope that by posting the code here you
> > agreed to it's use in octave ...).
> > What is missing is:
> > *) log axes ticks
> > *) minor ticks
> > *) does not take into account the axes size and font size to eliminate
> > tick overruns
> > *) gnuplot interaction
> > *) your favorite feature here
> >
> > Still, I think it is good enough to serve as a basis to the above 
> > improvements.
>
> Shouldn't autoscale and autotick be combined (axis limits are extended to
> the next tick)?
>
> I was thinking about something like (in algorithmic language):
>
> if (axis_mode == "auto")
>   limits = get_raw_limits(); // compute raw limits based on children
> else
>   limits = get_manual_limits();
> tick_step = get_best_tick (limits);
> if (axis_mode == "auto")
>   limits = extend _limits_to_next_tick (limits, tick_step);
> ticks = compute_ticks (limits, tick_step);
>
> Michael.
>

Well, we already have get_axis_limits in graphics.cc which attempts to
find the "nicest" limits, So the limits are probably "nice" by the
time we get to calc_ticks. However I will look at them to see that
they are "compatible" in the sense that they both agree on the meaning
of "nice"

Shai


reply via email to

[Prev in Thread] Current Thread [Next in Thread]