Style tags

Proof text in Hellbox can carry inline markup: mark a word bold, switch a phrase to a stylistic set, turn fractions on for one number. Tags work in typed content and in linked .txt files, so you can keep one marked-up proof document in your repo and every font you proof with it renders the styles in context.

Now <b>the bold carries the argument</b>, <i>the italic murmurs
beside it</i>, and <b><i>together they raise their voices</i></b>.

Fractions <frac>1/2</frac>, small caps <smcp>Reformer</smcp>,
and a stylistic set: <ss02>gargoyle ilk</ss02>.

Style tags

... sets the span in the family’s bold, ... in the italic, nested ... in the bold italic. Hellbox resolves which style that means from the fonts in the section, and you can override the mapping (see below).
... underlines.
Weight roles set the span in the family’s face nearest that weight: <thin>, <extralight>, <light>, <regular>, <medium>, <semibold>, <extrabold>, <black> (the OS/2 weight ladder; <bold> and <italic> are long forms of  and ). <light>Hamburgefonstiv</light> means “this family’s light” whatever family you proof, which is what makes a marked-up file reusable across a library. A family that can’t express the role renders the span at the nearest weight it has.
<f1>...</f1> sets the span in the section’s second font. Indexes follow the Fonts panel order counting from zero, and untagged text is the first font, so <f1> is the second, <f2> the third, and so on. These are also the tags Mix mode writes when you export a mixed distribution to a file.

OpenType feature spans

Any registered OpenType feature tag works as an element: <smcp>, <frac>, <liga>, <tnum>, <sups>, <ss01> through <ss20>, <cv01> through <cv99>, and the rest of the registry. The feature applies to the span on top of whatever features the section already has enabled.

If a font doesn’t have the feature, the span renders unstyled: the tag is still stripped, nothing breaks. That’s what makes a marked-up proof file portable across a whole library; each font shows what it has.

One honest caveat: fonts in the older AAT format (some system fonts like Hoefler Text) ignore OpenType feature settings entirely. Everything from the last decade of font editors is OpenType and works.

Axis spans

On a variable font, wrap a run in an axis tag to re-render it at different coordinates:

regular <wght@900>black</wght@900> regular
<wght@900,wdth@60>black condensed</wght@900,wdth@60>

The syntax is the four-character axis tag, @, and a value, with commas for multiple axes (= is reserved for feature values). Spans stack on top of the section font’s own axis settings and nest like every other tag; close with the matching </wght@900>. On a font without variation axes the tag quietly does nothing.

This pairs with the per-font axis controls: set a font’s overall coordinates in the Fonts panel, then push individual runs around with spans.

Exact glyphs by name

<glyphname>f_f_short</glyphname> inserts the exact named glyph, including unencoded glyphs you can’t type: ligature components, contextual alternates, stylistic-set glyphs. The glyph renders directly with no shaping, so calt and other contextual triggers never fire on it; that’s the point, you’re proofing the glyph in isolation.

This is the same markup Roberto Arista’s drawbot specimen builder uses, so existing proofing .txt files written for it work in Hellbox unchanged.

If the font has no glyph by that name, the name renders as literal text. Inside a styled span, the glyph comes from the resolved style when it has one, and falls back to the section’s base font when it doesn’t.

Unknown tags, and proofing code

Compact tag-shaped tokens Hellbox doesn’t recognize are consumed silently rather than rendered, so text written for future tags (or other tools’ tags) degrades to clean plain text instead of showing literal markup. That means <body> or <div> in a pasted code sample will disappear too, so when you’re proofing a coding font against real source code, flip the </> toggle under the content editor: parsing off means every character renders exactly as typed. That’s the right mode for code, since  and  are real HTML tags and have always parsed as styles.

Brackets that don’t look like tags still render literally with parsing on: anything with spaces (<see the appendix>), comparisons (a < b), and anything escaped (\<liga> renders a literal <liga>).

Tag styles mapping

With multiple fonts in a section, tag assignments live on the font list itself. Hover a font row and a chevron appears; it pops the tag styles for that font: Use for Bold / Italic / Bold Italic (plus any weight roles your text uses), with a checkmark showing where each tag currently resolves and “(Automatic)” when the heuristic picked it. Click to assign a tag to that font, click again to hand it back to Automatic; the popover stays open so the proof updates live behind it. When a tag lives on another font, the row says which one. The same chevrons appear on the Section mix rows in Automatic mix.

Each assigned tag also carries its own tracking field in the popover, in unit-less thousandths of an em like letter spacing. A bold that sets tighter than the regular, or an italic that needs air, gets its own fit wherever the tag applies: tag spans, Mix-mode words assigned that font, and grid cells.

Everywhere text goes

Markup works in typed section content, linked .txt files, every section type, and headless renders: the same tags style your proofs in CI and through the command line. A marked-up file linked to a section re-renders on every save, so the proof tracks your text editor keystroke for keystroke.

Vertical text currently strips tags without styling them (spans in vertical orientation are on the roadmap).