972 - [FONT MAC] CSS font-weight: all font weights show as either normal or bold

Status: RESOLVED FIXED

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

Description

[Jan Carpenter]

Font weights normal, lighter, and 100 through 400 all appear as normal text.
Font weights bold, bolder, and 500 through 900 all appear as bold text.
(bold and bolder already reported on bug #970)

Comment 1

[Peter Linss]

Oops, wrong bug.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is generally OK by CSS1, since those are the fonts that are available.
(However, Windows can produce a weight 900 font...)  However, weight 500,
according to CSS1, should be rendered as normal rather than bold.  See:
http://www.w3.org/TR/REC-CSS1#font-weight

Comment 3

[leger]

Setting all current Open/Normal to M4.

Comment 4

[Peter Linss]

This is really an issue with the font code. Who's handling that these days?

Comment 5

[Kevin McCluskey (gone)]

Moving to M10

Comment 6

[Sam Allen]

*** Bug 10316 has been marked as a duplicate of this bug. ***

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See also bug 12453.  This bug needs to be tested on Linux with a font that has
more than two weights.  (Try the test from bug 12453 in IE5 to see that weight
900 does exist on Windows.)

However, the weight 500 bug is a [PP] bug.  It does not happen on Linux.  Again
see the test case for bug 12453 and the following spec references:
http://www.w3.org/TR/REC-CSS1#font-weight
http://www.w3.org/TR/REC-CSS2/fonts.html#q46

Should it be filed as a separate [PP] bug?

Also, this bug might really need to be separate for different platforms.  I
haven't tested it on Linux.  Bug me if you want me to do so.

Comment 8

[Kevin McCluskey (gone)]

Moving to M11

Comment 9

[Kevin McCluskey (gone)]

I investigated the problem on WIN32 and talked to peterl about the solution.
The current code on WIN32 only looks to see if the font weight is greater or
less than 400 and sets the logical font to be either bold or normal.

The solution is to interpret the font weight given as an explicit font weight if
it divides without a remainder into 100. So font sizes of 100 200 300 400 500
600 700 800 900. would be passed through as the logical font weight on WIN32. If
the remainder is 1-9. which is the case for a font weight of say 301, 402, etc,
then the remainder should be interpreted as a the number of times to make the
font bolder. This involves looking for next boldest weight for the font. If the
remainder is 99-91 this should be interpreted as the number of times to make the
font lighter, where (100-remainder) returns the number of times to make it
lighter. All other raminder values (10-90) will not be allowed. The CSS Style
code will clamp the maximum remainder at 9 when making it bolder, and clamp it
at 91 when making it lighter. The current constants in nsStyleConsts uses
increments of 101 and -101 when making it bolder and lighter. These need to be
changed to 1 and -1. However, This change can not be checked in until all three
platforms honor this.

There should be a separate bug filed for Mac and Linux on this, since all of the
work is in the platform specific code.

Comment 10

[Kevin McCluskey (gone)]

Add support for font weights on WIN32.
Previously, all fonts displayed as normal if they where below 400 and as bold if
they were greater .

Now the available fonts are queried and the font weight is selected based on the
algorithm provided in the the CSS2 spec.
Also implemented the CSS1 lighter and bolder logic by looking for the next
available weight.
The weights are queried and cached the first time the font is loaded to avoid
having to query the weights multiple times
for the same font.

Fixed in the Sept 20, 1999, 2:30PM build on WIN32.

Ramiro, reassigning to you for Linux. When working under Linux, please reassign
to dcone for Mac.

Comment 11

[ramiro]

Reassigning to dcone.

dcone: when you are done, reassigning to [e-mail] for the linux work.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Should this be split into separate bugs by platform so it's easier to track?

Comment 13

[Hixie (not reading bugmail)]

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 14

[Matthew Brealey]

> This is generally OK by CSS1, since those are the fonts that are available.
> (However, Windows can produce a weight 900 font...)  

Actually Windows has four weights, corresponding to 100-500, 600, 700-800 and 
900 (in almost every font; e.g., Arial, Times NR, Comic Sans MS, etc.) 

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

[e-mail]:  You just changed this bug from Windows NT/PC to Mac System
8.6/All.  Does Mac System 8.6 serve fonts with more than two font weights?  If
not, then this should go back to Windows/PC.

Comment 16

[dcone (gone)]

This bug has been marked future because we have determined that it is not 
critical for netscape 6.0.  If you feel this is an error, or if it blocks your 
work in some way -- please attach your concern to the bug for reconsideration.

Comment 17

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 18

[Hixie (not reading bugmail)]

Much as it hurts me to do so, I'm actually going to move this back over to what
timeless had set it to. After testing with some recent builds, it turns out that
on Windows we do things right except for the lack of a 900 Verdana font, on 
Linux over Exceed we do things right, but on Mac we do things wrong. In fact,
no Mac browser gets this right (out of Mac IE, iCab and us).

I made a test case:
   http://www.hixie.ch/tests/adhoc/css/fonts/weight/001.xml

dcone: Are you still the right person to fix this? It is an important CSS1 bug.

Comment 19

[Hixie (not reading bugmail)]

Note: I just realised that the reason I marked this P2 is not actually the same
as the summary. On Windows and Linux we change weights at the right point, but
on Mac we don't. (see http://www.hixie.ch/tests/adhoc/css/fonts/weight/001.xml)
Should I open a new bug for that? The bug described in the summary is actually
an XP bug which I would have marked Hixie-PF (i.e., which I don't think is a
Mozilla 1.0 blocker).

Comment 20

[Madhur Bhatia]

Any progress with this bug? 

Comment 21

[Greg K.]

ATSUI (see bug 121540) provides some enhanced font weight functionality.

Comment 22

[Madhur Bhatia]

cc'ing myself

Comment 23

[Greg K.]

See [http://developer.apple.com/fonts/TTQualSpec/QS09/FQS9.html] for what ATSUI
AAT can do for this with suitably enabled fonts.

Comment 24

[Henri Sivonen (:hsivonen)]

Attachment: Test Case tailored for Jaguar default fonts

Comment 25

[Henri Sivonen (:hsivonen)]

Attachment: Expected results on Jaguar for attachment 98263

Comment 26

[Simon Fraser [no longer active]]

Taking bug.

Comment 27

[Greg K.]

See also <http://greg.tcp.com/mozilla/font-weight/Skia/index.xhtml> for a
demonstration of Skia's variable weight as implemented by AAT (and so probably
dependent on bug 121540 for Mozilla support).

Comment 28

[Torben]

Updating OS since support for mac classic is dead.

Comment 29

[Chris Casciano]

to update comment 18 to make up for the past 2 years - there is still no support
here on the mac side where mac side now is (OS X) Safari 1.0, OmniWeb 4.5,
Camino trunk, Moz trunk, iCab 2.9.1, Opera 6.02, IE 5.2.3

moz/camino is also still the odd man out in rendering 600 as normal

Comment 30

[Alex Muehle]

On my website www.redmill.ch a lighter font in grey and italic is displayed as
normal text, even ignoring the grey and italic. Rgds, Alex

Comment 31

[Agustín Fernández]

While some comments indicate this was fixed on Windows I still see it on Windows
XP on Mozilla 1.7 (20040616). I will attach a testcase using Arial.

Comment 32

[Agustín Fernández]

Attachment: testcase using arial

Comment 33

[u81239]

I confirm the testcase. I also ran into this on my site, which renders a nice
inbetween-bold heading in IE6 but not in Firefox.

~Grauw

Comment 34

[John Hawkins]

I was attempting to use this property on my website tonight, and I discovered FF 1.5.0.1 apparently shows the same behavior of only rendering CSS font-weight in either bold or normal... wow... bug open since 1998 and number 972, no less. Impressive! 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Comment 35

[Josh Aas]

With Firefox 2 and the trunk (FF3a1+) using the "testcase using arial," I see 100-600 non-bold and 700-900 as bold. I think this is the correct behavior so this isn't a bug any more. dbaron - do you agree, and if so can we close out this bug?

Comment 36

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Well, it's exactly the behavior that the summary of this bug is complaining about.  I thought Mac had the capability to do extra-bold, although maybe that's been removed.

Comment 37

[Josh Aas]

The summary is saying that the bolding starts at 500, not 700. I thought that was what the complaint was, that we start bolding at too small a font size.

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The summary is:
"[FONT MAC] CSS font-weight: all font weights show as either normal or bold"

Comment 39

[philippe (part-time)]

At time of this comment, Minefield trunk builds display font-weight: [100 200 300] as bold in both attached test cases. 
This might be a regression of bug 364678.

Comment 40

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #36)
> Well, it's exactly the behavior that the summary of this bug is complaining
> about.  I thought Mac had the capability to do extra-bold, although maybe
> that's been removed.

Only if the font has the other weights; that should work right now on the trunk, though there have been some changes to that code recently.  There was a question regarding 600 -- the CSS spec says:

> If any of the values '600', '700', '800' or '900' remains
> unassigned, they are assigned to the same face as the next
> darker assigned keyword, if any, or the next lighter one
> otherwise.

This seems to mean that unless the font has an explicit 600 weight, that it should map to the next darkest (bold).. is that correct?

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #40)
> > If any of the values '600', '700', '800' or '900' remains
> > unassigned, they are assigned to the same face as the next
> > darker assigned keyword, if any, or the next lighter one
> > otherwise.
> 
> This seems to mean that unless the font has an explicit 600 weight, that it
> should map to the next darkest (bold).. is that correct?

Sounds correct to me, and agrees with comment 2.

Comment 42

[philippe (part-time)]

(In reply to comment #39)
> At time of this comment, Minefield trunk builds display font-weight: [100 200
> 300] as bold in both attached test cases. 
> This might be a regression of bug 364678.
> 

This has been corrected in bug 365613.

With that patch: 
* font-weight: 600 now displays as bold.
* fonts that have a wide range of weights display those correctly (example: Gill Sans in the first test case) - that is better than what Safari/Webkit does.

Tested with
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a2pre) Gecko/20070105 Minefield/3.0a2pre ID:2007010516 [cairo]

Comment 44

[Rob Campbell [:rc] (:robcee)]

Attachment: screenshot of testcase #2 in recent GranParadiso build

Based on the results of this screenshot, this looks fixed to me. The Arial testcase seems invalid as there are no other font weights associated with that font other than Regular and Bold. Arial Black is a different font so it wouldn't necessarily get chosen for high font-weight values.

Comment 45

[Greg K.]

Attachment: Screenshot showing failure to utilize full weight variability of Skia font on OS X

Though it’s a special case, we don’t take advantage of the full weight variability of the Skia AAT font face on OS X. This is a screenshot of this feature demonstated using the Intaglio application, which enables it.

Comment 46

[Greg K.]

Attachment: XHTML testcase demonstrating Skia AAT font weight variability on OS X

And here’s an XHTML testcase.