I’ve spent a lot of time describing presentation options for object headers and diagram nodes. I wrote about the sorts of things I would need, not didn’t actually list them.
Happily, despite the number of node and header styles I’ve shown, I actually don’t need that many.
Style Guidelines
I have a few guidelines in how object header and diagram node styles are applied.
- Every color of each scheme has a ‘friendly’ (unfilled) and ‘hostile’ (filled) option.
- Header and node for an object will use the same colors.
- All headers of an object type will use the same style.
- All nodes of an object type will use the same style.
- Header and node for an object need not both be friendly or both be hostile.
As specific style possibilities, I see
- All headers filled, all nodes filled.
- All headers filled, all nodes unfilled.
- All headers unfilled, all nodes filled.
- All headers unfilled, all nodes unfilled.
- All headers filled, all nodes filled except spell nodes. That is, spell headers are filled but spell nodes are unfilled.
How to Apply
In the taxonomy, identify
- Object color scheme (Character, Green, etc.). This will be used for both headers and nodes. Can (in fact, usually will be) inherited.
- Schema color index (A-E, from dark to light).
- Fill text color (black, white). This will be used for filled nodes.
Text color in unfilled nodes will usually be either black, or ‘color A’ of its color scheme. I expect this will be global. I lean toward black as the color, as long as the stat block content is black. It would look strange to me if the stat block is more visually prominent than the object name.
Specific Overrules General
Always, a specifically set value supersedes a more general value.
- Header printer friendly/hostile is a global setting.
- Node printer friendly/hostile is a global setting.
- I can define in taxonomy that ‘Spell’ nodes wills be printer friendly. This will apply to all spell nodes, even if the diagram node style is globally ‘filled’ (hostile).
- I can choose to have a a single object override the taxonomy settings.
Presentation Attributes
I expect to use the following metadata:
- color-scheme (named, probably set high in the taxonomy and unchanging after that).
- color-index (A-E… or A-G if I want to add black and white at A and G respectively).
- filled-text-color (black or white… or A or G).
- header-style (filled or unfilled; usually global and not set explicitly).
- node-style (filled or unfilled; usually global and not set explicitly).
- header-text-style (normal, italic, bold, bold italic)
- node-text-style (normal, italic, bold, bold italic)
- header-text-size
What these things mean when it comes to actually rendering content will be determined at build time. For instance, if I mark ‘Feat’ as (brown, E) my script will encode according to the rendering engine. Ditto for filled vs unfilled presentation, and so on.
Closing Comments
Overall I think this is not a complex system. even so, it’s good to think through how to implement before starting to encoded. I’m going to have to recode some of my existing taxonomy information, and reimplement a fair amount of XSLT. Overall it will mean less XSLT code than I have today because I remove a lot of special case code. Still, there’s significant change here.