Closed Bug 972 Opened 26 years ago Closed 18 years ago

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

Categories

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

PowerPC
macOS
defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: jcarpenter0524, Assigned: dbaron)

References

()

Details

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

Attachments

(6 files)

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)
Status: NEW → ASSIGNED
Assignee: peterl → kipp
Status: ASSIGNED → NEW
Assignee: kipp → peterl
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
Setting all current Open/Normal to M4.
Assignee: peterl → michaelp
Target Milestone: M4 → M7
This is really an issue with the font code. Who's handling that these days?
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
*** 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.
Assignee: ramiro → dcone
Reassigning to dcone. dcone: when you are done, reassigning to pavlov@netscape.com for the linux work.
Status: NEW → ASSIGNED
Target Milestone: M11 → M12
Should this be split into separate bugs by platform so it's easier to track?
Target Milestone: M12 → M13
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
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...
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
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
Target Milestone: M14 → M15
Keywords: fonts
> 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.)
Target Milestone: M15 → M17
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.
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
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.
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]
Any progress with this bug?
ATSUI (see bug 121540) provides some enhanced font weight functionality.
cc'ing myself
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: atsui
Taking bug.
Assignee: dcone → sfraser
Status: ASSIGNED → NEW
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).
Updating OS since support for mac classic is dead.
OS: Mac System 8.5 → MacOS X
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
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.
Attached file testcase using arial (deleted) —
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
Assignee: sfraser_bugs → dbaron
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
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.
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]
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
Closed: 18 years ago
Resolution: --- → FIXED
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.
And here’s an XHTML testcase.
Blocks: 437355
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: