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:
Windows 10:
OS X:
iOS:
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:
+1
I’ve noticed the same - the ‘i’ problem being the most prominent.
"i’ as well
For the i/I situation, you may want to refer to this thread, @danny’s comments in particular:
I don’t recognise the zone picker issue though (iPhone 6S+):
The zone picker text legibility issue reoprted by @Allan_Hsu looks similar to what was reported here:
This definitely seems to be platform dependent and shows up in a variety of screens/windows.
@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:
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:
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 
Amen. If you have right-justified text with no hyphenation, word spacing is always screwed up. You either have to use hyphenation or go with ragged right (and ragged right is more legible, IMO).
I hate to bump an old thread, but … the right-justified text with no hyphenation is my only major visual complaint about an otherwise totally gorgeous app.
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…
the UI is designed around certain metrics, and multiple scripts are matched to meet the same stylistic goals – the font used is Google Noto
I agree about the little “i” issue. Luckily this problem goes away more and more every month as the average DPI get higher and higher.
