Hellbox: live font proofing for Mac

2»

Comments

  • This is cool! I too am building a font editor, Shift, and have had this persistent idea in my head of what it would be like to be able to do proofing inside the editor itself, instead of having to export into different apps.

    My initial thoughts was more an infinite canvas experience like figma or tldraw, where you have something akin to text boxes that you could apply different designspace locations, sizes, layouts and move around. This would obviate the need for tabs and you could see and edit the font in all its different design contexts in one place.

    I first thought I could do a similar thing to Counterpunch and incrementally compile the font on the fly and render that with the FontFace api (because this is an Electron app), and then you get all the html/css layout and semantics for free, and that fidelity (this is what your font will look like when compiled), but I didn't go down that route.

    I'm not a type designer so I am not sure how useful this type of editing experience would be, or whether just having single/multiline fixed text, like Glyphs in different tabs is fine for most.
     
    I work for tldraw so am infinite canvas pilled, but having everything in one space seems like a good experience and am keen to explore this type of interaction in the font editor space. 
  • jakeflem
    jakeflem Posts: 19

    Shipped the pieces of this that felt right regardless of where any spec lands, in 1.36:

    • Inline axis spans: <wght@550> or <wght@550,wdth@75>, stacking on the section font's own axis settings. Went with @ for axis locations and reserved = for feature values, per @Florian Pircher.
    • Unknown tag-shaped tokens are now consumed silently instead of rendering literally, so text using future tags degrades to plain text in old versions from here on. @yanone (For proofing text that should render its brackets verbatim, code samples and the like, tag parsing is a per-section toggle, and \< escapes a single tag.)
    • <extrabold> and the other weight roles now resolve to the font's own fvar named instance first, wherever the designer put it, before falling back to name matching. STAT lookup is next.

    @Dave Crossland I went back and forth on instancer syntax since it's what the Python tooling already speaks, but the location-vs-selection distinction won out for a format that also has to carry feature values. The forward-compat rule means <wght=550> degrades cleanly today, so accepting instancer-style as input later is a small, non-breaking addition if that's where tools land.

    @Roel Nieskens on CSS spans: for me it's about signal-to-noise. Proof text gets read a lot more than it gets written, in the editor, in .txt files, in diffs when proofs live in a repo, and <smcp>hello</smcp> keeps the text legible in a way <span style="font-feature-settings: 'smcp'">hello</span> doesn't, regardless of whether a person or a tool wrote it. Both syntaxes need custom extensions at the edges anyway (there's no inline CSS for a glyph by name). Where CSS fits well is interchange: accepting font-feature-settings, font-variant, and font-variation-settings on pasted spans maps mechanically onto the tags, so formatted text from other tools could just work while the terse forms stay the native syntax. I dug into the Wakamai Fondue engine tables and they're exactly the right mapping for that, so I may take you up on the help.

    Still sitting with the bigger spec question rather than committing to anything yet. 🙇‍♂️

  • jakeflem
    jakeflem Posts: 19
    @kostyafarber My take after building both a web proofer (idiotproofed) and this... canvas and pages solve different problems. An infinite canvas is a pretty great editing surface, but a proof's constraints are kind of the point in most cases. That's why Hellbox is quite unapologetically paged. The good news for an editor like Shift is you don't have to build proofing at all if you don't want to. Hellbox watches a folder, so if Shift can export a binary on save, your users get live-updating PDF proofs next to the canvas with zero integration work.
  • yanone
    yanone Posts: 144
    Awesome
  • Jack Jennings
    Jack Jennings Posts: 152
    edited August 12
    I own the `hellbox` package on PyPI. I'll be looking for a new project name given your announcement; if there's anything that you can think of to do with a python package related to your project, I'm happy to transfer ownership to you. (Looks like you have a CLI, maybe you want to wrap that in a python package as well?)
  • jakeflem
    jakeflem Posts: 19
    @Jack Jennings That's very generous, thank you! I'll take you up on it. it would be great to have a pip-installable wrapper around the headless CLI so proofs can run in CI with nothing but pip install hellbox. I'll DM you.
  • Miles Newlyn
    Miles Newlyn Posts: 280
    @jakeflem I'm liking this very much. 
  • jakeflem
    jakeflem Posts: 19
    @Miles Newlyn That's what I like to hear!
  • jakeflem
    jakeflem Posts: 19

    A few things have landed in Hellbox over the last two weeks:
    1. Proof only what's marked done. Hellbox reads mark colors from your UFO, designspace, or Glyphs file (RoboFont mark colors, Glyphs color labels) and shows them as swatches in the section controls. Pick one or more and the generated text and "All drawn glyphs" narrow to those glyphs. A "no mark" swatch shows you what you haven't flagged yet.
    2. RoboFont round trip. Cmd+click a glyph rendered from a .ufo or .designspace source and it opens in RoboFont's edit window. Select text and hit Return to land it in a Space Center with /glyphnames intact. If RoboFont is closed, Hellbox launches it and opens the UFO. The Glyphs round trip has worked this way for a while; now both editors do.
    3. Axis spans. On a variable font, wrap a run in <wght@900> or <wght@900,wdth@60> to render it at those coordinates. Nests like any other tag. Weight roles like <extrabold> resolve to the font's own named instances first, then the STAT table, so work-in-progress variable fonts land on the designer's own ExtraBold.
    4. CI with just the .glyphs file. Headless renders compile .glyphs and .glyphspackage sources with the bundled fontc, so a repo with the source and the .fontproof renders on any runner.
    5. Plus fixes: underlines are drawn from the font's post-table metrics so they're consistent at every size, zero-width glyphs get their own room in Glyph Set grids, <b> on a single variable font uses its Bold instance, and hidden fonts stay hidden through live reload. Font-resolution checks gate every release.
    Full notes: hellbox.com/changelog