Hellbox: live font proofing for Mac

jakeflem · July 13

Hi all. I make Hellbox, a native Mac app for proofing fonts while you draw them.

Some of you may recognize it. It launched in June as Font Proof, a name that sat too close to Font Proofer, so it's now Hellbox. A hellbox was the bin in a print shop where broken type waited to be melted down and recast. Kind of a weird name, but for an app whose job is finding busted glyphs, I think it works! And I am no stranger to weirdly named tools... (see idiotproofed.com)

Just like Idiotproofed, the idea is one idea: the proof keeps up with you. Hellbox watches your Glyphs file, and when you save, the open proof updates. It does the same with RoboFont and FontLab (in beta), no plugin required. Everything renders as a live PDF through CoreText, the Mac's native text engine, so what you proof is what your users get.

In the box: waterfalls, glyph sets, compare styles, columns and rows with per-cell control you can combine into complex layouts, mixed fonts and styles in the same proof, linked text files, markup on frozen proofs, proof templates and section templates, 70+ OpenType feature toggles. Pay once ($100, 14-day trial), no subscription. macOS 14+ (12 and 13 in beta).

More at hellbox.com, and the longer story is on the blog: From Idiotproofed to Hellbox

Release notes are on the site if you want a sense of how fast updates ship. If something's missing or broken, tell me and I'll fix it.

James Puckett · July 14

This is cool as, well, you know!

jakeflem · July 14

James Puckett said:

This is cool as, well, you know!

Thanks, James!

Chris Lozos · July 15

is there a way to add our on text to this? I have several runs of text that I prefer to use and are part of my workflow for many years.

jakeflem · July 15

Yes! You can add any text you like. You can link text files, save section templates, save proof document templates. Since we all have our particular workflows, the goal of the app is to allow reusability of as much of that process as possible.

Chris Lozos · July 15

Thanks!

Chris Lozos · July 15

Can I format in columns?

jakeflem · July 15

Yep! There’s a “columns and rows” section type. There’s also a “compare styles” section type that allows either a columns or rows comparison of styles.

This is a complex layout created in the tool with the “columns and rows” section type:

Image: https://us.v-cdn.net/5019405/uploads/editor/y1/bygkv1p98833.png

You can also do less complicated layouts:

Image: https://us.v-cdn.net/5019405/uploads/editor/zv/v8fqgtoc7mwd.png

Please let me know if you have any issues or more specific requests as you dig into the trial. You can email me at jake@hellbox.com

Chris Lozos · July 15

Looks good so far

Xiaoyuan · July 16

Hi Jake,

Somehow I feel the idiotproofed sounds like a better name than hellbox...

I'm wondering if you would make a video showcasing the main features? I think it would be so good to have a look, especially for people like me—downloaded it, tried it for a few minutes then got caught up by work and forgot about it and then 15 days gone, the trial has ended! and I don't know what's the main features... I would really like to see a demo video.

not gonna lie, the main thing intrigues me is the auto updating pdf and ... one time payment.

jakeflem · July 16

Hi Xiaoyuan. Thanks for the feedback. I'm working on a video tutorial. Hopefully will go live soon. I like the name Idiotproofed as well, but it's a separate project.

jakeflem · July 24

Thanks @Chris Lozos!

Thomas Phinney · July 25

I expect this is totally obvious to a significant chunk of the readers here, but probably equally NOT obvious at all for many....

“Hell” is German for “light,” and a “light box” is of course an old pre-digital proofing device for overlaying and comparing paper proofs. So “Hellbox” ≈ “Light Box.”

Chris Lozos · July 25

And "Hellbox" is a very long-time name in metal type setting for the bin that bad lead type was thrown in and ready to be melted down and reused to cast type. And yes, @Thomas, I (in the 1960s) cut my Graphic Design teeth on a light box, which we used to create mechanicals (Camera-ready art) for offset printing. ;-P

Kris Sowersby · July 27

Mate this is really good!

Is there any way to incorporate user-defined inline styles for proofs? A way to mark up the .txt files to mix in OpenType features and bold/italic styles?

jakeflem · July 28

@Kris Sowersby Thank you! I’m glad you think so. There is a way. I've kept it hidden until now, but have been working on making the system more robust and extensible and it's officially out in today's 1.24.0 update (Hellbox → Check for Updates, or hellbox.com). It's pretty simple though! I've attached an image of what you can get, plus the exact text file that produces it (all the way at the bottom of the post).

Image: https://us.v-cdn.net/5019405/uploads/editor/fz/uq454oe8rmxw.png

