On Thu, Aug 6, 2015 at 11:09 AM, Arthur D. Edelstein arthuredelstein@gmail.com wrote:
On Thu, Aug 6, 2015 at 9:41 AM, David Fifield david@bamsoftware.com wrote:
On Thu, Aug 06, 2015 at 01:36:57PM +0200, Moritz Bartl wrote:
On 08/06/2015 11:43 AM, David Fifield wrote:
Oh, very interesting. It seems the difference is only in one code point, in the "cursive" and "fantasy" styles (last two columns): [...] Could you make screenshots of the two renderings?
Attached. I don't see any difference between default and cursive.
That's very interesting. In just that one code point, your computer chooses a sans-serif font for the "fantasy" and "cursive" styles, while mine chooses a serif font. Probably we would find more examples if we tested more of Unicode.
I would not have expected a difference like this. It does not come down to small rendering differences; the browser is simply choosing a different font. Perhaps there is something non-deterministic about how Firefox (or Fontconfig) loads its font files. Like, maybe it iterates a directory in inode order and takes the first match when there is a tie.
If you add "Noto Serif Armenian" or "Noto Sans Armenian" to the lists in the prefs "font.name-list.fantasy.x-unicode" and "font.name-list.cursive.x-unicode" (these can be edited in about:config) does that determine the font chosen for that code point and allow you to get a checksum match? If so, it seems we should include as many fonts as possible in each "name-list" to ensure the font priority is consistent across platforms.
I'm finding that if I modify "font.name-list.fantasy.x-western" to include "Noto Sans Armenian" or "Noto Sans Serif" I control which of the two fonts is chosen. Unfortunately, if I add the attribute `lang="jp"` to the HTML span element enclosing the glyph (using the Firefox dev tools), then the font chosen is determined instead by "font.name-list.fantasy.x-unicode".
So it looks like we need to provide the order of fonts to every "font.name-list.*" pref whenever there might be more than one font covering the same code point. In the currently bundled collection, there are only a few fonts with overlapping code point coverage, so it shouldn't be too bad, I hope.