Sorting Group Labels

[sdenarie]

Hello,

I have been working with TreeViewer recently and I have found it very useful for visualizing my phylogenies in a very aesthetically pleasing form. However, I am having some difficulty with the Group Labels feature. When adding some group labels, there are large gaps between some of the boxes where certain labels could easily fit next to each other, but those labels are for some reason separated out anyway, producing messy results. Are there any commands or features that would allow me to condense or arrange the labels, or will I need to export my tree figures as SVGs and arrange the labels myself in another program? Any insight would be much appreciated!

Thank you!

[arklumpus]

Hi, I'm glad you're finding TreeViewer useful!

Would you be able to provide a screenshot (or the tree file)?

I'm not sure what the problem might be in this case, but are you sure that the labels are applied to the correct groups? You can also uncheck the Prevent overlap box within the settings for the Group labels module, which will cause all labels to be drawn on the same row.

Note that the actual amount of space required by each label is computed as the largest of the following quantities:

• The range covered by the tips of the group, increased/decreased by the Margin specified within the Layout options.
• The amount of space necessary to write the group name with the specified font, increased/decreased by the Margin specified within the Text options.

Therefore, it is sometimes possible for a label to require more space than it would seem, depending on the value for the margins (which can be set to a negative value if necessary), so you could try playing with those as well.

[sdenarie]

Hello arklumpus,

Both the specific names used for some of the group labels and the tree itself are not things that I want out in the wild just yet since both are based on a completely new data set, but I have posted below an example of one of the odd group label arrangements in case it might help at all with troubleshooting. Except for the small labels near the bottom (in which the text is retained), all of the higher labels have short group names relative to the width of their respective group label boxes.

[sdenarie]

Here is another example as well.

[arklumpus]

Thanks for the screenshots!

If I understand correctly, the issue here is that the group labels try to "fall down" to get as close to the tree as possible, while instead you would like them to "fly up" (e.g., in your second example, you would like Thy to be close to the other purple labels). Is this correct?

That was intended behaviour, but I have now pushed an update to the Group labels module that adds two new options: Gravity and Invert arrangement. These should help you achieve what you want (I think that changing the Gravity should solve your problem, but try experimenting with both options).

• With Gravity set to Bottom and Invert arrangement disabled (the default settings), the result will be the same as before.
• If you enable Invert arrangement, the order of the group label "rows" will be inverted (so that larger labels are closer to the tree rather than farther away).
• If you set the Gravity to Top, the labels will be moved as far away from the tree as possible (without creating any new rows).

Here are examples of the four possible combinations with rectangular and circular coordinates:

You should get an update notification at some point, but you can manually update the Group labels module by opening the Module repository (using the button in the Modules tab), selecting the updated module in the Plot action tab, and clicking Install.

I hope this solves the problem, let me know if you have any other issues or questions!

[sdenarie]

Hello arklumpus,

This update wonderfully resolves the issue that I was having with the gaps! I really appreciate you taking the time to institute a fix for that problem so quickly! The modularity of these settings provides some very nice and visually-pleasing options for displaying the labels, too, so that is appreciated as well. The examples you posted are also very helpful!

