font-weight mapping rules for fonts with missing weights aren't quite correct

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
8 years ago
7 months ago

People

(Reporter: dbaron, Unassigned)

Tracking

(Blocks: 1 bug, {css2, testcase})

Trunk
x86_64
Linux
css2, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

8 years ago
http://test.csswg.org/suites/css2.1/20101001/html4/font-weight-normal-001.htm
http://test.csswg.org/suites/css2.1/20101001/html4/font-weight-normal-001-ref.htm

http://test.csswg.org/suites/css2.1/20101001/xhtml1/font-weight-normal-001.xht
http://test.csswg.org/suites/css2.1/20101001/xhtml1/font-weight-normal-001-ref.xht

CSS 2.1, section 15.6 says:

Once the font family's weights are mapped onto the CSS scale, missing weights are selected as follows:

    If the desired weight is less than 400, weights below the desired weight are checked in descending order followed by weights above the desired weight in ascending order until a match is found.
    If the desired weight is greater than 500, weights above desired weight are checked in ascending order followed by weights below the desired weight in descending order until a match is found.
    If the desired weight is 400, 500 is checked first and then the rule for desired weights less than 400 is used.
    If the desired weight is 500, 400 is checked first and then the rule for desired weights less than 400 is used. 

On Linux, I observe the following bugs in the pairs of tests above (test and reference), with the font that has weights 100, 400, 700, and 900:
 * font-weight: 300 maps to 400 instead of 100
 * font-weight: 800 maps to 700 instead of 900

This suggests to me that we aren't (or pango isn't) quite following the rules given.
The discrepancy is due to gfxPangoFonts using fontconfig for matching fonts to weights.  That is also causes us to get bolder and lighter wrong sometimes.
(I thought there was a bolder/lighter bug but I didn't find it.)
(In reply to comment #1)
> (I thought there was a bolder/lighter bug but I didn't find it.)

That was bug 419962, apparently obsoleted by secret spec changes referred to in bug 93725 comment 33.

Comment 3

7 years ago
(In reply to comment #2)
> > (I thought there was a bolder/lighter bug but I didn't find it.)
> 
> That was bug 419962, apparently obsoleted by secret spec changes
> referred to in bug 93725 comment 33.

The CSS 2.1 spec is being revised to match CSS3 behavior, so
bolder/lighter are a straight mapping that will be handled by the style
system (see definition of bolder/lighter in the CSS3 Fonts spec for the
values).
(Reporter)

Updated

7 years ago
Blocks: 605520

Comment 5

2 years ago
On Linux KDE 4.13.3, Linux 3.13.0-86-generic x86_64, in the 2nd column (W1479) of the test:
 * font-weight: 300 maps to 100
 * font-weight: 800 maps to 900

This suggests that this particular bug has been fixed for quite some time now.

I get expected results with Firefox 48.0a1 buildID=20160401175617 and with Firefox 50.0a1 buildID= 	20160607071209. Can another Linux user confirm this?

Comment 6

7 months ago
On Linux KDE 4.14.30, Linux 4.10.0-26-generic x86_64, in the 2nd column (W1479) of the test:
 * font-weight: 300 maps to 100
 * font-weight: 800 maps to 900

I get expected results with Firefox 54.0 buildID=20170612121707.

Resolving as WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.