728518 - Poor font face selection for Arabic characters when the style calls for Arial with font-weight:900

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[blinky]

Attachment: testcase

After using the paragraph format with the Arial bold Arabic font, Arial bold turns to Arial normal font.

That happens after you enable hardware acceleration.


Arial bold arabic font
http://i449.photobucket.com/albums/qq217/movh/290ee0d8.png

After changing the format to "Heading 1", Arial bold turns to Arial normal font.
http://i449.photobucket.com/albums/qq217/movh/839f3231.png

http://i449.photobucket.com/albums/qq217/movh/b745932c.png


Should not turns Arial bold arabic font to Arial normal when you use the Paragraph Format.

Comment 1

[blinky]

I think this explains what is happening in the link http://www.adslgate.com/dsl/showpost.php?p=1063716613&postcount=1

http://i449.photobucket.com/albums/qq217/movh/250c2819.png

Comment 2

[Alice0775 White]

Regression window(m-c)
Cannot reprpduce:
http://hg.mozilla.org/mozilla-central/rev/81f6b9cbb2a9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120214 Firefox/13.0a1 ID:20120215021649
Can reprpduce:
http://hg.mozilla.org/mozilla-central/rev/46e22ce549b0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120215 Firefox/13.0a1 ID:20120215083849
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=81f6b9cbb2a9&tochange=46e22ce549b0


Regression window(m-i)
Cannot reprpduce:
http://hg.mozilla.org/integration/mozilla-inbound/rev/44f6dc4eb809
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120214 Firefox/13.0a1 ID:20120214021949
Can reprpduce:
http://hg.mozilla.org/integration/mozilla-inbound/rev/
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120214 Firefox/13.0a1 ID:20120214032749
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=44f6dc4eb809&tochange=80fa4ccd0b2b

Comment 3

[Jonathan Kew [:jfkthame]]

I think the issue here is caused because your markup effectively calls for Arial "extra bold", when you have a <strong> element (font-weight:bolder) within the <h1> element (which is already styled with font-weight:bold). This gives a computed value for font-weight of 900, and when hardware acceleration is enabled, this resolves to the Arial Black face.

But when we then check the character coverage, it turns out that Arial Black doesn't support the Arabic letters, and so we then end up falling back to another face - and apparently we're not making the best choice at that point, for some reason.

Bug 668813 affected this because it caused us to try and find a match within the Arial family before proceeding to the general fallback search (which might have chosen a font from an entirely different family); however, it looks like that "next-best-match-within-the-family" isn't getting the right style.

Comment 4

[Jonathan Kew [:jfkthame]]

Simple testcase, assuming <h1> is styled in Arial Bold by default:

data:text/html;charset=utf-8,<h1>this is العربى h1 <b>and bolder العربى  text

The first part of the line appears in Arial Bold, as expected. Within the <b> element, the English text appears in Arial Black, because it is bolder than bold; but the Arabic characters, which are not supported in Arial Black, fall back to the regular Arial face.

This happens because gfxFontFamily::FindFontForChar does not handle weight matching well when trying to find the face that's the "best match" for a given font. If it finds an exact match, or a face whose weight is within 100 of the desired value, it'll use that; but if not, it effectively ignores the weight value. In the example here, it's trying to find a face for an Arabic character, given Arial Black as a font to match; the weight of Arial Bold differs from Arial Black by 200, and so it is not preferred over Arial Regular.

We'll get better behavior if we fully incorporate the "weight distance" into our evaluation of the closeness of a match, rather than just having a sudden transition between "it's very close" and "ignore it".

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: patch, improve the handling of weight in FindFontForChar

Comment 6

[Jonathan Kew [:jfkthame]]

I pushed this to tryserver, to check that it doesn't break existing font-matching tests on any platform:
https://tbpl.mozilla.org/?tree=Try&rev=fc5aaefd9242

Comment 7

[John Daggett (:jtd)]

Comment on attachment 598543 [details] [diff] [review]
patch, improve the handling of weight in FindFontForChar

> rank += 8 - abs(fe->Weight() / 100 - style->ComputeWeight());

Use 9 instead of 8, since the weight difference of 8 (e.g. desired
weight == 100, actual weight 900) will produce a rank of 0 and the font
will be ignored since 'rank > aMatchData->mMatchRank' won't evaluate to
true.

Comment 8

[Jonathan Kew [:jfkthame]]

(In reply to John Daggett (:jtd) from comment #7)
> > rank += 8 - abs(fe->Weight() / 100 - style->ComputeWeight());
> 
> Use 9 instead of 8, since the weight difference of 8 (e.g. desired
> weight == 100, actual weight 900) will produce a rank of 0 ...

I went ahead and changed it, though it's not actually needed - we set the rank non-zero as soon as we find the character is supported, before looking at style closeness.

https://hg.mozilla.org/integration/mozilla-inbound/rev/4ad3d672bf46

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/4ad3d672bf46