zulip-mobile icon indicating copy to clipboard operation
zulip-mobile copied to clipboard

Bundle a font in the app and use it consistently

Open gnprice opened this issue 7 years ago • 3 comments

There are a lot of spots in the app where our layout is affected by nuances of the font used.

  • An extreme example is #2365 -- a component we get from one of our dependencies comes out completely broken with the default font on certain devices.
  • A more subtle example was uncovered in chat at #mobile > input height discrepancy. Fonts differ in how much vertical padding they build in -- for the sake of ascenders and descenders in Latin letters, or more so for some other scripts like देवनागरी that use more vertical space -- and that can cause the same text widget, with all the same properties right down to the font size, to lay out with a different height when given a different font. That in turn makes it quite difficult to design a layout that consistently looks right.

In the web app, we solve this by specifying a specific font, and providing the font in case the browser doesn't have it. We should do the same thing in the mobile app.

In the web app, the font we use is Source Sans Pro. We could use that, or another free font -- see the Google font directory for many choices, but two particularly likely candidates would be Noto and Roboto.

A quick feasibility check: the full download for Noto Sans is 16MB, but that's easily cut down to 2MB by dropping exotic variants like "SemiCondensedLightItalic", or 1MB with modern compression (xz). I think even my 1MB list has more variants than we probably need.

gnprice avatar May 03 '18 01:05 gnprice

https://github.com/zulip/zulip-mobile/issues/3885 is targeted at older Android devices to get all emoji glyphs to display. It outlines a way to fetch a font dynamically on Android, instead of bundling it with the app.

chrisbobbe avatar Feb 20 '20 02:02 chrisbobbe

Ah, thanks for drawing that connection! I'd forgotten we had this old issue filed.

One difference between the situation for emoji and for text is this:

A quick feasibility check: the full download for Noto Sans is 16MB, but that's easily cut down to 2MB by dropping exotic variants like "SemiCondensedLightItalic", or 1MB with modern compression (xz). I think even my 1MB list has more variants than we probably need.

Whereas the Noto emoji are a single font file NotoColorEmoji.ttf, and it's 9.4 MB (in the latest/largest version I have lying around, from the Android SDK v29 aka for Android 10) and compresses down only to 8.7 MB.

So if we wanted to bundle a font for (Latin-script) text, I think we could, unlike for emoji. ... OTOH I don't think any reports of the kinds of issues above have been on iOS, and that's natural because most of the arbitrary variation is from different vendors' Android devices. So there may be no advantage to doing so over the #3885 approach.

gnprice avatar Feb 20 '20 19:02 gnprice

We had a report the other day of another issue with text getting cut off early: https://chat.zulip.org/#narrow/stream/48-mobile/topic/translation.20display.20issue/near/1564807

which turned out to have the same root cause as #2365 did, namely https://github.com/facebook/react-native/issues/25481 (formerly known as https://github.com/facebook/react-native/issues/15114 .)

In that case, the issue was triggered by the device settings having a bold font selected.

gnprice avatar May 09 '23 18:05 gnprice