1459858 - [Mac OS] Some letters are displayed with white lines inside on https://developer.microsoft.com/

Status: NEW

(Core :: Graphics: Text, defect, P3)

Description

[roxleitan]

Attachment: Untitled.png

[Affected versions]:
Nightly 61.0a1 (2018-05-07)

[Affected platforms]:
Mac OS X 10.13

[Steps to reproduce]:
1.Launch Nightly 61.0a1 with a new profile
2.Open https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/variable-fonts/

[Expected results]:
All letters should be displayed correctly

[Actual results]:
Some letters are displayed with white lines inside

Comment 1

[Jonathan Kew [:jfkthame]]

This seems to be an issue at the graphics font-rendering level. These glyphs are constructed with multiple overlapping contours, and we're sometimes seeing faint edges of the pieces where they overlap. It seems to vary with size, perhaps depending exactly how the antialiasing of the individual parts works out.

I've seen the same issue in Chrome, too (but haven't noticed it in Safari), though it seems to be more frequent/visible in Firefox. Perhaps it has something to do with how Skia composites the glyphs, or something like that? Given that it doesn't happen in Safari, AFAICT, it isn't necessarily inherent to Core Text glyph painting.

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Is this a regression?

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Milan Sreckovic [:milan] (needinfo for best results) from comment #2)
> Is this a regression?

Not a recent one, at least. I can reproduce with builds as far back as mozilla50, which is as old as mozregression is able to launch successfully on my current system.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: similar font-rendering issue in Safari

On further testing, I was able to spot the same problem occurring in Safari, as seen in this screenshot.

As such, I think we can regard this as a Core Text font rasterization issue, rather than a Firefox bug. Though if there's anything we can do to mitigate it, that would be good.

Comment 5

[roxleitan]

Mozregression on Mac OS X 10.12:

Last good revision: 652ceb559a7459d466e1d580e3465f0e7608788c
First bad revision: d85e4be1d7875e80e1217576dcaea195fb606edd

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=652ceb559a7459d466e1d580e3465f0e7608788c&tochange=d85e4be1d7875e80e1217576dcaea195fb606edd

Comment 6

[Jonathan Kew [:jfkthame]]

I don't think this is really a "regression" from bug 1341088, as suggested in comment 5; rather, the OTS update there enabled us to load the Bahnschrift font on the MS demo page, whereas previously we had rejected it and rendered a fallback.

The actual issue here is in Core Text's rendering of the font, where glyphs are constructed with multiple overlapping contours, and can be reproduced in much older builds (see comment 3) if the font is allowed to load (by disabling OpenType Layout sanitization). It also reproduces in both Chrome and Safari, though depending on the exact antialiasing mode being used, it may be more or less visible. Comment 4 has a screenshot showing the same issue in Safari (zoom the image to see the glitches, for example where the bowls of "a" and "b" join the vertical stems).

Comment 7

[Chris Lewis]

I'd agree that this is an issue with the way the font is constructed and not Firefox's problem.

More information on overlapping contours in fonts and the problems they cause:

http://help.fontlab.com/fontlab-vi/Remove-Overlap/
http://www.thomasphinney.com/2014/01/overlapping-paths-in-type-design/
https://github.com/scribbletone/vardebug

Most publicly-released fonts will have those overlaps removed during the final production process to avoid this kind of problem. 
In fact, I think I read somewhere that overlapping contours might actually be formally disallowed in production-level variable fonts, but I can't find it now. I'll post here if I do.

Comment 8

[Chris Lewis]

Sorry, I have it backward, it was the earlier PostScript CFF .otf format that disallowed overlapping contours. The new OpenType 1.8 spec explicitly *allows* overlaps, because the variable-font point delta math for multiple contours would be infeasible to translate to a single combined contour. [See https://docs.microsoft.com/en-us/typography/opentype/spec/cff2#8-charstrings-index]

I still agree it's Core Text's problem.