Future Global Font Format Requirements

Add links
From Meta, a Wikimedia project coordination wiki

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.

Better complex script support[edit]

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[edit]

Developer Technology Description Notes Links
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[edit]

  • Use a shaping markup syntax for authoring shaping logic that is formally defined and pleasant to type.
  • twitter discussion
Developer Technology Description
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[edit]

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.

Better compression[edit]

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.

  • 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.
  • Do family variation client-side. Relevant examples:
Developer Technology Description
Apple GX Variations gvar & fvar tables
Adobe Multiple Masters linear interpolation of two extrema
LettError MutatorMath
Don Knuth METAFONT
Fister Metapolator
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[edit]

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:

Better Classification[edit]

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)

Better UIs[edit]

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 font developers to author shaping logic graphically, similar to Microsoft's Volt

Bigger fonts[edit]

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)[edit]

Better Signing[edit]

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[edit]

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.

Better updates[edit]

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.

D.R.Y.[edit]

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.

Better rendering[edit]

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.

Better Specification[edit]

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.

References[edit]

Conferences[edit]

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Future_Global_Font_Format_Requirements&oldid=24893107"