-
Notifications
You must be signed in to change notification settings - Fork 3
Challenges
It seems that some published trees illustrate clades and phenotypic relationships that are not explicitly supported by the study. These might be “glosses” to aid reader understanding, nods to accepted clades and taxonomy.
The tree illustrator will push for additional rigor in these figures, which might be annoying for an author. But with the right approach to presentation, we should be able to bridge this divide by supporting glosses like:
- collapsing clades
- highlighting details and areas of interest
- (explicit) addition of “landmark” nodes?
Cecile Ane brought this up during the recent All-Hands meeting. The issue is that people will use this tool to make tailored figures, but this happens prior to paper submission. People may be disinclined to submit their data to a repository at that point, considering the paper itself may not come out for many months. So there must be some way to circumvent this problem. One idea kicked around was some flavour of embargo. (JWB)
This is something that we have been discussing in the Smith laboratory: plotting multiple trees on top of each other. One difficulty is when trees have different sampling. At the moment, R is the only go-to place to construct such a figure (and even then it is not straightforward). I think this would be a great feature. (JWB)
One approach is not to compete on features per se, but to offer the “path of least resistance” versus other tools:
- no installation or software “footprint”
- easy (single-click) update to a figure from changed data
- easy access to “house styles” of important journals
- easy re-purposing (embeddable web widgets, screen-ready graphics, etc)
- no need for cleanup in dedicated drawing apps
This approach might capture many first-timers who haven’t yet invested time in learning the hard way. Maybe someday people will complain about figures that have that predictable “Tree Illustrator” look, a la LaTeX. This means we’ve succeeded. (jimA)
@jimallman, September 22, 2014. This is based on experience so far in building the 'stylist' proof-of-concept. See the wishlist of final images for a sense of what we want to allow in the Tree Illustrator.
There’s a very tricky interplay of scale, transformation, and layout in SVG, and therefore in D3. If one is programming with a predetermined figure in mind, it’s not too hard to pin down one or two of these and let the others adjust.
In our case, we want to keep all of these as flexible as possible up to the “moment of truth” when the desired diagram is rendered. This is delicate business, because there are limitations on all sides:
- SVG elements scale easily, but this also scales line widths, font sizes, etc (Not Good)
- SVG paths cannot be easily “projected” mathematically, so must be generated at final size.
- Rendered trees should accommodate all labels and accompanying data (not push them "off-canvas”)
- Our tree(s) need to share a larger canvas with captions, legends, bitmaps, etc.
Given these restrictions, fitting a pre-determined final size means "working backward” from that canvas to the scalable elements:
- Adjust specified illustration size as needed for print/screen resolution.
- Of the total illustration size, how much is allocated for a tree-figure?
- Subtract any “tabular” data (traits, etc) alongside or surrounding the tree proper
- Subtract space for the widest visible label on any node or element.
- Apply any height/width constraints to the tree layout; adjust its dimensions accordingly.
- Render the tree layout within these constraints; add labels and accompanying data.
- Alert the user if there's just no way to fit the desired content in this layout.
The result should be a complete figure that looks precisely right at its final printed (or on-screen) size.