This is a great reference, but ten years out of date. Unfortunately there is no really good central place to get updated information on this.
For almost five years, I was tech lead of the text stack in Android. There are a few things about the architecture not to like, but overall it is a world-class implementation - it has refinements like hyphenation and Knuth-Plass style paragraph layout, and of course emoji. It also had the benefit of Roozbeh Pournader's work for much of that time, so it gets Unicode and locales right. Among other things, I claim it does one of the best jobs on the "CJK problem" of any stack out there, using both font selection and the locl OpenType feature to adapt rendering for the preferred language(s). It's open source of course, but does suffer from thin public documentation.
I'm interested in building the next stack in Rust, and have done some work in this direction. I'd love to see solid documentation as part of that effort, but of course writing takes time and effort, and the target audience is quite specialized.
> Among other things, I claim it does one of the best jobs on the "CJK problem" of any stack out there, using both font selection and the locl OpenType feature to adapt rendering for the preferred language(s).
What does Android infer the preference from? I’m using U.S. English as the UI language with input method set to combined Finnish and English (with Simplified Chinese, Traditional Chinese, Korean and Vietnamese also in my input method list) and using a Finnish SIM, and Android 9 seems to pick Simplified Chinese glyphs for me. (I’m not suggesting these signals should have another result. I’m just curious what signals are considered meaningful.)
The main signal is the locale setting, which can have a list of languages in it. For example, you could have Finnish as your primary language, with Hong Kong Chinese second. Then CJK will get rendered as zh-Hant-HK.
Apps can set locale explicitly to override that, but almost none do. Probably the motivating example is a translation app, which can then render both, say, Chinese and Japanese correctly.
Input methods are technically a separate setting from your locale list, which is maybe confusing but that's the way it is.
I believe it was the default from Marshmallow through Pie, but as of 10 it's default off because the powers that be decided that performance was more important. And it was actually on even without full justification, as it improves appearance and density for ragged-right text as well. One of the things we tuned is trying to avoid a final line with just one word on it - in that case, it's far more likely to insert a hyphen to avoid that. I think that's really nice in mobile, where screen real estate is at such a premium.
I’m surprised Knuth-Plass was noticeable; it’s not greedy cheap, but it’s got to be a drop in the bucket compared to rasterization. Did y’all make sure to implement the O(n) version, or did you do the O(n^2) variant?
Well, it's O(nm) where m is the number of candidate breaks on the line. The amount of time spent Knuthing and Plassing is not too bad, but where it does hurt you is that you have to measure the substrings with potential hyphenation breaks. And even if rasterization is more costly, layout hurts because often you have to do lots of it in bulk, when materializing new content, where rasterizing usually scales with the number of pixels you have to draw. And in Android that basically has to happen on the UI thread (offloading it to an async thread is theoretically possible but a major pain).
I haven't been involved in day-to-day engineering on Android in 3 years though. Maybe of the current team will feel like chiming in.
.. reading the post, do we need to be reminded that text is rendered on more devices than an Android mobile phone? Is 'done' == 'dead' here?
A web browser and a desktop interface (windowing,menus,mouse) sharing core glyph engine components sounds important, at least. In other news, the state of font availability, rendering fidelity and directional support are always going to be changing across the entire world, no?
For almost five years, I was tech lead of the text stack in Android. There are a few things about the architecture not to like, but overall it is a world-class implementation - it has refinements like hyphenation and Knuth-Plass style paragraph layout, and of course emoji. It also had the benefit of Roozbeh Pournader's work for much of that time, so it gets Unicode and locales right. Among other things, I claim it does one of the best jobs on the "CJK problem" of any stack out there, using both font selection and the locl OpenType feature to adapt rendering for the preferred language(s). It's open source of course, but does suffer from thin public documentation.
Another good source is Chromium, which tends to be a bit more open, with discussions in the bug tracker and published documents, such as https://www.chromium.org/teams/layout-team/eliminating-simpl...
I'm interested in building the next stack in Rust, and have done some work in this direction. I'd love to see solid documentation as part of that effort, but of course writing takes time and effort, and the target audience is quite specialized.