linebender / linebender/runebender

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

Open
#208 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
799
Forks
35
PR merge metrics
No merged PRs in 30d

Description

For context, see [this discussion about font source data structures and data storage](https://github.com/simoncozens/babelfont/issues/10).

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked discussion about font source data structures and storage, then review Runebender's existing source model and editor UI entry points. This proposal needs a design decision defining the variable-first data model, formula constraints, and compatibility with existing variable-font output before implementation scope or completion criteria can be established.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
design, desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.