1119619 - Fonts displayed differently in FF 35

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Yaron]

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.

Comment 1

[Yaron]

See also Bug 604991.

Comment 2

[Simon Montagu :smontagu]

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.

Comment 3

[Yaron]

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

Comment 4

[Yaron]

Sorry.
http://s27.postimg.org/bhe2wl4oz/FFOld_Document_Font.png

Comment 5

[Simon Montagu :smontagu]

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?

Comment 6

[Yaron]

Hi Simon,

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

Thank you.

Comment 7

[John Daggett (:jtd)]

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.

Comment 8

[Yaron]

Thank you John. I appreciate it.

Comment 9

[Lawrence Mandel [:lmandel] (use needinfo)]

John - Did you have a chance to look at this? If not, can you still take it?

Comment 10

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

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.

Comment 11

[Yaron]

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.

Comment 12

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

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.

Comment 13

[Yaron]

Hi Paul,

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

Regards.

Comment 14

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

Jonathan, can you reproduce, and agree with comment 7?  Thoughts on how to proceed?

Comment 15

[Yaron]

Thank you Milan. I appreciate it.

Comment 16

[Jonathan Kew [:jfkthame]]

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!

Comment 17

[Yaron]

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.

Comment 18

[Jonathan Kew [:jfkthame]]

(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?

Comment 19

[Yaron]

I did not restart the browser.

Disabling hardware acceleration does solve the issue.

Thanks.

Comment 20

[Jonathan Kew [:jfkthame]]

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).

Comment 21

[Yaron]

Thank you. I do appreciate it.

Comment 22

[Jonathan Kew [:jfkthame]]

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.

Comment 23

[Jonathan Kew [:jfkthame]]

Attachment: 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

Comment 24

[Jonathan Kew [: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.

Comment 25

[Jonathan Kew [:jfkthame]]

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

Comment 28

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/916d2a778a48

Comment 29

[Yaron]

Great. Thank you very much.