I'm developing an Android app that requires to use Roboto font to render the UI.
According to https://github.com/google/roboto/releases, there are three types of Roboto font:
Hints are the instructions embedded in a font on how to modify (distort) a glyph to look better on low-resolution displays. As a tradeoff, a hinted font consumes more space than the unhinted version.
Both Roboto and Noto have hinted and unhinted versions. Google recommends:
- Use the unhinted versions on Android and on Mac OS X, which doesn’t implement hints.
- Use hinted fonts on Chrome OS, Windows, and Linux.
What's the difference between roboto-android and roboto-unhinted?
Traditional screens are low-resolution displays.
So low-resolution, in fact, that just scaling font glyphs is horribly pixelated at common text sizes. So text rendering systems do not just scale text, they distort glyph shapes to make them match pixel limits as much as possible (grid-fitting).
Microsoft has historically implemented this via font hints (smart fonts → TTF): the font files themselves contain instructions (code) on how each glyph form should be distorted at specific sizes. The advantage is that your text renderer does not need to be very smart. The disadvantage is that only fonts where someone spent a lot of time writing hinting rules display well on-screen, and that only at the specific pixel densities targeted by this person (that's why Microsoft tried so long to force manufacturers to only produce 96 dpi screens).
Apple chose to focus on dumb fonts (postscript and children → CFF fonts), with a smart rendering engine (that applied the same rules to all fonts).
Font formats are now merged in opentype (TTF + OTF), but a font can still be rendered in dumb mode (the text renderer controls the distortion) smart mode (the font hints control the distortion), or some mixes of both.
Because Linux was forbidden access to windows fonts via legalities, but still hosted many apps written for TTF fonts, the Linux text renderer is able to compute on-the-fly synthetic hints for un-hinted TTF fonts.
And grid-fitting does not matter anyway for high-resolution displays like smartphones and hidpi screens. The pixels are small enough rounding errors during scaling and pixel alignment mismatches are negligible.
– Android: does not need hinted fonts, since it's used on high-res displays, and anyway could probably autocompute hints given it's a Linux variant
– Apple: was never TTF or hint-oriented, uses high-res displays nowadays
– Windows: often used with low-res displays, many apps still use old dumb rendering stack that won't grid-fit correctly without hints
– ChromeOS and Linux: can be used on low-res displays, can autocompute hints, do not absolutely need hinted fonts, but Google probably paid someone to hint the fonts manually, so it considers the built-in hints better (hinting process these days: autocompute hints with the Linux engine, then check manually if it works well, correct when needed, add the corrected computation to the font files. The best automatic hinters produce clean shapes but sometimes distorting too much means glyph stems, that were aligned, are not aligned anymore, because the algorithm moved one shape to the upper pixel line and the next shape to the lower pixel line. A human being is really better at identifying and fixing such cases).
Modern font formats are horrible babel towers of legacy metadata to please all kinds of software (typically: Microsoft used A, Apple B, OS/2 C and Adobe D, let's put A B C and D in the new format so everyone is happy. Besides A B C and D have all their own drawbacks, let's add E which is better for next-gen software). The android version is a little smaller than the unhinted one, Google probably stripped all metadata Android does not use from this version. It will work as well as the unhinted version as long as you only use it on Android, and you'll save on storage.