Future Global Font Format Requirements
Wikimedia's global user community is the most diverse in the world, and the problems that exist with current font system implementations hurt these users. This page gathers suggestions for a future font technology that would benefit the Wikimedia audience by solving those problems.
- 1 Better complex script support
- 2 Better compression
- 3 Better Classification
- 4 Better UIs
- 5 Bigger fonts
- 6 Unencoded characters (Gaiji)
- 7 Better Signing
- 8 Better Security Model
- 9 Better updates
- 10 D.R.Y.
- 11 Better rendering
- 12 Better Specification
- 13 References
- 14 Conferences
Better complex script support
Users of complex scripts suffer clumsy or even broken shaping with OpenType. The history of the OpenType and AAT (GX) designs is discussed at length in http://typedrawers.com/discussion/1134/what-were-the-first-opentype-font-releases-and-when/
Better layout engine
- Allow for printing of very wide glyphs. http://typedrawers.com/discussion/1075/printing-very-wide-glyphs-in-indesign
- Use a shaping system that supports non-adjacent positioning (i.e. deeper data context &/or spatial detection) to produce a design that users love for such a script (eg Urdu Nastaleeq)
- Use a shaping system that supports cross-font kerning, for example so that a T from one font followed by an o from another font are kerned.
- Use a shaping system that supports variant typographic traditions and orthographies within the same language
- Use a 'bubble kern' method. See http://tosche.net/2015/09/bubblekern.html
- Use a shaping system that supports language-specific typesetting conventions (mentioned in SILE presentation at Granshan 2015.)
- Behdad Esfahbod's wishlist
- ACTION: Add examples of edge-case shaping that cannot be done today, quote the Tiro articles found in http://tiro.com/John/
|DecoType||ACE||Arabic layout engine||State of the art for 25 years||live demo|
|Apple||AAT (GX)||State-based layout engine||Fast but hard to program||TT Ref Man|
|SIL||Graphite||Cross-platform layout engine||High level x > y / a _ b type replacement rules, with attributes||homepage|
Better shaping description language
- Use a shaping markup syntax for authoring shaping logic that is formally defined and pleasant to type.
- twitter discussion
|Adobe||OpenType||Feature file .fea|
|Apple||AAT (GX)||mif, kif, jif & atif input formats|
|Microsoft||OpenType||VOLT project syntax / VOLT input syntax|
|Monotype||OpenType (and ?)||FontDame syntax|
|SIL||Graphite||shaping input syntax|
Better rich text markup
The way OT features are indicated in "rich text" mark up is not specified by the OT standard, and there were no public specifications until 2011 when CSSv3 introduced
font-feature-settings. This is less than ideal; for example, in order to set one character in an alternate glyph via OT features, the author must surround that character in a span element, and apply a super-long CSS property to that element, and this will segment the text run so that the isolated character stops interacting with the rest of the line's OT features (such as kerning.) This makes the reading experience bad.
Users suffer slow font loading or filled disks because app/web developers must send dozens of instances in a family over the wire or store them on disk, despite that the type designers create only a few masters.
- Introduce new contour primitives. Relevant examples: Glyphs 2's Smart Components, METAFONT/Metapolator's stroke primitives, Levien's Spiro splines, and Adobe's CJK stroke primitives (which David Lemon suggested may be open sourced as part of the Source/Noto CJK project at https://www.youtube.com/watch?v=DBz0rVUYNPA&feature=youtu.be&t=16m37s)
- Design the format for on-disk compression. Relevant examples: Google's WOFF 2. David Berlow has proposed a CFF-like "CTF" table for TT splines.
- Design the format for streaming. Relevant examples: Google's TachyFont https://github.com/googlei18n/TachyFont
- Do family variation client-side. Relevant examples:
|Apple||GX Variations||gvar & fvar tables|
|Adobe||Multiple Masters||linear interpolation of two extrema|
|Elseware||Infinifont (PANOSE2)||This should include the ability to define ways of generating scaled glyphs - small caps in Latin, or superscript/subscript, combining letters in IPA, mathematical glyphs, stacked superscripts - similar to https://github.com/loicsander/Robofont-scripts/tree/master/ScaleFast.|
GX Real World Examples
Adam Twardoch has prepared some GXified fonts. The GXified fonts have no kerning for all the masters, and no GPOS variations (for which there is currently no spec/format, so we'll have to invent something) will inflate the sizes But the indication is that that a GXified TTF becomes efficient when it replaces 2-3 standalone TTFs and 3-4 OTFs. With more than 4 fonts ("weights"), you'll nearly always be gaining (and of course you get the benefit of intermediate styles.) There are some additional potential compressions. The above includes 3 masters; the middle master is stored fully and then there are point movement deltas in both the lighter and the bolder direction. Families that don't have a middle master designed explicitly can be stored as one "main" master and one delta for even more efficiency.
- Adobe's Ex Ponto Pro is originally 3 OTFs totalling 665 KB (some 220 KB each) and a GXified TTF with no hinting is 643 KB, so no gain there.
- Impallari's Raleway is originally 7 TTFs totalling 1.6 MB (about 230 KB each) while as OTF it's less than half the size (about 60 KB each) and a GXified TTF is 190 KB (260 KB with hinting) http://recordit.co/ATkOh38lzZ
Other sample videos:
- Cinzel GX: http://recordit.co/58V3nhdqWE
- Playfair Display GX: http://recordit.co/5CCkDR9vPb
- Source Sans GX: http://recordit.co/mcSFSLv3rU
Users with large collections of fonts like to filter their collections to select fonts they are potentially interested in using for some particular text.
- Provide richer classification metadata inside font files
- Provide standard heuristics that font/text engines can apply to any collection of fonts to infer metadata from shape analysis
- Elseware's Infinifont (PANOSE2)
- Catherine Dixon's PhD Thesis
For Monospace fonts, OS/2.isFixedPitch has a very specific meaning (every single glyph in the font has the same width) so there should be a better way to indicate that a font is monospaced but does not have this requirement, maybe using one of the unused OS/2 fsSelection bits. (reference)
Users don't know about font features or understand how to use them.
- Provide a reference UI for users to review the typographic features in a font. This could be in a font utility app like OS X's Font Book, which already shows character set, text samples and information on language support, naming and foundry notices. It could equally be in the font panel which gets seen more than a utility app.
- Provide a reference UI for os/toolkit/application developers to enable users to activate features. Relevant examples: Adobe's recent efforts for OpenType and Peter Sikking's Interaction Architecture contributions to Libre Graphics applications
- Provide a reference UI for font developers to author shaping logic graphically, similar to Microsoft's Volt
Users are burdened when fonts that require more than 64k glyphs are split into sets of fonts. Users are also burdened with per-style files, instead of per-family files.
- Remove the glyph limit.
- Provide more documentation and tools for system developers, type designers and users to support and use the TTC composite font format from Adobe and Apple, that enables a virtual font to be created out of many component fonts, effectively removing the limit on the number of glyphs, and providing single per-family files.
Unencoded characters (Gaiji)
- Support rare and ancient characters found in Chinese, Japanese and Korean. This is the subject of a Wikimedia grant project https://meta.m.wikimedia.org/wiki/Grants:IEG/Solve_the_display_issue_on_rare_characters_in_CJK_fonts
As fonts contain more sophisticated logic (and perhaps as they are streamed) the ability to verify they have not been maliciously modified becomes more important. The OpenType format has a DSIG table for securely signing fonts to prove they have not been tampered with, but currently only a proprietary Microsoft tool (unmaintained since 2002) can sign them. Similar to the EFF "Let's Encrypt" project to make it possible for everyone to run secure websites, it is important that everyone can sign fonts to prove they have not been modified. fontTools issue #306 tracks this. http://www.w3.org/TR/SRI/ is also relevant.
Better Security Model
Users are burdened when fonts allow attackers to take over their computers. Fonts have been vectors for viruses and malware for a long time up to the present day, jailbreaking iPhones and enabling very severe system hacks - http://j00ru.vexillium.org/?p=2520 - so a new font format that throws out dangerous legacy technology would be good.
Users are burdened when fonts are updated but they do not receive notifications that the updates are available. It is common that applications auto-update, and users can set applications to update without requiring them to take any action, such that they are always up to date.
A new font format specification could provide a standard way to update fonts.
Users are burdened when the same font has different line layout in different applications/systems, because there are 3 vertical metrics in OpenType (in the OS/2 and HEAD tables) which are used differently by different systems.
A new font format should follow the Don't Repeat Yourself principle and avoid redundant data.
Control over gamma and similar values so that designers can tune their typography across devices towards similar colour; currently it is frustrating for designers that the 'same' font has very different apparent weight across devices.
Users suffer when implementations differ because the specification contains ambiguity.
A new format should have data in tables that are self-describing, so we don't have to write a custom parser for each, says Simon Cozens.