Fonts displayed differently in FF 35

RESOLVED FIXED in Firefox 48

Status

()

Core
Graphics: Text
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: Yaron, Assigned: jfkthame)

Tracking

({regression})

35 Branch
mozilla48
x86
Windows 7
regression
Points:
---

Firefox Tracking Flags

(firefox36 wontfix, firefox37 affected, firefox38 affected, firefox39 affected, firefox48 fixed, firefox-esr31 unaffected)

Details

(Whiteboard: gfx-noted)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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:
http://www.news1.co.il/

This is prior to 35:
http://s14.postimg.org/syb5qgme9/Old.png

And this is with 35:
http://s11.postimg.org/66mtvnu6r/FF35.png


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

http://s13.postimg.org/eyh711srb/FF35.png
http://s15.postimg.org/l7skk7d63/Old.png

See Bug 1118981.
(Reporter)

Comment 1

3 years ago
See also Bug 604991.
Yaron, can you post a screenshot of http://smontagu.org/testcases/arialblackweights_heb.html 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.
(Reporter)

Comment 3

3 years ago
Thank you Simon. I appreciate it.

Two screenshots with "browser.display.use_document_fonts" set to 1.
http://s28.postimg.org/5u6k3dda5/FF35_Document_Font.png
http://s22.postimg.org/w0wwiis1t/FFOld_Document_Font.png

Two screenshots with "browser.display.use_document_fonts" set to 0.
http://s4.postimg.org/6p52w2t7h/FF35_Default_Font.png
http://s4.postimg.org/mix098z19/FFOld_Default_Font.png


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

In the links I posted earlier, the affected font is Verdana.
http://s11.postimg.org/66mtvnu6r/FF35.png
http://s14.postimg.org/syb5qgme9/Old.png
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)
(Reporter)

Comment 6

3 years ago
Hi Simon,

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

Thank you.

Comment 7

3 years ago
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)

Updated

3 years ago
Blocks: 998869
(Reporter)

Comment 8

3 years ago
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
status-firefox36: --- → wontfix
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox39: --- → affected
status-firefox-esr31: --- → unaffected
Whiteboard: gfx-noted

Updated

2 years ago
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 (https://nightly.mozilla.org/) 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 (https://goo.gl/PNe90E).

Thanks,
Paul.
Flags: needinfo?(mvocom)
(Reporter)

Comment 11

2 years ago
Hi Paul,

I have just tested it on FF 45 (new profile), Pale Moon 26 and IE 8.
http://www.news1.co.il/

FF 45:
http://s14.postimg.org/z6a7ymj0h/image.png

PM 26:
http://s15.postimg.org/b3b8oi04b/image.png

IE 8:
http://s12.postimg.org/yp8lqurvx/image.png

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 http://www.news1.co.il/ is opened.

Thanks,
Paul.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 13

2 years ago
Hi Paul,

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

Regards.
Jonathan, can you reproduce, and agree with comment 7?  Thoughts on how to proceed?
Flags: needinfo?(jfkthame)
(Reporter)

Comment 15

2 years ago
Thank you Milan. I appreciate it.
(Assignee)

Comment 16

2 years ago
I'm not seeing the problem on my Windows (8.1) system on the news1.co.il 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 news1.co.il 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.)

Thanks!
Flags: needinfo?(jfkthame) → needinfo?(mvocom)
(Reporter)

Comment 17

2 years ago
Hi Jonathan,

Disabling hardware acceleration does not fix it.

Results with FF 48:
http://s24.postimg.org/xpkif84yd/Fonts.png
http://s18.postimg.org/6aa8ggo7d/Computed.png

Thank you. I appreciate it.
Flags: needinfo?(mvocom)
(Assignee)

Comment 18

2 years ago
(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)
(Reporter)

Comment 19

2 years ago
I did not restart the browser.

Disabling hardware acceleration does solve the issue.

Thanks.
Flags: needinfo?(mvocom)
(Assignee)

Comment 20

2 years ago
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).
(Reporter)

Comment 21

2 years ago
Thank you. I do appreciate it.
(Assignee)

Comment 22

2 years ago
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)

Comment 23

2 years ago
Created attachment 8741510 [details] [diff] [review]
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
Attachment #8741510 - Flags: review?(m_kato)
(Assignee)

Updated

2 years ago
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
(Assignee)

Comment 24

2 years ago
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.

Updated

2 years ago
Attachment #8741510 - Flags: review?(m_kato) → review+
(Assignee)

Comment 25

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/916d2a778a48a2da47051c4ccd1c7139a14ed8fd
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
(Assignee)

Updated

2 years ago
Duplicate of this bug: 604991
(Assignee)

Updated

2 years ago
Duplicate of this bug: 644162

Comment 28

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/916d2a778a48
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox48: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
(Reporter)

Comment 29

2 years ago
Great. Thank you very much.
You need to log in before you can comment on or make changes to this bug.