1394278 - Font changes in-line when lang="nan"

Status: NEW

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

Description

[Kevin Hsieh]

Attachment: testcase.htm

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Nightly version: 57.0a1 (2017-08-27) (64-bit)

Steps to reproduce:

Open the attachment.

Actual results:

The appearance of U+25CC DOTTED CIRCLE changes in-line after the combining diacritic U+0358 COMBINING DOT ABOVE RIGHT, possibly because the font changed. Furthermore, the combining diacritic renders outside the base character's box and overlaps with the next character (perhaps this is a separate bug).

Expected results:

All the U+25CC DOTTED CIRCLE look the same, and U+0358 COMBINING DOT ABOVE RIGHT doesn't overlap with the next character. See screenshot of Safari rendering.

Comment 1

[Kevin Hsieh]

Attachment: safari.png

Comment 2

[Kevin Hsieh]

Attachment: firefox.png

Comment 3

[Peter Chang[:pchang]]

Astley, this is likely a layout issue. Can you have someone to check it?

Comment 4

[Jonathan Kew [:jfkthame]]

I think this is an artifact of an optimization in the font selection code in gfxFontGroup::FindFontForChar.

Our default serif font on macOS is Times, so that's what is in the font group's font-family list here. But Times doesn't include the U+25CC dotted-circle character; so fallback occurs. In gfxPlatformMac::GetCommonFallbackFonts, we try Hiragino Kaku Gothic ProN as a fallback for this Unicode symbol range, so that's what we see for the initial run of dotted circles.

But then we run into U+0358, and again, it's not present in Times (so we have to do fallback). In this case, I believe GetCommonFallbackFonts doesn't help, and we get all the way to the "global" system fallback code path, and there we end up finding Times New Roman. (At least on my system.)

Then we have another dotted circle. But this time, when gfxFontGroup::FindFontForChar determines that it can't find the character in the font group's list, or via prefs, it reaches this line:

https://dxr.mozilla.org/mozilla-central/rev/db7f19e26e571ae1dd309f5d2f387b06ba670c30/gfx/thebes/gfxTextRun.cpp#3070-3075

and here it finds that it can use the same font (Times New Roman) as the preceding character, and it does so. And likewise for the following dotted circles.

The idea here was clearly to try and minimize "ransom-note" effects when font fallback is occurring on a per-character basis; if we're able to use a single font for a whole run of characters, this will usually be better than frequent font changes. But in this particular example, the result is rather odd. :(

Comment 5

[Astley Chen (inactive)]

Thanks for Jonathan's feedback in comment 4.

With some spot checks on other platforms, mint Linux and Windows 10 can render the text correctly as the fonts in use are DejaVu Serif and Times New Roman respectively. This is a macOS only issue.

Comment 6

[Jonathan Kew [:jfkthame]]

While this particular example is macOS-specific (it doesn't occur on the other platforms because Times New Roman and DejaVu include the dotted-circle character, so fallback doesn't come into play), the underlying issue exists across all platforms and I'm sure equivalent examples could be constructed by finding alternative characters where fallback is involved.

Comment 7

[Astley Chen (inactive)]

(In reply to Jonathan Kew (:jfkthame) from comment #6)
> While this particular example is macOS-specific (it doesn't occur on the
> other platforms because Times New Roman and DejaVu include the dotted-circle
> character, so fallback doesn't come into play), the underlying issue exists
> across all platforms and I'm sure equivalent examples could be constructed
> by finding alternative characters where fallback is involved.

Yes, thanks for making it clear.
I'm wondering the priority of this bug and seems to me it's rarely a user-facing issue.

Comment 8

[Peter Chang[:pchang]]

Oops...I shouldn't change the component.