It's a tag system that works in typed section content and in linked .txt files, so you can keep one marked-up proof doc in a repo and every font you load renders it in context. Wrap any string in:

 and , which resolve to the family's actual bold/italic (remappable per section if the family's naming confuses the guess)
<thin> <light> <medium> <semibold> <extrabold> <black>, the OS/2 weight ladder, resolved to the nearest weight of whatever family you're proofing
any registered OpenType feature tag as an element: <smcp>, <frac>, <tnum>, <ss01>...<ss20>, <cv01> and so on, layered on top of the section's feature settings

If a font doesn't have the feature or the weight, the span just renders unstyled, which is what keeps one file portable across a whole library. Code samples are safe too: only real feature tags parse, so <body> or  in an HTML specimen renders as text, and \<liga> escapes a literal tag. Same tags work headlessly, so your CI proofs pick them up from the repo.

Docs with the full grammar: https://hellbox.com/docs/style-tags

Let me know how this does or doesn't fit your needs!

Kris Sowersby · July 28

@jakeflem

🤯🤯🤯

This is exactly what I am after! You mad genius, thank you so much 🙏

I actually have a bunch of proofing .txt files with this exact otf markup from an old drawbot PDF specimen builder Roberto Arista made for us aaaaaaaages ago. So it's basically ready to roll!

We did run into a very specific issue of inserting calt glyphs and other non-unicode glyphs that needed to be proofed without the contextual triggers, like f_short etc. Our solution was:

<glyphname>f_f_short</glyphname>

as a string in the txt file.

Is this something worthwhile, you reckon?

Again, thank you so very much for this.

jakeflem · July 29

@Kris Sowersby hell yeah! Worthwhile enough that it's already shipped. <glyphname>f_f_short</glyphname> works in 1.25.0 (Check for Updates).

Behavior: the named glyph renders directly with no shaping, so calt and friends never fire on it, which I take it is the whole point. Works for anything the font has a name for: ligature components, contextual alternates, stylistic-set glyphs. If a font has no glyph by that name, the name just renders as literal text. It also composes with the other tags, so <glyphname>g.2</glyphname> shows the alternate in the bold.

Docs: https://hellbox.com/docs/style-tags

Your post is my only spec for Roberto's format, so if those old .txt files do anything else, send one over. I'll consider matching whatever makes sense.

Happy to go back and forth on this thread, but you can also email me at jake@hellbox.com or message me on fufo discord. Whatever works.

Kris Sowersby · July 29

@jakeflem Discord friend request sent ✌️

yanone · July 30

Hi Jake. Very nice tool.
Since you’re relying on source files, how far does your support of OpenType features go? Mark positioning and bidirectional text?
Do you parse the source files and render from them directly, or do you compile to a TTF internally and have CoreText shape it? Cheers.

jakeflem · July 30

Hi @yanone, thanks. It compiles internally. UFO and designspace sources go through a bundled fontc into a real binary font, Glyphs files come in through the running Glyphs app the same way, and CoreText shapes from that binary. So OpenType support is whatever the compiled font has, shaped to CoreText's level: mark and mkmk positioning, bidi, contextual alternates, etc. Hellbox proofs RTL and vertical CJK through the same path. The reasoning for compiling rather than interpreting sources is that the proof behaves like the font you'd actually ship, same toolchain lineage and all. Rendering is CoreText too, though I just added an optional FreeType view for checking hinting, since CoreText never executes hint programs.

yanone · July 30

Top-level engineering, especially the Glyphs part was a surprise.

Full disclosure: I’m developing a new font editor (still alpha stage) and I was wondering whether it would be compatible with Hellbox.

It’s not really. Counterpunch also compiles with fontc, but a 100% identical result is not guaranteed, especially for Glyphs sources, because I build on babelfont-rs which ingests all source format types and then forwards them to fontc via babelfont’s internal fontir converter. But the same is true for your UFO approach. Locking in one certain compiler for Hellbox while a user may ultimately compile their binaries with another compiler opens the floodgates for ambiguity.

Few suggestions: Allow binary font intake. Font export from my app is swift (because fontc), and binary intake decouples Hellbox from any particular production pipeline.

Then allow variable settings. Not only will the community ask for that at some point real soon, but it also solves your problematic weight setup. Not all weight are always named in the “canonical” naming scheme you implemented as tags, and it would also solve the overriding of your and tags with arbitrary values.

Finally, consider implementing at least a line height setting. While I think more advanced settings such as letter spacing or word spacing are not that interesting to type designers (until someone requests that), some fonts are specifically designed for certain line heights (think diacritic collisions) and therefore need to be proofed like that.

