Font/Glyph editing

[Zentheon]

Graphite looks like such an interesting and very promising piece of software. I'm probably not the first to make the "Blender for 2D" comparison, but I say that affectionately (even the keybinds are easy to pick up coming from it).

Speaking of which, one of the areas in the creative space that lacks are genuinely solid OSS option is font/glyph editing. While maybe not something in the scope of Graphite itself, I for one would be curios in investigating such a thing, as the underlying vector editing foundations are by far the most involved part. Is such 3rd party extensibility in the pipeline at all (maybe via plugins or something of the sort)?

[Keavon]

We'd welcome code contributions as PRs. It is not out of scope (see our roadmap to get a feel for the scope).

[Zentheon]

Iiinteresting... I did notice there were a number of ambitious things on there earlier, so fair enough. I may peek around the code sometime to get an idea of it

[0HyperCube]

In terms of creating and editing paths, the cubic bézier editing is pretty robust. However there exist no option for quadratic bézier or spiro paths. Furthermore there is no way to forcefully snap to a grid (the grid overlay can be trivially ignored). Also features from fontforge such as constraining handles to horizontal/vertical, knife tool, separate background layer, guide lines (see #3644), etc. are not implemented.

I suppose that it would be desirable to have all the glyphs in a single node graph. Using a single node allows reuse of common letter forms across different glyphs and also allows all of the font creation process to be done in the glyphs. Unfortunately there are some serious performance limitations for graphs with many nodes e.g. #4572.

In terms of the node graph types, one approach would be:

• Each gyph consists of zero or more vector generators (e.g. path, rectangle) and some modifiers (e.g. path, stroke + solidify stroke)
• These are merged into a single Vector per glyph
• Nodes that mutate a Vector to set attributes (Tables and attributes for graphical data #1832) for glyph specific properties such as kerning, metrics, glyph name, unicode value or values (for ligatures), accent positions, etc.
• A stack of merge nodes feed a Vector[] into a top level font node (this is not possible currently since the merge node will only output Graphic[] per issue Constructing List<T> from T #4251 which was for some reason closed without resolution by @Keavon)
• A font node (similar to the artboard node) collects all the glyphs and produces a Font (new type).
• The font can be then be modified by other nodes e.g. to combine with other fonts or set font wide properties.

In terms of the editor interface, tools such as select, artboard, colour picker, fill, gradient, text should probably be hidden and the options for setting the fill and stroke colours should be removed from the tool options (the bar at the top of the viewport). When the Font output is rendered, it should probably show a grid with all the glyphs and the unicode character. The graph preview option could be used to edit a specific glyph only.

Note I have not designed a font so this is mostly speculation.

[Zentheon]

You're pretty much right on for the most part. I hadn't fully considered the implications of nodes, but that would open up avenues for pretty much all the advanced functionality other font editors need dedicated features for, and then some...

• Component instances? just create a reusable Vector[] node group
• Variability? Could likely simply be two separate font-specific nodes (or toggled modes of one) that pull in registered tags and then custom ones. Probably some neat tie-in to animation there
• Non destructive, mass-glyph operations could be very cool
• Mix-match aspects of multiple fonts in a single project
• Projects using use custom or edited characters in a font edit node, where it can then be plugged around where needed

And other stuff I'm probably forgetting (I had my thoughts arranged a little better before an accidental power off cleared my first attempt). The main thing I feel has some broader implications is something like color fonts. Unfortunately, the formats are kind of all over the place. Fortunately, COLR/CPAL is the main one that matters. Unfortunately, it's still kind of complex. There's V0, which goes as far as solid fills and some blend modes, and then V1 adds gradients and integrates deeper with variability.

CPAL in particular allows setting multiple palettes for consuming software to choose from (eg dark/light variants), and sharing swatches between palettes. I imagine palettes would be a great general node type, where color fonts could then derive. It definitely isn't needed for an initial feature set, but still worth leaving the door open for later down the line.

Some other stuff like multiple canvas outputs (opening glyphs open in their own tabs) and a way of referencing common bundles of nodes and variables seems on the agenda already from what I can tell. The idea of treating glyphs no more specially than custom nodes with some extra attributes probably works great, though I am curious how something like unicode selection/validation would then work. A raw text input might be a little too lenient, though maybe not as long as there's some mechanism for adding unicode ranges (known and custom), where individual codes wouldn't need to messed with anyway. "Ranges" could also probably be treated like just a group of glyph Vector[]s.

Kerning especially should have some sort of way to pick out codes that exist already. Not sure how deep Graphene's introspection ability goes, but that or a table of known codes the root font is aware of. Typically, editors arrange kerning into groups, so passing individual codes around as String[] independent of ranges for purposes like that makes sense. The full type for a "glyph node" kerning attribute might then look something like Array<Map<isize(offset), Array<String(unicode)>>>.

This is also mostly speculation, since I don't know much of Graphite's inner workings yet

[0HyperCube]

I hadn't fully considered the implications of nodes

The document being made of a single node graph is the unique aspect of graphite. It comes with some advantages and challenges. The user can add any arrangement of nodes that have compatible types and the tooling must try to work with that (although it is often not very successful currently).

Unfortunately, the formats are kind of all over the place.

There are a number of optional tables which I would suggest ignoring to make the implementation some what tractable.

I imagine palettes would be a great general node type

See #2349.

I am curious how something like unicode selection/validation would then work.

Currently the nodes have to just work with whatever content is passed in. However there is work for runtime error messages in the graph so users can see and debug issues with their graphs (infrastructure for this in the node execution is in #4556). This would allow the font node to reject invalid inputs. Ideally it could also point to the glyph that produced the invalid data if in part of a stack of merge nodes.

A raw text input might be a little too lenient, though maybe not as long as there's some mechanism for adding unicode ranges (known and custom), where individual codes wouldn't need to messed with anyway.

The properties for a node can define custom widgets such as sliders, dropdowns, curve editors, etc. You can do something better than a raw text input if required.

I would expect you could also have a dropdown in the editor tooling to bulk add glyphs for particular ranges (like fontforge).

some sort of way to pick out codes that exist already

I would think that custom enums would b benficial for usecases like #2222 or #2349. There hasn't really been any design work on this though.

Not sure how deep Graphene's introspection ability goes

I'm not really sure what you mean by this? For an introduction to the node graph implementation, see node-graph/README.md specifically the graphene section.