Complex Text on Simple Devices
Pedro Navarro Sr. Software Engineer / Streaming Client Technologies 1
Background 2 Gibbon ● Codename for our JavaScriptCore-based application framework. It provides objects to create UI elements, access the device and perform video playback.
● Written in portable C++ targeted to the lowest common denominator
● Runs in Consumer Electronic devices (TVs, Blu-Ray players, Roku devices), Android TV and Game Consoles (from the Wii to the PS4 Pro) Netflix UI Powered by Gibbon since 2013 3 Constraints ● We are targeting devices with very low capabilities (128mb total RAM) and, in many cases, with a Read Only file system.
● We don’t control the host we are running on, so we have to be ready to work with old compilers and different versions, and combinations, of all third party libraries we use
● Very long release cycles: except for game consoles it takes 12 months from the time we provide our SDK until there are devices in the market with it.
● No upgrades! We are part of the device’s firmware. OLD DEVICE Luckily, we didn’t have to ● Small footprint. Our binaries and fonts have to be as small as support this one. possible, as flash storage is scarce
● Different graphics platforms. We need to run on DirectFB, OpenGL and Game Console graphics APIs. 4 2013’s Text Engine ● Our first iteration of Gibbon’s Text Layout Engine was very simple and provided just 1:1 mapping between characters in a text string and glyph indices in a font.
● The character set was WGL-4, which we extended later to add additional Latin glyphs.
● Support for CJK was added by introducing fall fallbacks.
2013 Supported Writing Systems ■ Latin (425 languages) ■ Cyrillic (106 languages) ■ Greek (1 language) ■ Chinese (5 languages) ■ Japanese (1 language) ■ Hangul (1 language) 5 Global Launch ● For the global launch we had to be ready well in advance because of the long release times.
● We defined our own Character Set (NGL-2), to standardize our fonts and our content.
● Supporting Complex Scripts meant that we had to integrate text shaping and BiDi processing.
● Research showed that the vast majority of devices we needed to support, besides game consoles, would be low performance set-top boxes. Global launch candidates: Indic writing systems: ■ Arabic (38 languages) ■ Bengali (5 languages) ● It’s important for us to get pixel fidelity between ■ Hebrew (9 languages) ■ Devanagari (19 languages) platforms, so the UI doesn’t have to account for ■ Ge’ez ■ Gurmukhi ■ Georgian ■ Gujarati (2 languages) differences. ■ Armenian ■ Kannada (4 languages) ■ Tibetan (4 languages) ■ Malayalam (2 languages) ■ Khmer ■ Oriya (2 languages) ■ Lao ■ Tamil ■ Thai ■ Telugu ■ Burmese 6 Global Text Layout Engine Features
● Font Handling ○ Modular fonts ○ Aliasing, fallbacks and substitution ○ Synthetic bold and italic support ● Text Shaping ○ Context based glyphs ○ Ligatures (substitution) ○ Positioning ○ Reordering ● Text Layout ○ Rich text ○ Bidirectional support ○ Line breaking (word wrapping) 7
Font fallbacks 8 Font fallbacks / Font linking
● Font linking automatically picks glyphs from other fonts, if not present in the active one, that offer the Unicode range where the missing glyph is.
● Font linking lets us ships fonts for each script as needed, making the deployments modular.
● Design points: ○ A writable file system is not guaranteed, so Fontconfig’s cache solution would not work for us. Fontconfig might not be available on the system so we would have to supply ours. ○ We are not generic: we control the fonts that are in our system and the content we are going to display. ○ We know the font we want to use for every writing system. 9