[Biopython-dev] Modifications to CircularDrawer

[Leighton Pritchard]

Hi all,

I'm starting to remember why I left circular labelling options alone ;)

On 5 Dec 2012, at Wednesday, December 5, 16:57, Peter Cock wrote:

On Wed, Dec 5, 2012 at 4:29 PM, David Martin <d.m.a.martin at dundee.ac.uk<mailto:d.m.a.martin at dundee.ac.uk>> wrote:

label_orientation: circular|upright  Sometimes it is nice to have a proper circular plot

I'd have to see the code or an example (and it seems any image attachment
will stall your emails for moderation - I'm a moderator but there is some time
delay before this gets that far).

I still don't like 'upright' - but that's a naming issue, rather than one of functionality.

label_placement: inside|outside|overlap|strand which maintains overlap as
default, inside is all inside, outside is all outside, strand is forward outside
and reverse inside.

Perhaps below/above rather than inside/outside and then it could be done
to both the linear and circular drawers? Do you think this is useful then?

'Below' and 'above' are context- (and viewer!) dependent: on a circular diagram 'above' on a feature at 12 o'clock is on the opposite side of the feature when it's 'above' at 6 o'clock.  It's not clear what either would mean for a feature at 3 o'clock or 9 o'clock.  'Inside' and 'outside' are stably relative to the circular track for a feature at any position on the circle, so I prefer them as settings.

I'm not keen on 'overlap' or 'strand', as I'm not clear what kind of label orientation they refer to: for example, what is being 'overlapped'?

Looking at the .pdf, it seems like you've anchored the green labels to the track, rather than to the feature, which I think looks good there - but I'd like to have the option of track vs feature anchoring available via an argument like 'label_anchor', which could be distinguished from 'label_text_anchor'. Including this choice, my preferred arguments would be something like:

label_direction='clockwise'|'anticlockwise' - 'clockwise':
The text looks like it's progressing clockwise (like the green text in the .pdf); 'anticlockwise' like the blue text.  By choosing 'clockwise' or 'anticlockwise' for the appropriate group of features, we achieve part of what I think you might mean by 'upright' (i.e. clockwise from pi/2 to 3pi/2, anticlockwise elsewhere).  That could be handled with an 'auto' option.  This argument essentially dictates label_angle for each feature: more of which later.  It would be nice to have synonyms of 'counterclockwise', 'anticlockwise' and 'widdershins' ;)

label_anchor='track'|'feature'
Describes what element the text bounding box will be anchored to.

label_text_anchor='start'|'end'
Which part of the text bounding box (relative to the text) gets anchored. I think it's a good idea to have this wrap a lower-level setting that has label_text_anchor=float, as a relative location on the feature, where start=0, center=0.5, end=1, and values beyond that offer a label separation, relative to the label size - though I can't imagine why I'd use it over the option below - since spacing would depend on bounding box size - the flexibility could be useful, and you'd have to do that calculation anyway ;)

label_placement='inner'|'outer'
Do we anchor on the track/feature towards the circle centre (inner) or on the other side (outer)?  I think it's a good idea to have this wrap a lower-level representation that has label_placement=float, as a relative location on the feature, where inner=-1,outer=1 as a proportion of track/feature height, and other values place the anchor relative to the feature/track boundary - this again offers a choice of label separation, but one that's uniform for all features.

label_position='start'|'end'|'center'
Where, relative to the feature, do we anchor?  I think it's a good idea to have this wrap a lower-level representation that has label_position=[0,1], as a relative location on the feature, where start=0, center=0.5, end=1.  That gives more flexibility for those who want it (and you have to do the calculation, anyway).

label_orientation='radial'|'horizontal'
Fairly obviously, 'radial' = as it is now, and 'horizontal' is reading like regular text.  But this one's a tricky one, which is why all the labels are radial at the moment ;)  I think that this choice has to either live with ('radial') or override ('horizontal') the label_direction argument.  As with label_direction, this essentially dictates label_angle for each individual feature, which has its own issues (what do we measure the angle relative to?  If it's relative to a common reference, then for a constant angle you get some funny-looking label patterns, and it doesn't look good in bulk.  Relative to a feature-local reference, we can choose the tangent or the normal - but at what point of the feature?  Really, we want that to be the tangent or normal at the anchor point of the text, so that the same angle looks consistent across all features (45deg to the normal at the start of a long feature is different to 45deg to the normal at the centre of that feature, relative to the bottom of the page: this looks weird)).
A complicating issue here with text anchoring is what part of the text box gets anchored: depending on the font, and the string, choosing the top or bottom of the bounding box (which will include ascender and descender spaces) can look weird, so it's probably best to anchor on the midline of the text box.  This avoids a problem with 'anticlockwise' vs 'clockwise' when implemented as a rotation, in that anchoring to the lower left of text, then rotating 180deg around the centre of the text box gives a different final positioning (and anchoring) than anchoring to the midline of the text box, then performing the same rotation.

By appropriate choices of these settings, we can obtain pretty much any labelling style.  We need to keep in mind, though, that the arguments won't be interpreted properly until the Diagram gets passed to the renderer, so 'auto' settings to achieve a particular effect with complicated combinations of arguments dependent on feature location might be better passed with draw().

As specific examples:

1) Let's say the effect we're looking for is for horizontal text, anchored to the outside of the track.  Here we'd need to consider two halves of the diagram.  On the left hand side we need to set label_text_anchor='end', and on the right we set label_text_anchor='start'.  On both sides we set label_orientation='horizontal', label_anchor='track', label_placement='outer'.  However, we need to take care with features towards the top and bottom of the image, as horizontal labels will run into each other, here.

2) Dropping the requirement for horizontal text, we can set label_orientation='radial', label_anchor='track', label_placement='outer' on both sides (maybe this should be the default?), but set label_direction='clockwise', label_text_anchor='end' on the left, and label_direction='counterclockwise', label_text_anchor='start' on the right.

3) If we wanted to label features directly, on the appropriate side of their track, we could set label_anchor='feature' for all features, with label_placement='inner' for reverse-strand, and label_placement='outer' for forward-strand features.

These are some fairly obvious standard settings which could be made available as presets in the calls to draw(), so that the fiddly details are hidden.

Cheers,

L.

--
Dr Leighton Pritchard
Information and Computing Sciences Group; Weeds, Pests and Diseases Theme
DG31, James Hutton Institute (Dundee)
Errol Road, Invergowrie, Perth and Kinross, Scotland, DD2 5DA
e:leighton.pritchard at hutton.ac.uk       w:http://www.hutton.ac.uk/staff/leighton-pritchard
gpg/pgp: 0xFEFC205C tel: +44(0)844 928 5428 x8827 or +44(0)1382 568827





________________________________________________________



This email is from the James Hutton Institute, however the views

expressed by the sender are not necessarily the views of the James Hutton

Institute and its subsidiaries. This email and any attachments are confidential and 

are intended solely for the use of the recipient(s) to whom they are addressed.

If you are not the intended recipient, you should not read, copy, disclose or rely on 

any information contained in this email, and we would ask you to contact the 

sender immediately and delete the email from your system.  Although the James 

Hutton Institute has taken reasonable precautions to ensure no viruses are present 

in this email, neither the Institute nor the sender accepts any responsibility for any 

viruses, and it is your responsibility to scan the email and any attachments.



The James Hutton Institute is a Scottish charitable company limited by guarantee.

Registered in Scotland No. SC374831

Registered Office: The James Hutton Institute, Invergowrie Dundee DD2 5DA. 

Charity No. SC041796