I thought this was going to be a simple explanation, and part of it is, but the more I investigate the more confused I get. A thread in 3 parts: - What people are complaining about - What I tried - What makes a font appear the way it does
Is there anything Twitter can do about this? Im not sure they can influence the development choices of Androids font renderer, unless they implement one themselves And I doubt they are ready for another corporate typeface redesign, even just to flatten the bases of the bowls.
So is font hinting and subpixel rendering being done? I really cannot tell. I guess the easiest way to have crisp text on mobile is to use a larger display font size and use a phone with a hi-res screen.
The only info I managed to find says that Android uses OpenGL for font rendering: The text shaping is done in software (with the harfbuzz library) ascenders and bowls are largely aligned so pixel alignment is easy too I know iOS doesn`t use subpixel rendering and I imagine Android doesn`t either. With rotation, complex AMOLED pixel layouts, and the high dpi of mobile screens, it`s just usually not worth it
It seems to me that the Android font renderer is not doing much with pixel alignment. Im not sure what it is doing with font hinting information. Its rendering the bowls a full pixel below the baseline instead of paring them off. This is visually obvious at small font sizes.
But this is disastrous for digital fonts: youll have a really hard time with pixel alignment. You have to sacrifice either the ascenders, or the bowl. It seems most font renderers choose to sacrifice the bowl. achieve visual alignment you cannot have the base of ascenders align with the outline of the bowls; they will appear ever so slightly misaligned. You want the bowls slighly below the baseline. It works when you print it out, because printing is much higher-res! is based on GT America, a typeface originally designed for print. Design for print seeks to achieve visual alignment, which is often counterintuitive for logical types. See for some examples: is Merriweather, a font designed for screens first Notice that ascenders/descenders (vertical) align at the base with the bowls, in letters like b and d. This makes pixel alignment very easy will change the dimensions of your font by 5 to 10%! Lastly, the font design itself ...
The more pixels you have in a given space, the better a font will look. They almost always look great on hi-res tablet screens for this reason. Next, font size. If it is too small, and you have only between 10 to 20 pixels across for a font, a 1-pixel difference is a lot.
Okay, so if the font has kerning and hinting information, and the font renderer is able to use it sanely, we should have nice text(?) What else? Firstly, screen dpi.
In Windows 7, DirectWrite is responsible for font hinting: In Linux, autohinting is done through fontconfig Im not sure for MacOS but it appears to have autohinting. Much more than you wanted to know about rasterising: how to reshape the font. Opentype allows hinting zones to be applied to parts of the glyph to tell the renderer which parts to align, which is a more flexible approach. Whichever method is used, if this is done well, your fonts should appear less blurry.
the pixel grid of the screen. A smart font renderer usually distorts the shape of the glyph (within reasonable range) so that it aligns as closely to pixel boundaries as possible. Truetype lets a font designer embed hinting information into the font itself, as instructions
So thats one place to start looking on a desktop OS. I cant find any info on whether this is done for mobile OSes The next trick is called font hinting. You dont want to render a font according to its exact shape on an LCD screen, because it would not align well with
as an on-by-default feature starting with Windows Vista, where it was called Cleartype. Linux would later pick it up througg the freetype rendering library. MacOS seems to have this under its LCD font smoothing option: trick to make fonts look sharper than they are relies on the fact that LCD pixels are made up of RGB subpixels. By selectively lighting up the red or blue subpixels, you can make fonts appear to take up fractions of a pixel. This technique, subpixel rendering, was pioneered only makes text legible, it doesnt make it look good yet. If your display device has large pixels, or if each glyph is so small that it is shaped only by a handful of pixels, its difficult to make it look good.
uneven-looking spacing. After this step, the renderer has to decide how to turn a bunch of geometric shapes into a grid of pixels. A few tricks are used here to make the text even legible. A more comprehensive treatment: text shaping, the font renderer breaks up a text block into lines, determines the position of each glyph in the line, then applies adjustments: for justify-alignment, for kerning, for ligatures, according to a complicated rulebook. If this step goes wrong, you get
Each character in a font file is called a glyph. Glyphs have bounding boxes and a defined baseline. The shape of each character is a vector described mathematically. If you simply place the boxes next to each other side by side, the spacing would be horribly off.
So what accounts for these differences? A quick primer on font rendering. Im heavily compressing a technical subject into a few tweets, and fully expect to be wrong on some things. Please comment and correct me for posterity.
And yet the issue does crop up on Android! Its more obvious at small font size (left) than at medium (right). Look at the bowls vs the descenders, on letters like b and d. Compare the t and the i adjacent to it. is the result: Chirp with autohinting applied, and loaded as an OTF font I am hard-pressed to point to any obvious differences between the woff (vanilla) version and this one. On my screen, this appears to marginally reduce the fuzziness, but it doesnt translate here font hinting information shows up as a series of raw truetype instructions, and I am not knowledgeable enough to evaluate their effectiveness. What I could do instead, is apply fontforges autohinting to Chirp, save it as an OTF, and attempt to have my system load it hinting areas (the green and blue shading) do not get encoded into truetype (ttf) and webfonts (woff), but they do get encoded into opentype (otf) fonts. They is why they showed up for Source Sans, but not Chirp an earlier post, I thought Chirp didnt have font hinting information. This turned out to be wrong. Id determined that Chirp does have kerning information encoded. It just doesnt seem to result in consistent-looking spacing appears to crop off the right-side tail of the a to a larger degree, and render it looking slightly narrower.
Next, switching bsck to Chirp. First image is a screenshot, second image is taken with my phone. Chrome seems to render with a bit more fuzziness; antialiasing bleeding into adjacent pixels more. And notice the difference in the rendering of a noticed Twitter`s image conversion does something weird to the pic. Ughhh.)
First, I used the devtools console command from to restore the old UI which defaulted to Roboto on my system Little difference between Firefox (left) and Chrome (right) reports varied. Some reported hardly noticing the issues, while for others they were glaring, sometimes to the point of nauseation Time to run some experiments on Linux.
This is a concise history of the development of grotesque/grotesk/gothic typefaces from the early 18th century to modern-day
Unaligned baseline; bowls (the circular part of characters like b, d, and o) not aligning with ascenders/descenders (vertical strokes) kerning issues, funny spacing the complaints. That g-tail. This is aesthetics; its a common design from American Gothic typefaces, which were themselves derived from European Grotesk typefaces in the early 1800s. No comment for this thread. going to be tweeting while out of the house so this may take a while to finish. I dont plan to comment on the aesthetics of Twitters new font. Thats going to be a whole nother post that I dont plan to write. This thread is about the technicalities of font rendering.