The problem is, the more settings you implement, the closer you get to existing markup languages such as latex, Indesign markup, and especially HTML+CSS, which already contains all necessary features

jakeflem · July 30

Thanks @yanone. Counterpunch looks great! Hellbox already takes binaries. Drag any OTF/TTF in, or point a watched folder at wherever your exports land and the proof live-reloads on every export. The source intake is just there so people can save-to-proof without exporting. Agreed on compiler lock-in, that's why the binary path is the ground truth. There's also a headless CLI for rendering proofs from binaries in CI, docs at hellbox.com/docs/ci

Variable settings exist too. You can add a variable font more than once and dial each copy to whatever axis values, or pick designspace instances. Line height, letter spacing, and paragraph spacing are all per section in the typography panel. The b and i tags map to any font in the proof so they aren't stuck with canonical style names, though I could make that flow smoother.

Agreed on the markup creep. Proofing needs a pretty small set of controls and everything past that is a page layout app

Also had a peek at your repo, you're already persisting a file handle for binary export. So if someone points that at a Hellbox watched folder, every export re-renders the proof automatically. Live proofing for Counterpunch with zero work on either side.

yanone · July 30

Your https://hellbox.com/docs/style-tags/ page doesn't list tags for variable settings. Is this only possible in the app directly? I'm asking because there's an opportunity to copy/paste formatted text from font editors into Hellbox directly if the full syntax is known.

jakeflem · July 30

@yanone There's no inline tag for axis values today. Tags cover style spans, font indexes like <f1>, feature spans, and exact glyphs by name. Variable settings live on the fonts themselves. Each font entry in a section carries its own axis coordinates, so the workaround is to add the same font at different settings and reach it with <f1>. The weight roles like <light> and <semibold> also resolve against a variable font's weight axis, which covers the common case.

An inline axis span is a natural extension though, something like <wght=550> stacking on the section's coordinates. If you're serializing formatted text out of Counterpunch, tell me what you'd want to emit and I'll consider matching it.

yanone · July 31

Counterpunch currently doesn't support formatted text. In its current stage, its editor is single-line and axis and OpenType feature settings are applied for the entire text run at once. It does support explicit glyph names akin to your <glyphname>, as does Glyphs.app.

But extending its editor to formatted multi-line text is on the roadmap, and I'm looking for an exchange format for it. There is an opportunity to establish a comprehensive and simple open (!) markup standard for font proofs, and font editor users would be able to copy/past tagged text back and forth between Hellbox and Counterpunch, among others.

Since you're authoring this currently, I think the process should be the other way around, so here's a proposal: You think the tagging through from scratch and define inline tagging for all use cases important to type designers including line height without scope creeping towards CSS to much. Axis tags should support multiple values à la <wght=550,wdth=75>. Nested single tags would of course also work. I would define that spelled-out <extrabold> tags map to actual fvar instances or STAT table entries on the wght axis (in that order of priority) rather than assuming wght values for predefined weight names. Even though there are norms for them, there is no guarantee a font uses the normal names. Counterpunch as a variable font editor would always export <wght=700> axis tags instead of literal weight names. The weight name tags make sense to me for proofing static fonts.

If you publish this tagging standard under an appropriate open license, font editors both libre and commercial would be able to support the format. You would also have to accept that other libre proofing apps could arise.

Also make sure that Hellbox ignores unknown tags from now on, so that users of older Hellbox versions don't see literal <futuretag>s in their proofs. Columns and page layout would be exclusive to Hellbox; I'm not going to implement that, only formatted text maybe within a certain column width.

Wdyt?

Florian Pircher · July 31

For a common exchange format, I would suggest reserving the equal sign for layout features like calt=1 and cv01=3 and at signs for axis locations like wght@350 or slnt@-11.

Dave Crossland · July 31

I suggest the fonttools instancer syntax

https://fonttools.readthedocs.io/en/latest/varLib/instancer.html

Simon Cozens · August 1

Just use a CSS style tag. Lots of smart people put much work and thought into both HTML/CSS specification and tooling, and it's all there for the taking. Reinventing pseudo-HTML gives you a document format for precisely one application (I mean "application" in the sense of usage, not in the sense of app); using the existing standard gives you free interoperability.

jakeflem · August 1

@Simon Cozens yeah, and I don't want to invent meanings CSS already defines. The tags exist because I want people to be able to type them by hand in .txt files or the app directly with as little friction as possible, so terseness matters a lot to me. There may be a middle path but I haven't had a chance to think it through yet completely.

@yanone @Florian Pircher @Dave Crossland good input all around. I'm going to sit with this before committing to anything!

Hellbox: live font proofing for Mac

Comments

Categories