4 ms·
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 y
by raphlinus 7y ago
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.
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-simple-text 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.
- copperx 7y agoGreat to know. I'm curious about Knuth-Plass paragraph layout in Android. Is it the default when text is justified? I wish browsers implemented it, but it seems almost impossible.
- raphlinus 7y agoI 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 gave a talk at ATypI 4 years ago on Android typography, it might be interesting: https://youtu.be/L8LD0BM-Vjk https://youtu.be/L8LD0BM-Vjk
- thechao 7y agoI’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?
- raphlinus 7y agoWell, 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.
- houqp 7y agoWhat's the best way to watch for updates on your next Rust stack?
- raphlinus 7y ago#text stream in xi.zulipchat.com (requires registration, is open to anybody with a Github account).
- dan-robertson 7y agoHow did whole-paragraph hyphenation mix with text editing? I’m guessing people didn’t want to see words shifting around as they types a paragraph. Do hyphens cause accessibility issues for users with low literacy?
- raphlinus 7y agoIt's disabled in editing, and you're absolutely right about that. I never got any negative feedback about accessibility problems. My guess is that since they are standard in print sources, they're manageable.
- hsivonen 7y ago> 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.)
- raphlinus 7y agoThe 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.