Created attachment 8640996 [details] unicode-rendering-bugs-chromium-firefox.png User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12 Steps to reproduce: What steps will reproduce the problem? 1. Open the URL https://github.com/atom/atom/issues/8026#issuecomment-124875482 2. Look for the unicode oddity provided in a comment 3. Compare the rendering to Safari (or other unicode compliant text renderers) Actual results: Some of the unicode character modifiers are rendered sideways, while they should be rendered above or below the characters they modify. Expected results: It should look like in Safari (Compare the screenshot, Safari (correct) to the left, middle is Chromium, right is Firefox.
Companion bug filed for chromium: https://code.google.com/p/chromium/issues/detail?id=515424&thanks=515424&ts=1438249596
Created attachment 8641099 [details] Windows7.png Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0 20150729030208 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 20150630154324 I can't reproduce this. The issue must be with the font that ends up used on Mac OS X.
In the Chromium bug they came to a similar conclusion (as far as I understand it) they think that it is a question of how fallback fonts are chosen.
For text that uses lots of Unicode combining marks, the author should ensure that a suitable font (i.e. one that supports the characters in question, and has adequate layout support such as OpenType GPOS mark-to-base and mark-to-mark positioning features) is also specified. Without that, results may be inferior, and will vary depending on what font(s) happen to get chosen by fallback algorithms when the default font being used doesn't support all the characters involved.