Closed Bug 1119619 Opened 8 years ago Closed 6 years ago

Fonts displayed differently in FF 35


(Core :: Graphics: Text, defect)

35 Branch
Windows 7
Not set



Tracking Status
firefox36 --- wontfix
firefox37 --- affected
firefox38 --- affected
firefox39 --- affected
firefox48 --- fixed
firefox-esr31 --- unaffected


(Reporter: mvocom, Assigned: jfkthame)



(Keywords: regression, Whiteboard: gfx-noted)


(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150106233618

Steps to reproduce:

Fonts in many Hebrew sites are displayed differently (and wrongly) in FF 35.

Go to:

This is prior to 35:

And this is with 35:

I don't know if this is relevant:
"Windows-1255" does not appear in "Fallback Character Encoding".

See Bug 1118981.
See also Bug 604991.
Yaron, can you post a screenshot of before and after the FF35 update? That will provide a clue if this is the same issue as bug 604991.

(In reply to Yaron from comment #0)
> I don't know if this is relevant:
> "Windows-1255" does not appear in "Fallback Character Encoding".

That at least we can eliminate as relevant: if this was an encoding issue the text would appear as mojibake ("Chinese"), not the correct characters in the wrong font.
Thank you Simon. I appreciate it.

Two screenshots with "browser.display.use_document_fonts" set to 1.

Two screenshots with "browser.display.use_document_fonts" set to 0.

NOTE: I've disabled Clear Type and "Smooth Font Edges".

In the links I posted earlier, the affected font is Verdana.
So from the screen shots this looks very like bug 604991 or bug 644162 all over again. Did we make some change to gfx backend prefs in FF 35, or something else which would have caused this to resurface?
Flags: needinfo?(jdaggett)
Hi Simon,

This bug is really annoying.
Can you please think of someone else who might look into it?

Thank you.
I suspect this is a regression caused by bug 998869, which landed in FF35 and changed how fontlists are passed around internally. Code in layout/style does some funky things with generics and I'm guessing this is a case where the new code didn't quite perfectly mimic the old code. That said, this problem may also be related to a lack of properly pref font list handling that the new code simply exposed.

I'll investigate this by the end of the week.
Flags: needinfo?(jdaggett)
Blocks: 998869
Thank you John. I appreciate it.
John - Did you have a chance to look at this? If not, can you still take it?
Component: Untriaged → Graphics: Text
Flags: needinfo?(jdaggett)
Keywords: regression
Product: Firefox → Core
Flags: needinfo?(jd.bugzilla)
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160303134406

Hi Yaron,

I have tested your issue on latest FF release (45.0) and latest Nightly build and could not reproduce it. I have opened the link you provided and I haven't seen any font issues. Chrome and IE have the same behavior as Firefox.

Is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build ( and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (

Flags: needinfo?(mvocom)
Hi Paul,

I have just tested it on FF 45 (new profile), Pale Moon 26 and IE 8.

FF 45:

PM 26:

IE 8:

I hope you can notice the difference.
Could you please upload a screenshot of that site?

Thank you.
Flags: needinfo?(mvocom)
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160315153207

Hi Yaron,

I have tested your issue on latest FF release (45.0.1), latest Nightly build (20160321030217) and managed to reproduce it. Your latest print screens were more useful and they show the issue more accurately. Chrome, IE and Edge displays the same font when is opened.

Ever confirmed: true
Hi Paul,

Thank you. I appreciate it.
And now it just needs to be fixed. :)

Jonathan, can you reproduce, and agree with comment 7?  Thoughts on how to proceed?
Flags: needinfo?(jfkthame)
Thank you Milan. I appreciate it.
I'm not seeing the problem on my Windows (8.1) system on the site (maybe they've modified the CSS being used?). But I can reproduce something that may be related using a simple testcase: on Windows, with the DirectWrite font backend in use,

  data:text/html;charset=utf-8,<div style="font-family:Arial;font-weight:900">hello  עברית world

will render the English words in Arial Black, as expected, but the Hebrew appears in Times New Roman Bold.

Note that this happens only if hardware acceleration is enabled; disabling it in Options/Advanced (and restarting the browser) should make it all revert to consistently using Arial Bold.

This problem occurs because (under DW), Arial Black is part of the Arial family, but it doesn't have the same character coverage as the regular face; specifically, it lacks Hebrew. So what I think happens is that font-matching has selected that as the best-match face for the specified style; we then look at its character repertoire, find that the Hebrew characters are missing, and fall back to the next family in the font-family list ... or if there isn't one, to a default (which happens to be serif).

As Simon pointed out in comment 5, this has been a longstanding issue, and AFAICS we've never really resolved it. It's quite likely the font-list changes mentioned in comment 7 may have affected the exact conditions where it shows up, but I suspect the underlying problem has been there ever since we adopted DirectWrite.

Whether this is truly the same issue as originally reported for is not clear to me, as I haven't seen the problem on that particular site.

Yaron, do you still see this on the original site? If so, please do a couple of things to help confirm what's happening:

(a) Try disabling hardware acceleration; does that fix it?

(b) (In Nightly, with h/w acc re-enabled) Go to about:config and set devtools.fontinspector.enabled preference to 'true'; then right-click on one of the badly-displayed headlines, choose Inspect Element, and then click the Fonts panel in the inspector. What fonts does it report are being used?

(c) Still in the Inspector for a problem headline, what does the Computed style panel show? (In particular for font-family and font-weight.)

Flags: needinfo?(jfkthame) → needinfo?(mvocom)
Hi Jonathan,

Disabling hardware acceleration does not fix it.

Results with FF 48:

Thank you. I appreciate it.
Flags: needinfo?(mvocom)
(In reply to Yaron from comment #17)
> Hi Jonathan,
> Disabling hardware acceleration does not fix it.

Did you restart the browser after changing that setting? It doesn't take effect until the next launch. (Sorry, I should have said that.) If it's still a problem then, please also let me know what the Inspector says about the fonts when h/w acc is disabled -- exactly the same as enabled, or are there differences?
Flags: needinfo?(mvocom)
I did not restart the browser.

Disabling hardware acceleration does solve the issue.

Flags: needinfo?(mvocom)
OK, thanks -- that confirms what's going on here. I'm hoping to have a patch ready shortly to make things work better (without needing to disable h/a).
Thank you. I do appreciate it.
The problem here happens when there are some faces within the family (such as Arial) that have a reduced character repertoire -- e.g. Arial Black and Arial Narrow don't include Hebrew, although it is supported in the Regular and Bold faces.

Another example that demonstrates the problem is

  data:text/html;charset=utf-8,<div style="font-family:Arial;font-stretch:condensed">hello  עברית world

which will fall back to Times New Roman for the Hebrew characters, because they are not present in the Arial Narrow face.

We already have code that deals with this situation when it's an Italic face that lacks certain characters, because this led to problems with Arabic script; fonts like Arial and Times New Roman don't include Arabic characters in their Italic faces, so we fall back to the Regular face and apply a slant instead. We just need to extend that kind of behavior to other stylistic attributes as well.
Assignee: nobody → jfkthame
Note that the above patch removes the existing FindNonItalicFaceForChar() method, and just uses the (more general) FindFallbackFaceForChar instead, even for the italic case. This is because FindNonItalicFaceForChar() doesn't actually work properly in a case like

  data:text/html;charset=utf-8,<div style="font-family: Arial; font-style: italic; font-weight: 900">
    hello العربي world</div>

In this case, initial font-matching will find Arial Bold Italic; but that doesn't support the Arabic letters, so we call FindNonItalicFaceForChar. That will look for a non-italic face, and find Arial Black (because of the font-weight value); but Arial Black also lacks Arabic, so we give up on the Arial family and fall back to something unrelated (e.g. Times) instead.

Using FindFallbackFaceForChar() instead solves this, because it will find the best-matching face in the family that *does* actually support the given character; in this case, we'll get Arial Bold, and then apply synthetic italics to it, which is the desired result.
Attachment #8741510 - Flags: review?(m_kato) → review+
Bug 1119619 - Allow font-selection to fall back to an alternative face within the same family if the first-found face was not Regular, to handle cases where some styled faces have a reduced character set. r=m_kato
Duplicate of this bug: 604991
Duplicate of this bug: 644162
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Great. Thank you very much.
Regressions: 1591863
You need to log in before you can comment on or make changes to this bug.