An editor to work with a new paradigm for variable-first fonts

[alerque]

For context, see this discussion about font source data structures and data storage.

I've become increasingly frustrated with the current scenery in editors. On one hand I love where Runebender is headed because the FOSS world needs a better editor coded from the ground up in a sane language that can hold it's own against the big ($$$) players. FontForge is capable but archaic and I feel like trying to working on (or with) it is a loosing downhill slide. Especially on Linux, there is nothing else to turn to.

I also understand where it's at being a UFO editor and trying to play in an existing field. However I would like to at least float the idea that it could do a lot better by scoping out some new terrain. Instead of trying to compete with existing editor packages by playing exactly the same game, why not offer something truly unique?

The current industry standard variable font formats are quite capable and flexible from an end user perspective (perhaps even more so than most people have discovered) but I'm pretty sure the source formats and editor tooling is leaving a lot on the table. In particular I think the incremental approach of taking what were static fonts with and 2D space drawing primitives ((x,y) coordinate points, lines, curves, etc), assembling them into masters, then interpolating between them is backwards.

• Masters should not be a thing. Saving data like this is not a requirement to compile to existing VFF output formats, and it it holding back both creativity and function.

• Dynamic glyph shapes should me moved up a level, and the concept of masters dropped entirely. The concept of instances can stay (as defined by a location on all axis), but masters and interpolation could be dropped entirely.

• Glyph shapes should not be defined by static control points with static values, they should be defined by formula (or in programmer speak: functions). These formula would universally receive the axis position and be able to respond to them. Instead of having a 400 weight instance with a control point (40,40) and a 600 weight instance with a matching point at (40,65), you have a glyph with a control point formula (x=weight/10, y=weight/8-10). You can still generate the same static instances and even variable technology and be compatible with existing rendering technology, but you could revolutionize the editor interface by never saddling it with the idea of masters. How you present and allow the user to navigate the multi dimensional space would be the challenge of course.

  In order to remain compatible with existing VFF technology such formula would need to constrained to generating straight lines (since the output would still be dependent on interpolation). However this would immediately open up a world of static instance possibilities that is currently simply not possible by essentially allowing curved axis, stepped axis, etc. Secondarily an interface to design and store such multi-dimensional shapes would enable a technology playground for future VFF output formats that is currently almost unthinkable. The new source format and editor UI would be immediately useful for production work using existing output technology and be an incredible playground for future output possibilities.

[cmyr]

So this was one of the original design goals for Runebender, and we are very interested in exploring interpolation strategies that are not based on multiple masters.

There are lots of questions, and they can only really be answered by experimentation. Ideally, Runebender is moving to a position where it will be a good testbed for these sorts of ideas.

In the near-term, I would like to polish Runebender into a simple font editor with a good drawing experience, that is a reasonable choice for people who just want to draw a font. Once we get there, I will be very happy to lift my head a bit and consider more ambitious goals.

In any case, thank you for the issue, it's a very good expression of some ideas that raph and I have been discussing for a while.

[xorgy]

If there is a datastructure that would enable this (maybe variable transform matrices or metacurves per control point), then work on it could be of interest to the ongoing UFO4 effort, or a successor to that... though maybe at some point XML starts being a bottleneck, and humans can't really be expected to edit the outlines in a text editor anyhow, so the goals of good variable-first software would drift away from the goals of UFO.

[alerque]

c.f. manumit, a PoC from @simoncozens introduced in this Twitter thread (source repo).