32339 - font-weight: bolder and font-weight: lighter not working correctly on Mac

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Christine Hoffman]

Using 2000-03-17-15-M15-nb1b build on Mac8.6.

Open the attached file. The testcase shows font weights 100-900 in default font 
for comparison. (1) tests the 'bolder' value and (2) tests the 'lighter' value 
of the CSS1 font-weight property. The test assumes the font used has at least 2 
weights.

Expected result: In test (1), the font in the second sentence should be 'bolder' 
than the font in the first sentence. In test (2), the font in the second 
sentence should be 'lighter' than the font in the first sentence.

Actual result: In both tests, the two sentences display in the same font. 

What Mac seems to be doing is to go down to the next weight instead of going to 
the first 'bold' weight as Windows and Linux do. If you revise the test to use 
font-weight: 400 for the first test and font-weight: 500 for the second test 
(Mac bolds at 500 with default font), then 'bolder' and 'lighter' work. This is 
because it is the next font.

Note: This is a different bug than #972 which does not address the 
'bolder'/'lighter' problem.

I am adding beta1 to keywords as these are CSS1 values that do not work 
correctly on Mac but do work on Windows and Linux.

Comment 1

[Christine Hoffman]

Attachment: testcase to demonstrate problem

Comment 2

[Jim Roskind]

At this point, unless you are crashing in a COMMON case, there is almost no
chance of getting a PDT+ notation.
IMO, you should pull this bug from a beta1 nomination... but we will review it
on Monday if it is still pending with the beta1 keyword.

Comment 3

[Pierre Saslawsky]

The MacOS Toolbox doesn't support font weights, we only have 'normal' and 'bold'. 
GFX on Mac displays in bold any weight larger than 400.

Closed as Invalid.

Comment 4

[Christine Hoffman]

I'm not sure why this in invalid. I am attaching a somewhat revised testcase. 
There are two examples. In the first example, the initial sentence has a 
font-weight of '100'; The second sentence (child) has a font-weight of 'bolder' 
and the text is NOT BOLDED. However, in the second example, the initial sentence 
has a font-weight of '400'; the second sentence (child) has a font-weight of 
'bolder' and the text IS bolded. Both examples should render bolded text in the 
second sentence.
Reopening bug.

Comment 5

[Christine Hoffman]

Attachment: revised testcase

Comment 6

[Pierre Saslawsky]

You're right: per the spec, this bug isn't invalid.

The Mac has only 2 states, normal or bold, we don't have a range of boldfaces. My 
interpretation of the spec was that everything above 400 (which is defined as 
'normal') should be bold, everything below should be normal, and 'bolder' or 
'lighter' should change the value by increment/decrement of 100. But it's not 
what the spec says: 'bolder' should increase the value to the next step that 
actually produces a bolder text on the screen. It means that we can have a 
situation where if we have 3 nested children that set their font to 'bolder', 
they will display the same bold font and a single additional nested child with 
the font set to 'lighter' will be sufficient to bring back the font to normal. It 
doesn't seem ok. One would expect that "bolder+bolder+bolder+lighter" would be 
the same as "bolder+bolder", instead of "normal".

Comment 7

[Kevin McCluskey (gone)]

Pierre, I implemented this on WIN32 after talking with at length with PeterL. 
The way it works is that your passed a font weight plus a digit which represents 
how many levels to make it bolder or lighter. For example, 2 levels bolder than 
font weight 100 is passed down as 102. 1 level lighter than font weight 700 is 
passed as 699. You will never be passed a stronger or lighter value larger then 
9 so you will never see 110 passed to you if the font weight is 100. 109 would 
be the max.

If you have any questions on this give me call.

Comment 8

[Pierre Saslawsky]

Fixed in nsFontMetricsMac.cpp

Comment 9

[Christine Hoffman]

Using 4/18 build on Mac8.6, verified fixed. Thanks Pierre