Continuing a discussion from twitter
It is desirable to have a font format that can store all data needed for different tools and workflows.
Here are some goals and challenges:
- Human readable
- Extendable
- File structure
- Cloud services have problems with a lot files, so a single file might be better
- putting several files in a .zip defeats point 1
- Multi master support
- Global and master specific font info (features vs vertical metrics)
Comments
- Glyph
- Features
- Direction (RTL, LTR, …)
- Substitutions
- Substitute (input_glyph_list, output_glyph_list, before_context,
after_context, feature_list)
- Substitute (input_glyph_list, output_glyph_list, before_context,
after_context, feature_list)
...
- Positionings
- Mark (before_context, after_context, feature_list)
- Kern (before_context, after_context, feature_list)
...
- Type (Ligature, Component, Mark, …)
- Script (Arabic, Cyrillic, Latin, …)
- Groups (kern_gourp1, mark_group1, …)
- Final name (unixxxx)
- Carets
I think this is a great design philosophy for a storage format, and so what is needed is not a total rethink of a new format but added detail to the UFO spec. Let’s keep UFO but add what we need to it.
Per-glyph feature storage seems like a sensible idea, (especially in keeping with the version-control idea of letting different people work on different parts of the font simultaneously) but we would also need to ensure that this works alongside features which deal with classes or multiple glyphs. (Should the f_i ligature be shored with /f or /i? I think the answer is “neither”.)
If we're going to consider storing layout data at the glyph level, I suspect that will have to involve doing so in terms of specifying participation in lookups and groups. Frequently in complex script work, managing lookup order is important — which is why I still favour VOLT —, and a single glyph participates in the layout in multiple ways: as output from some GSUB, as input to other GSUB, as context in other GSUB or GPOS, as a base or as a mark in multiple and contextual GPOS, in sequential spacing adjustments. These roles are defined primarily in terms of how the glyph participates in lookups and groups, and only secondarily in how those lookups are mapped to features.
Input: array of string glyph names/one string of class name
Output: array of string glyph names/one string of class name
Before context: array of string glyph names/one string of class name
After context: array of string glyph names/one string of class name
Languages: array of string languages (human readable)
Features: array of string features (human readable)
Flags: array of strings (human readable)
aalt
,smcp
and so on – but the result is another glyph. Where would this glyph be stored? In an object "inside" the original glyph definition? But do note that definitions foronum
,pnum
,lnum
, andtnum
may refer to each other's glyphs in a sort of recursive way: you can transform lining digits to tabular and the other way around. That calls for a glyph independent definition.It gets more complicated with multi-glyph features. Storing all of
/fi
,/ffi
, and/fl
code under/f
sounds nice but if you add some special handling for an/i
glyph (say, to handle a Turkish dotless/i
) you need to hunt down all previous definitions using that/i
elsewhere."Human readable" does not mean that one must be able to write (or debug) this source document. There could be software for that! From a purely organizational point of view, for me the current (as in: binary storage) system makes most sense:
1. Glyph outlines are defined and associated with a fairly random name and/or number;
2. Those glyphs are indexed in one or more character maps, which maps each glyph to a codepoint that can be used on a computer;
3. OpenType features refer to the glyphs by their names.
On a more personal note: for me a
ttx
dump is perfectly readable. I can find whatever I want, and edit and add to it, then re-compile into a proper font again. Admittedly, a font editor is easier and less prone to random typo errors.And the XML in ttx files is considered human readable.
And about storing OpenType substitution on a glyph level: Isn’t that done like this in fontForge? At least it was the last time I looked at it a few years ago.
As mentioned, we use the file system for almost 25 years now and I expect it to be used at DTL for the next 25 years (FoundryMaster, the successor of FM, supports the 4-byte glyph databases). The format is public, BTW.
Encoding (library-wide)
Encoding (font-specific)
GSUB (library-wide)
GSUB (font-specfic)
GPOS (library-wide)
Metrics/meta (font-specific)
My colleagues and friends at URW reworked the AFDKO a bit, so during the generation of fonts the GSUB and GPOS are subsetted (OTM does this subsetting too). Hence, the ‘library-wide’ features files. Of course, in case of a font-specific layout, a font-specific features file can be used, as was the case for DTL Flamande, for example. Also the reworked AFDKO will accept any naming entry from the UFM file.