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

RESOLVED FIXED in Future

Status

()

P2
normal
RESOLVED FIXED
21 years ago
11 years ago

People

(Reporter: jcarpenter0524, Assigned: dbaron)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
Future
PowerPC
macOS
css1, fonts, platform-parity, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P2][CSS1-5.2.5], URL)

Attachments

(6 attachments)

(Reporter)

Description

21 years ago
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)

Updated

21 years ago
Status: NEW → ASSIGNED

Updated

21 years ago
Assignee: peterl → kipp
Status: ASSIGNED → NEW

Updated

21 years ago
Assignee: kipp → peterl

Comment 1

21 years ago
Oops, wrong bug.
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

20 years ago
Setting all current Open/Normal to M4.

Updated

20 years ago
Assignee: peterl → michaelp
Target Milestone: M4 → M7

Comment 4

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

Updated

20 years ago
Assignee: michaelp → kmcclusk
Status: NEW → ASSIGNED
Target Milestone: M7 → M8
Target Milestone: M8 → M9
Summary: CSS font-weight: all font weights show as either normal or bold → {css1} CSS font-weight: all font weights show as either normal or bold
Target Milestone: M9 → M10
Moving to M10

Comment 6

20 years ago
*** Bug 10316 has been marked as a duplicate of this bug. ***
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.
Target Milestone: M10 → M11
Moving to M11
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.
Assignee: kmcclusk → ramiro
Status: ASSIGNED → NEW
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.

Updated

20 years ago
Assignee: ramiro → dcone

Comment 11

20 years ago
Reassigning to dcone.

dcone: when you are done, reassigning to pavlov@netscape.com for the linux work.

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
Target Milestone: M11 → M12
Should this be split into separate bugs by platform so it's easier to track?

Updated

20 years ago
Target Milestone: M12 → M13

Updated

20 years ago
Summary: {css1} CSS font-weight: all font weights show as either normal or bold → [FONT]{css1} CSS font-weight: all font weights show as either normal or bold

Updated

20 years ago
Target Milestone: M13 → M14
Keywords: css1
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...

Updated

19 years ago
Summary: [FONT]{css1} CSS font-weight: all font weights show as either normal or bold → [FONT MAC]{css1} CSS font-weight: all font weights show as either normal or bold

Updated

19 years ago
Summary: [FONT MAC]{css1} CSS font-weight: all font weights show as either normal or bold → [FONT MAC] CSS font-weight: all font weights show as either normal or bold

Updated

19 years ago
Target Milestone: M14 → M15
Keywords: fonts

Comment 14

19 years ago
> 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.) 

Updated

19 years ago
Target Milestone: M15 → M17

Updated

19 years ago
OS: Windows NT → Mac System 8.6
Hardware: PC → All
timeless@bemail.org:  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

19 years ago
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.
Target Milestone: M17 → Future

Updated

18 years ago
Keywords: mozilla0.9
OS: Mac System 8.6 → Windows NT
Hardware: All → PC
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...
QA Contact: chrisd → ian
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.
Keywords: mozilla0.9.3, pp, testcase
OS: Windows NT → Mac System 8.5
Hardware: PC → Macintosh
Whiteboard: [Hixie-P2]
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).
Whiteboard: [Hixie-P2] → [Hixie-P2][CSS1-5.2.5]

Comment 20

17 years ago
Any progress with this bug? 

Comment 21

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

Comment 22

17 years ago
cc'ing myself

Comment 23

17 years ago
See [http://developer.apple.com/fonts/TTQualSpec/QS09/FQS9.html] for what ATSUI
AAT can do for this with suitably enabled fonts.
Blocks: 105800
Depends on: 121540
Created attachment 98263 [details]
Test Case tailored for Jaguar default fonts
Created attachment 98264 [details]
Expected results on Jaguar for attachment 98263 [details]

Comment 26

16 years ago
Taking bug.
Assignee: dcone → sfraser
Status: ASSIGNED → NEW

Comment 27

16 years ago
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

16 years ago
Updating OS since support for mac classic is dead.
OS: Mac System 8.5 → MacOS X

Comment 29

16 years ago
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

16 years ago
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
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.
Created attachment 153943 [details]
testcase using arial

Comment 33

15 years ago
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

Updated

14 years ago
Assignee: sfraser_bugs → dbaron

Comment 34

13 years ago
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

12 years ago
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?
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

12 years ago
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.
The summary is:
"[FONT MAC] CSS font-weight: all font weights show as either normal or bold"
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.
(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?
(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.
(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]

Updated

12 years ago
Duplicate of this bug: 377004
Created attachment 261468 [details]
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.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 45

12 years ago
Created attachment 261585 [details]
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

12 years ago
Created attachment 261586 [details]
XHTML testcase demonstrating Skia AAT font weight variability on OS X

And here’s an XHTML testcase.

Updated

11 years ago
Blocks: 437355
You need to log in before you can comment on or make changes to this bug.