That said, one minor issue remains. Notice how in my second screenshot, there is an indigo bar (#383681) that is longer than the light blue bar just above it (#4E96BC)? The latter is naturally a less inclusive clade than the former, and I would like to sort the labels so that the labels for less inclusive clades fall below the labels for the more inclusive clades. The gravity toggle does fix the gaps, but does not reorder the labels in this way. Would a fix for this be possible, as well?

Thank you for your help so far!

[arklumpus]

Great, happy to help!

I think I managed to replicate the issue with those labels; the problem is that the text is too big to fit in the actual size of the group, and the label thus becomes a little big bigger (in your case, almost imperceptibly). This messes up the hierarchy, because now inner group labels are not 100% contained within the outer group label.

You could fix this by simply using a smaller font (or setting a negative value for the Margin within the text options), but I have just pushed another update to the Group labels that adds a new Overflow setting to the text options.

• The default is Expand label, which expands the label so that the text fits completely within it (this is the previous behaviour).
• If you set it to Clip, excess text will be hidden.
• If you set it to Compress text, the text will be compressed horizontally so that it fits within the label. This only works with Rectangular coordinates.

Here are some examples (these are with Gravity set to Bottom, but they should give you an idea).

So, try updating the module and changing the Overflow to Clip or Compress text!

[sdenarie]

Hello arklumpus,

Thank you for adding those additional options! That said, none of them really seem to influence the issue I'm trying to resolve.
I have posted a modified version of my second example below, with arrows indicating the important focal labels:

The two red arrows points to wide bars, one light blue above, and another indigo below, with the light blue label circumscribing a less inclusive clade and the indigo label circumscribing a more inclusive clade (I have included a black bar on the latter, showing the width of the text occupying the label, i.e., only a relatively small fraction). What I would like to do is to rearrange the group labels so that the label for the less inclusive clade is placed beneath the label for the more inclusive clade.

The blue arrows highlight a similar issue - I would like the "Het" and "Eupa" labels to go beneath the more inclusive "P-Idae" label rather than above it. I would like to be able to switch them around so that the "P-Idae" label is sitting next to the indigo label instead of the "Het" and "Eupa" labels. This would again be putting the less inclusive labels beneath the more inclusive.

Hopefully this clarifies a bit what else I am trying to achieve in my label sorting. Thank you again!

[arklumpus]

Hmm, I see what you mean... But have you tried using the Compress text option? The problem should be that Het is too long.

At least, when I tried to reproduce the issue, using Compress text or Clip fixes it:

• With Overflow set to Expand label (i.e., the default), it looks like your example:

• With Overflow set to Compress text it's fixed:

If this doesn't solve it in your case, there might be something else going on, but I would need the tree file in order to reproduce the problem... If you don't want to post it here, you can email me (giorgio.bianchini [at] bristol.ac.uk) - I promise I won't use it for nefarious purposes 😅

[sdenarie]

I did try both the "Compress Text" and "Clip" options, although neither had any perceivable effect. Notably, though, when I decreased the "Margin" field in the "Layout" section, that did swap the positions of the indigo and the light blue labels (the ones indicated by the red arrows in my previous example). However, even with this change, the "Het" and "Eupa" labels still sort above the "P-Idae" label. Using the "Compress Text" and "Clip" options in conjunction with this change seems to have no effect, nor does greatly reducing the font size of the labels. That said, something else must be going on. If there was some way that I could just send you the tree shape with the labels, I wouldn't mind doing that, if you know of a way to remove the other data from it.

[sdenarie]

As an update, it looks like when I remove the "PI" label, the "Het" and "Eupa" labels do sort underneath the "P-Idae" label. I'm not sure why that label is conflicting with the other two, though, since it is less inclusive and should sort under the others like at more deeply nested nodes (e.g., like how "PRA" sorts underneath "P-Ini"). Just adding this detail in case it helps at all.

[arklumpus]

I'll try to give it another go... Just to confirm, the issue still occurs if you have both Margins set to 0 and the Overflow to Compress text, right?

[sdenarie]

Yes, that's right. Changing "Margin" to 0 swaps the positions of "Indigo" and "Light Blue" in the desired manner regardless of whether "Overflow" is set to "Expand Label", "Clip", or "Compress Text", but none of these options have any effect on the relative positions of "P-Idae", "Het", "Eupa", and "PI". Changing the font size for all the groups labels and changing the text of the "P-Idae", "Het", "Eupa", and "PI" labels specifically to a single letter each also has no effect on their positions.

[sdenarie]

This problem does not seem to be specific to the tree I was working with before, as using labels for similar assemblages of taxa in different trees with certain areas of differing topology yielded the same results I was seeing before. That said, I did some testing with another tree that I labeled and found some interesting results. Here are some different setting combinations that I used:

Margin = 5, Overflow = Expand Label

Margin = 5, Overflow = Compressed Text

Margin = -20, Overflow = Expand Label

Margin = -20, Overflow = Compressed Text

Given that the "Margin = 5, Overflow = Expand Label" represents the default, it seems that changing "Overflow" to "Compress Text" results in no change. Likewise, from the default, changing "Margin" to "-20" causes other labels to display the unwanted behavior, with smaller group labels sorted above larger group labels. Only when I set "Margin" to "-20" and "Overflow" to "Compress Text" do I get the desired result, although at the expense of essentially unreadable small group labels. I have no idea why this is the case from a technical standpoint, but it could be that perhaps the program treats some labels as wider than they actually are regardless of the label text? Why this affects some labels and not others is unclear to me, though.

[arklumpus]

Thanks for the further examples!

Essentially, the issue happens because nesting is not explicitly considered within the multiple "sorting" steps that happen while arranging the labels.

The first problem is that the assumption is that if a label represents a group nested within another group, the inner group label will be fully contained within the outer group label. This is generally true, except when margins and relatively long labels interfere. The second problem is that with Gravity set to Top, labels will try to float up as far as possible, eventually floating above outer group labels if there is space.

I have pushed yet another update to the Group labels module, which provides options that will hopefully address the problem:

• There is a new None option for Gravity (this may or may not help in your case).
• A new Preserve nesting option, which actually considers the tree structure when arranging the labels. Hopefully this should solve your problem.
• A Manual label rows option, which can be used to manually specify the row for the labels.
  • This is useful if you cannot get what you want by using combinations of the other settings.
  • To use this option, enable the check box and then add a Number attribute with name LabelRow to the node whose label you wish to move (you can change the name of the attribute by clicking on the little wrench next to Label rows).
  • Row 1 is the closest to the tree (red in your case) and values increase going outwards. Row values smaller than 1 are ignored.
  • When this option is enabled, first of all the label rows are determined "normally", and then the manual override is applied. Therefore, moving a single label will not affect the position of other labels (even if they overlap or descend from the moved label).

Please give this a try and let me know what you think!

[sdenarie]

Thank you for the additional update! The "Preserve Nesting" option is exactly what I needed and produced just the result I had hoped for. The "Manual Label Rows" option is also a great addition, as I found it useful for sorting the labels for the more deeply nested nodes to close gaps or align labels for groups with similar ranks when using "Bottom" for the "Gravity" setting. I tried the "None" option for "Gravity" as well, but it didn't really seem to make any changes. Might be useful sometime, though!

All that said, I would like to thank you for being so expedient with your responses and for pushing out such helpful updates so quickly! You've been an enormous help, and I hope that the changes that you've made here will help other people who use this program in the future. I know that I certainly will be using it more often from now on myself!

As a final note, I think one more interesting addition that you could add sometime, inspired by your addition of the "Manual Label Rows" setting, would be some way to force the addition of new rows for the group labels. In combination with the "Distance" setting, I can imagine users potentially creating new rows to create broad gaps between labels so that they can use short distances to bring the deeply nested labels very close to the groups they circumscribe while keeping the more inclusive labels further away. This may help with visual clarity for certain figures. I've mocked up a quick example below:

Just another interesting idea!

[arklumpus]

Great, glad we solved it! I'm closing this issue for now, feel free to reopen it (or create a new one) if you still have problems.

You other idea is quite interesting, but I need to think a bit whether it would work best as another option for Group labels or for Highlights (or both)🤔