Closed Bug 1591863 Opened 5 years ago Closed 5 years ago

The Tahoma arabic font will fallback to Segoe UI when the platform font list is reinitialized

Categories

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

72 Branch
x86_64
Windows 7
defect

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox-esr68 --- wontfix
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- fixed

People

(Reporter: over68, Assigned: jfkthame)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Steps to reproduce:

  1. Download Font Loader.
  2. Download Franklin Gothic Book Regular.ttf.
  3. Download and extracts the archive.
  4. Open index.html.
  5. Open the Font Loader, Click on the Add Fonts button, Select the font file Franklin Gothic Book Regular.ttf then click Open.
  6. Click on the Load button.

Actual results:

The Tahoma arabic font will fallback to Segoe UI when the platform font list is reinitialized.
The font appears correctly when press Shift-Reload.

Priority: -- → P3

This doesn't reproduce for me on win10, probably because of different font versions; I get the Arabic text rendered in Times New Roman Bold. (Are your font settings in Preferences all the defaults, or is Tahoma specified there?)

To confirm, does this occur when the gfx.e10s.font-list.shared pref is enabled, or is it specific to the old platform font list implementation?

Flags: needinfo?(jfkthame) → needinfo?(over68)

(In reply to Jonathan Kew (:jfkthame) from comment #2)

This doesn't reproduce for me on win10, probably because of different font versions; I get the Arabic text rendered in Times New Roman Bold. (Are your font settings in Preferences all the defaults, or is Tahoma specified there?)

lang="ar" has been added to index.html in the archive, You can try. All font settings are default.

To confirm, does this occur when the gfx.e10s.font-list.shared pref is enabled, or is it specific to the old platform font list implementation?

I can reproduce with and without enable gfx.e10s.font-list.shared.

Flags: needinfo?(over68) → needinfo?(jfkthame)

I can also reproduce when open index.html then click on the Reload button.

Thanks, I can now reproduce this as well. Weird ... will investigate.

Assignee: nobody → jfkthame
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jfkthame)

AFAICS, the expected result here would be for the Arabic text to render in Segoe UI Bold, given the default prefs:

  pref("font.name-list.sans-serif.ar", "Segoe UI, Tahoma, Arial");

So the question is why we're picking Tahoma Bold instead on the initial load.

OK, this is happening because Segoe UI Black (unlike the lighter faces of Segoe UI, including Bold) does not include Arabic characters.

We end up in gfxFontGroup::FindFontForChar with a font list that includes the Roboto webfont (initially not loaded), and then Segoe UI, Tahoma and Arial from the default sans-serif generic, which we append to the font family list from CSS if no generic is given.

When we come to look at Segoe UI, because the testcase has font-weight:800, we choose the Black face. But then (depending exactly which code path we're on and what fonts have been instantiated) it's possible that we'll find that it doesn't support the Arabic character at https://searchfox.org/mozilla-central/rev/11d9c7b7fa82fdfb8ac2a8f0864e9d8d5fe2b926/gfx/thebes/gfxTextRun.cpp#2890-2898 and go on via continue to the next family in the list (Tahoma), without reaching the code later in the function at https://searchfox.org/mozilla-central/rev/11d9c7b7fa82fdfb8ac2a8f0864e9d8d5fe2b926/gfx/thebes/gfxTextRun.cpp#2963-2973 that would fall back to the Bold face.

So the fix is that we should not continue the loop early at line 2897; we still need to consider the possibility of fallback to another face within the family.

Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/de812e14530d
Ensure we don't sometimes bypass the possibility of intra-family style fallback in system fonts. r=lsalzman
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
Flags: qe-verify+
Has Regression Range: --- → yes

I tried to reproduce on a VM-Win7 64bit, but every time i try to load the font into the Font Loader the program freezes and is unresponsive. Would you be so kind as to verify this fix as well on latest Beta/Nightly?
Thank you.

Flags: needinfo?(jfkthame)

I don't have any Win7 systems, sorry. (But I'm pretty sure that if this were still an issue with current versions, the reporter would let us know.)

Flags: needinfo?(jfkthame)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: