It works, as far as I’ve taken it. I haven’t started building out the ‘styled’ diagrams yet, nor the document style elements (chapter, section, etc.).
I have, however, separated taxonomy from presentation. I can still have presentation details in the taxonomy file, but I also can completely separate them. I also have made it possible to separate style elements instead of having them monolithic.
That is, I can give a particular taxonomy entry a named style:
tex:tcbstyle=egdBrown5H
This would be the equivalent of the ‘old’ feat style: dark brown frame, pale brown heading, etc.
I can also express it
tex:tcbcolor=egdBrown
tex:tcblevel=5
tex:tcbfh=H
These get concatenated to make the egdBrown5H
tcbstyle.
Now that I’ve worked with it, I find I like breaking it down. I don’t often need to specify all the attributes, just override one or two (usually the tcblevel).
Taxonomy Files
The taxonomy used to have the default presentation details. Now it’s a fair bit simpler, and has only classification and parsing information.

(lots more below this, elided)
In this case, that this specific type
- is not searchable (I have no ‘Alertness content’, but I do have ‘Alertness feat’) [not inheritable]
- Calculate ‘plural names’ for things by default [inheritable, can be turned off]
- Default template for building search strings
No more presentation information!
Style/Layout Files
These have much the same structure, but don’t need to include all the elements. Inheritance is a powerful thing.
Speaking of which, I tried an experiment. I created a ‘pf1-style’ file that contained some of what I wanted for presentation, but not everything.

(lots more below this, elided)
Sets my defaults:
- color to ‘red palette’
- level to 1 (highest level, I use this mostly for things like classes)
- ‘printer hostile’ mode (filled headers)
I then created a ‘pf1-layout’ file that imports pf1-style and fills in a lot more detail.

(lots more below this, elided)
Here I override the color palette and the font I want to use for the object headers. I also define what I want to see in the level marker on objects… by default. I’m preparing for some other things that aren’t yet implemented in code.
And it all works. All through my pf1-layout I set presentation information and it’s applied correctly.
To make a printer-friendly version, I change just the ‘tex:tcbfh=h’ line to ‘tex:tcbfh=f’ and recompile the PDF. This won’t change things under the Spell taxonomy, though, because I’ve explicitly set spells to use a solid header.
Presentation Styles
For those curious, here are the style palettes I’m using right now. I will likely extend the list as I go.




Next Steps
I’ve had some great progress here, but I’m not done yet!
- Add support for styled document elements (chapter, section, tables, etc.)
- Add support for ‘inline’ presentation, which is often used for things like class features in the source documents.
- Use the layout specs to inform node appearance in dependency diagrams… the reason I started rebuilding this whole mess.
- Add support for coloring tables. Right now it’s hard set for the document, but I feel tables can benefit from inheriting colors from containing objects. Right now the default is brown trim throughout the document. ‘Magic’ is purple palette. Tables within a spell description look more harmonized if they have purple trim instead of brown.
- Expand the layout from just colors and node styles to content selection. These are the bits I said were extra and not yet implemented, above. This can replace the RAF/WIF/Final logic I have in XSLT today, and make it much more extensible.
- meta:statblock elements show what bits to include in the statblock, and in what order.
- meta:body elements show what bits to include in the content of the element, and in what order.
- I can probably extend the layout file settings to define the domains.
Because of the inheritance, I believe I can set up layout files for my domains, content, and presentation… and then some very simple wrappers that make it easy to create layout files for the various combinations of output.
Closing Comments
I’ve still got a way to go, but I have implemented the trickiest part. I see how to do the rest.
It works! IT WORKS!