Re: tic marks for transformed axes

[Ethan A M. <merritt@u.washington.edu>]

On Friday 26 December 2003 03:26 pm, Jim Van Zandt wrote:
>
> I've checked code into CVS that implements levels 0 and 1.
> I'd appreciate if you would run the demo

Jim:

	I ran into a minor issue when updating my patch for
handling string data so that it would apply on top of your new
code.  My patch revises add_tic_user() so that it maintains the
tic entries as sorted lists, allowing only one tic entry for any
given axis coordinate. Your demo scripts revealed a difference
between my patched version and the current behaviour,
but in thinking about it I decided both were incorrect.

The issue is what to do when a minor tic entry and a 
major tic entry both have the same coordinate.  My code
was keeping whichever was specified last.  The current
code keeps both.  Either way potentially causes a
problem, either by over-printing two labels at the same 
place or by losing a desired tic label.

I modified my patch so that only the tic with the lowest
"level" code is kept; i.e. major tics trump minor tics.
This makes your demo scripts behave the same as on
the unpatched cvs version.
I *think* this is the right thing to do, but maybe someone
can offer arguments for a different approach.  Would there
ever be explicit minor tic labels that should over-ride the
[possible null] major tic labels?

I don't see an easy way to even detect this condition in
the current code, though.  So if both major tic labels and
minor tic labels are present they will print on top of each
other at major tic locations.  Maybe we can live with this
though the next release.   Or else I could break out just
the sorted-tic-lists part of the datastrings patch and apply
that to the cvs version sooner rather than later. 

What do you all think?


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle