[background] binary editing ideas, enabled by fast (rust) compiler/ttx

[davelab6]

@yanone posted at https://typo.social/@yanone/112729852038649593

1/ A font editor that works on sources and binaries simultaneously. It writes binaries natively through a fonttools-like adapter, and upon generating updates only tables or fragments which have been changed recently, such as glyf and gvar for outlines. The updating should happen transparently during editing, so that I can always preview the latest actual font in whichever environment I please during design time.

This absolves font editors from having to implement complex shaping in their UI.

2/ In version 2.0, complex shaping and editing becomes one and the same transparent process. When I click on a glyph in the Harfbuzz-shaped text, the editor overlays the outline editor widget, and moving points writes directly to the binary which reloads in the background.

The object model keeps a cache of binary representations of as many unchanged objects as possible to minimize the assembly time for binary edits.

When flagging the post to me, he also mentioned,

This would all be an excellent use case and show-off for the new Rust font compilers that are coming along. In addition to a fast compiler it would need a fast design-time-data to binary adapter like what ufo2ft does, and plugins for stuff like filters, because you need to basically put the entire production stack into the app, but I've been thinking of foundry profiles as plugins for a while anyway.

I keep having these ideas for editors because existing tools are such an incredible pain for my workflow.

@yanone did you post other ideas elsewhere? If you recall and can share a link, would be great

[justvanrossum]

Incremental compilation will be key here.

[yanone]

did you post other ideas elsewhere?

No.

Thank you for taking this seriously enough to create a discussion. At first it was just one of those random ideas that one has. I would love to see something like this happen. I tried to load a UFO in FontGoggles which doesn't lead to the intended results such as correct mark positioning, apart from the long compile time. I would really want to see the complete font being re-compiled on the fly as soon as a single point is moved.

You never edit all parts of a font at once. You work either on features, or on outlines, or on mark positions, etc, so depending on what you're currently doing, 99.9% of a font will not have to be re-compiled.

Anyway, I know that you guys understood the idea already. I'm just babbling.

Fontra is particularly well situated to enable this because of its communication protocol. A binary compiler as described above wouldn't have to be part of Fontra, but simply sit beside it and subscribe to all incoming changes and decide what to recompile.

I hope one can subscribe to all kinds of events in Fontra, also as part of the upcoming Python API. I already have other ideas that I would need this for, such as an external interface to organize my glyphs.

[driehuis]

Rust is cool, and Fast in general even Cooler. That said, the thing to avoid is tight coupling.

There's few things that irk me more than a UI sitting there, frozen, because I (or a random user before me) asked for the feature of regenerating the world in real time.

Trufont, for any font with a reasonable number of glyphs, will just sit there and wait while it generates the font overview page when you're done editing a glyph and return to the overview page. Fontlab, for the same font, will be sitting there with a "Not responding" annotation in the title bar whilst it is merely opening the UFO. In both cases, I'd be happier if it rendered the bits it knew (for example, the contents of fontinfo.plist with generic font outlines) before it bothered to render the individual glyphs. Bonus points for just caching the glyphs' bitmaps from last time. In both cases the root cause is tight coupling, where the app has to wait for all to be known before it can render the overview page.

Bringing this one up as a "careful what you wish for". It's cool if an app can use any spare cycle available to build final artifacts in real time. It's uncool if that causes the app to become less responsive.