XML Workflow: Yet More Refactoring

Almost all the code discussion under ‘XML Workflow’ are about XSLT, the XML transformations. LaTeX is a very important transformation step, the last one before going to PDF.

Most of this code was written about ten years ago, with only small changes made over time. I know much more about LaTeX and major libraries I use in LaTeX than when I started. I’m sure the LaTeX code — about 3,000 lines of it — can be cleaned up and simplified.

Document Classes

When I first started, I had only one document class. Over time I’ve adjusted how it works, but I still have supported only one class at a time.

Standard Two-Column is the most commonly used. I really want to explore other layouts, in particular one based on the work of Edward Tufte. Different subjects can work better with different layouts, and I want to have multiple layouts available.

I still want all document classes to support the same content. That is, I want to be able to switch between the standard two-column and Tufte-based layouts freely and have the documents still build reasonably.

Colors

I want to keep consistent palettes, so I’m defining them in a common style file. I am likely to write these to an XML file and generate the LaTeX file from this file. This source file will make it easier for me to use the same palette in GraphViz (DOT) files.

TColorBox

I use the LaTeX tcolorbox package for domain object headers, and for document section headers. However, I haven’t done so in a consistent manner, partly because of how the section headers are implemented. In the current code, section header appearance is basically hard coded.

I will redesign so section headers and object headers work the same way in code. They serve different purposes in the document structure, but fundamentally the layout engine is the same.

To whit:

  • Object headings are just tcolorbox calls and I can set everything I want up, directly.
  • Section headings look like they use the regular \chapter, \section, etc. macros, and then tcolorbox internally. The way the titlesec package uses tcolorbox macros, can’t easily be customized like object headings.

Because I want to use styles interchangeably, I need them to accept code the same way.

Thankfully, that should be straightforward.

  • Define a command that has the tcolorbox settings to put in the tcolorbox optional parameters.
  • Define a box to hold any stat block content. If this box is not empty, put it in the ‘lower’ section of the tcolorbox.
  • Build tcolorbox object, using the defined command and box as needed. This will get the object presented on the screen.
  • Clear the command and box (shouldn’t be needed because anything else using them should set them up again).

Thus, when adding a domain object to the document, I can have

\egdSetTcbParams{egdBrown3H,level=3} % probably should at least have style
\egdSetTcbLower{statblock goes here} % may be empty
\egdStatblock{Object Name}

Today it would be just

\begin{statblock}[egdBrown3,level=3]{Object Name}
statblock goes here
\end{statblock}

The latter is the more common way to do things in LaTeX… but I can live with the difference, especially since it’s machine-written.

Similarly, for section headings, I can do

\egdSetTcbParams{egdBrown3H,level=3} % probably should at least have style
\egdSetTcbLower{statblock goes here} % may be empty
\chapter{Object Name}

I don’t see a ready way to pass in other parameters to the chapter macro. I have to set them as pseudo-global variables.

It’ll do.

TikZ Diagrams

When I first set up macros for use building dependency diagrams, I had not yet built out my taxonomy. Everything was style-driven in the documents (d20 Feat, d20 Rogue Talent, etc… hundreds of the bloody things). This followed into the LaTeX code, with \featnode, \featurenode, \racenode, and similar macros.

This did well enough for the time. It doesn’t work for me anymore because now I need to change more settings. I don’t want to maintain two sets of macros based on small configuration differences.

Instead, I’m going to take a step back. I will have a single node type for the diagrams, and apply the styles to them as needed. That way, if I want printer-friendly or printer-hostile diagrams, I change one setting at a high level and I’m done.

Tables

It comes to me that I haven’t talked much about tables in this series of posts. I’ve set it up so I’ve got a few styles based on different LaTeX tables. I mostly use tabulary, but sometimes use tabularx or even basic tabular. They tend to have the same tcolorbox wrappers.

I’ll want to do something about that, but I don’t yet know what. I’ll have to come back to this one.

Closing Comments

There are almost 3,000 lines of LaTeX document class and style files. I’ve covered the high points, but I’m sure there other things I’ll want to factor out. I imagine a fair bit of those 3,000 lines are sitting unused. It was written starting more than ten years ago, and I’ve changed how things work.

I’m going to go through the rest and touch that up as I go. Right now I’m working (a least!) a little bit against what was ‘designed’ when I started. I know so much more now that I’m sure I can do better today.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to Top