Bad Hebrew font on Firefox 4.0b on Win7 on some pages

RESOLVED DUPLICATE of bug 1119619

Status

()

defect
RESOLVED DUPLICATE of bug 1119619
9 years ago
3 years ago

People

(Reporter: list.israel, Unassigned)

Tracking

Trunk
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(2 attachments)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

Images from 4.0b6 and 3.6 (box on left):

http://img46.imageshack.us/f/39891517.png/
http://img708.imageshack.us/f/41570572.png/

Reproducible: Always
Posted image 4.0b6
Posted image 3.6
This problem only occurs on 4.0b (3.x not affected).
Assignee: nobody → smontagu
Component: General → Internationalization
Product: Firefox → Core
QA Contact: general → i18n
Can someone with access to Vista machine contribute some screenshots of this issue? Hebrew Firefox is NOT required. 

Discussion thread on Mozilla Israel - http://mozilla.org.il/board/viewtopic.php?f=9&t=8265.

See also - bug 604990
Version: unspecified → Trunk
I can see the issue on my Vista machine, I'll attach a screenshot later, the font is really hard to read, to much font smoothing.

any known workaround?
oops, i misread the bug description, the bug i'm seeing is completely different and isn't related to this bug. sorry.
The text with the "bad" font in http://img46.imageshack.us/f/39891517.png/ is in a <b>, so it looks as though the default Hebrew font in Windows 7 doesn't exist in bold weight, or we have a problem accessing it.
Assignee: smontagu → nobody
Component: Internationalization → Layout: Text
QA Contact: i18n → layout.fonts-and-text
Could you be more specific about where you're seeing a problem? (And maybe provide images of a minimized example.) On those wikipedia screenshots, I don't see a particularly glaring difference in the rendering of the bold text (e.g. Hubble's name). What should we be looking at, exactly?
The heavy highlighting in http://img46.imageshack.us/img46/3620/39891517.png doesn't help, but the issue is that the font is serif instead of sans-serif as expected.
I think this is a web design error. I haven't trawled through the relevant CSS on wikipedia, but I'm pretty sure the <th> element is already styled as bold; the use of the <b> tag within it therefore calls for an even-bolder font. The default sans font is Arial; so the font gets resolved to Arial Black. But Arial Black doesn't support Hebrew, so the result is that we can't actually use the font family that the CSS was requesting, and we eventually fall back to a default that happens to be serif.

This can be demonstrated with a small testcase such as
data:text/html,<p style="font-family:sans-serif;font-size:36px;">foo&#x05d0; <b>bar&#x05d0; <b>baz&#x05d0;</b></b></p>

Here, the third aleph is rendered using a different (serif) font on Win7 with D2D, because it is not available in Arial Black.

This will only show up when D2D/DWrite is in use, because the GDI backend doesn't recognize Arial Black as an even-bolder member of the Arial family, and so the use of <b> within <th> just ends up using the Arial Bold face (which does support Hebrew), perhaps with synthetic bolding added(?).
(In reply to comment #10)
> I think this is a web design error. I haven't trawled through the relevant CSS
> on wikipedia, but I'm pretty sure the <th> element is already styled as bold;
> the use of the <b> tag within it therefore calls for an even-bolder font. The
> default sans font is Arial; so the font gets resolved to Arial Black. But Arial
> Black doesn't support Hebrew, so the result is that we can't actually use the
> font family that the CSS was requesting, and we eventually fall back to a
> default that happens to be serif.
> 
> This can be demonstrated with a small testcase such as
> data:text/html,<p style="font-family:sans-serif;font-size:36px;">foo&#x05d0;
> <b>bar&#x05d0; <b>baz&#x05d0;</b></b></p>
> 
> Here, the third aleph is rendered using a different (serif) font on Win7 with
> D2D, because it is not available in Arial Black.
> 
> This will only show up when D2D/DWrite is in use, because the GDI backend
> doesn't recognize Arial Black as an even-bolder member of the Arial family, and
> so the use of <b> within <th> just ends up using the Arial Bold face (which
> does support Hebrew), perhaps with synthetic bolding added(?).

I don't think it's a web design error. I found the same problem on other Hebrew websites not related to Wikipedia/MediaWiki and this problem doesn't exist on Firefox 3.x...
I managed to reproduce this by setting gfx.direct2d.force-enabled to true. It's probably the same underlying issue as bug 584769.
Depends on: 584769
We have had reports on the mozilla.il forums of a similar but more serious problem: font fallback is apparently not finding any Hebrew fonts, and Hebrew text is being displayed as hexboxes. See e.g. the screenshot at the top of http://mozilla.org.il/board/viewtopic.php?f=9&t=9932
(In reply to comment #13)
> We have had reports on the mozilla.il forums of a similar but more serious
> problem: font fallback is apparently not finding any Hebrew fonts, and
> Hebrew text is being displayed as hexboxes. See e.g. the screenshot at the
> top of http://mozilla.org.il/board/viewtopic.php?f=9&t=9932

Bug 649611?
This is still getting reported very frequently on the Mozilla Israel forums as an issue that people can't live with in FF4. Even if it is a web design error, it's a sufficiently widespread one that I think we need some kind of compatibility fix for it.

At http://www.mozilla.org.il/board/viewtopic.php?f=9&t=10152&p=50624#p50632 there are screenshots from a user of http://smontagu.org/testcases/arialblackweights_heb.html (which is a variant of http://people.mozilla.org/~jdaggett/tests/arialblackweights.html, with added Hebrew text). The first screenshot is with gfx.direct2d.disabled set to false and the second with it set to true. I think this confirms Jonathan's analysis in comment 10.
Is this an issue people are still reporting?
Flags: needinfo?(smontagu)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #16)
> Is this an issue people are still reporting?

I don't follow the mozilla.il forums very actively, punting to tomer
Flags: needinfo?(smontagu) → needinfo?(tomer.moz.bugs)
Using the highlighted areas of the attached screenshots as a guide, I can reproduce the rendering regressions at the given wikipedia URL between Fx3.6 and Fx4 on my Win10 system. They also reproduce on current nightlies.

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=75caf7ab0376&tochange=68b886f9b3c3

So I assume this is a general issue with the switch to D2D/DirectWrite. On the other hand, both Chrome and Edge manager to display the page more closely to the "good" Fx3.6 rendering, so it feels like there's room for improvement here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(tomer.moz.bugs)
I believe this is the same issue as described (again) in bug 1119619, and the patch just landed there will resolve it; dup'ing forward to the new bug where the fix is happening.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1119619
You need to log in before you can comment on or make changes to this bug.