I bounce between using Windows 10, OS X, and iOS to control Roon and I’ve noticed some text layout issues with large blocks of text. The kerning on the Windows client is particularly bad (look at the space between ‘n’ and ‘d’ in the word “sound”), but OS X and iOS also have their share of issues; the letters within words can look too closely spaced, exacerbated by the weird and irregular inter-word spacing caused by the text justification:
I made a post about this a while ago, but I never heard back from anybody at Roon, so I thought I’d mention it again.
Throughout various clients, font metrics and layout flags are somewhat… unrefined, resulting in poor text legibility.
For example, the lowercase letter ‘i’ is hard to distinguish from ‘l’ and the inter-letter spacing is too tight for the typeface weight being used (the letter "t’ makes the word “stitches” harder to read):
“Now playing” in the zone picker on iOS is weirdly squished/truncated:
Most blocks of AMG-sourced text have very inconsistent kerning applied to get edge-to-edge text justification, resulting in very spaced out text and overcompressed text appearing in close proximity. I think the biggest problem here is that letters and words are allowed to get too close to each other:
@RBM What @danny said in that thread is more or less what I assumed was going on. As a career UI engineer, however, it seems like the currently shipping state of the clients is the worst way to leave it. A combination of these would be a proper solution:
Fix the font hinter - the code is (sigh) available and open for fixes. I suspect this would also fix the paragraph kerning issues with large blocks of text.
Ship the proper bold fonts - the “synthetic bolding” algorithm obviously works poorly in many cases.
Design around the issue - this involves the least coding. Why commit to a design that looks bad on any desktop client not hooked up to a 4k screen or non-retina mobile clients?
Admittedly, I’m sensitive to issues like this because I deal with them for a living, but when I see a shipping product with text layout issues like this, I get the impression that whoever made it is either ignorant of the issue (“looks fine to me!”), or does not care enough to fix it. It feels very unpolished.
As for the zone-picker issue, I’m encountering it on an iPhone 7 (non-plus). It looks like what would happen if the text was rendered slightly larger than display size and then resized to fit using a sub-optimal resampling algorithm.
What iPhone is that top screenshot with the bad “i” on?
Also I’m not seeing the weird spacing/truncating either. Can you explain what looks wrong to you?
The weirdly spaced text on the bio and review is because it is Justified aligned. Notice how the left and right edges of each line of text line up. The algorithm to do that only splits up extra space and adds it evenly between words. The fact that some looks too close is an optical illusion, as the algorithm never removes spacing.
Yikes, merging posts with more data… Let me reread this thread.
Non-retina trade-offs are an area where we are willing to compromise. Additionally, synthetic bolding is required for uniformity. Noto’s bolding is all over the place. Noto is required because it gives uniformity across all platforms for all scripts. We didn’t used to ship Noto, and there were even more issues with missing characters.
We aren’t using harfbuzz yet, but it’s on our to-do.
The bad “i” screenshot is from Windows, though I see it (though not as bad) on OS X as well. I suspect this is just a difference between the OS X and Windows text layout engines.
The weird truncating is hard to see on the shrunk-down version of that image, but pretty obvious at full size.
I think the issue with the justified aligned text isn’t that it’s squishing the text more than normal, but that seeing text with extra space to breathe in close proximity with the “normal” text emphasizes how rough the current kerning is in general. If you look at the work “punk” in my example, there is a weird amount of space between the “n” and the “k” in that word. In the word “times”, the e is given more space then any of the other character (looks like “tim e s”). It seems like the kerning around “t”, “e”, and after “m” and “n” in general is uneven throughout the client.
The engine is the same on all platforms. It is a home built thing (I personally wrote it), it:
renders via OpenGL (2 triangles per glyph from an on-the-fly texture atlas)
uses FreeType with the Harfbuzz hinter for glyph rasterizing.
we don’t use Harfbuzz for glyph shaping (yet). The shaper is a very fast but slightly-better-than-naive. It supports RTL for Hebrew (and obeys about 80% of the unicode “direction switching” rules), plus it can shape some simple Unicode combining characters. It does not support anything complex, like Arabic or Thai. I’d like to move to Harfbuzz, but unfortunately, it is low on the todo list.
Google’s Noto font is used across the board, server side and client side, with synthetic bolding and synthetic italicizing. We synthesize those faces to reduce font size (it could be 100mb+), and also because our designer did not want 400/700 as our regular/bold pairing. There isn’t a 550ish weight face in Noto across most of the scripts, so 400/550ish is what we get with synthetics.
The same engine is used on the server side to compose our Twitter/Imgur/Facebook share images, and the engine is also used to render the text on the face of the Squeezebox LCD panel.
We looked at the “i” at length and decided that the synthetic bold solution was not ideal for the “i”, but was acceptable on higher DPI screens. This problem also gets smaller and smaller every year as no one really is shipping ~100dpi screens anymore.
The truncating of the top pixel of each rasterized glyph is strange. I’ve seen it on my iPad Pro (the 12.9" one) as well, but not an iPad Air or Mini. GPU differences is my guess, and we just need to look into this. I was sure it had to do with the problem that the iPad Pro 12.9 and the iPhone Plus have a weird stage in how they draw (see https://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions – the Physical Pixels row), but if you are seeing this on a iPhone 7 non-plus, that guess is wrong.
Before Noto, our preference for uniformity was to use Arial Unicode when available, which lacks kerning tables. I had the kerning support taken out because we were just doing work for no reason with that font. It semes I forgot to put it back in when we switched to Noto. Before I just go turning it back on, I have to see how it interferes with synthetic bolding, but it clearly needs to be back on.
Danny, that custom engine work is very cool, but I guess it also explains why these issues exist on iOS and OS X, platforms where a very mature and exemplary text layout engine usually comes for free with native controls. I can see there being very real technical and logistical issues for what you’ve done though.
As for high-DPI screens, I see your point, even if I don’t agree. I do most of my work on 2560x1600 or 2560x1440 screens and 1920x1080 is still a very common PC resolution. Again, you could just design around this issue by adjusting aspects of how you render text for non high-DPI screens, or if the synthetic bolding is also in-house, you might just need to scale some parameter by a small sub-pixel amount for screens below some DPI threshold. You might want to do this anyway, because I feel like the “i” rendering on retina display mobile screens is still harder to read than it should be.
As for kerning, I would very much like to see the kerning tables turned back on:) Also, my designer friends are all over the use of hard justification in the AMG text blocks and would very much like to see ragged right, which looks great here in the forums
I was just searching the community forum on how to change the font in Roon, and came across this.
Any reason why we can’t just pick our own fonts? The blurry small “i” showing up as an “l” is rather annoying…