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)
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)
Updated•26 years ago
|
Status: NEW → ASSIGNED
Updated•26 years ago
|
Assignee: peterl → kipp
Status: ASSIGNED → NEW
Updated•26 years ago
|
Assignee: kipp → peterl
Comment 1•26 years ago
|
||
Oops, wrong bug.
Assignee | ||
Comment 2•26 years ago
|
||
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
Updated•26 years ago
|
Assignee: peterl → michaelp
Target Milestone: M4 → M7
Comment 4•26 years ago
|
||
This is really an issue with the font code. Who's handling that these days?
Updated•26 years ago
|
Status: NEW → ASSIGNED
Updated•26 years ago
|
Target Milestone: M7 → M8
Updated•26 years ago
|
Target Milestone: M8 → M9
Updated•26 years ago
|
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
Updated•26 years ago
|
Target Milestone: M9 → M10
Comment 5•26 years ago
|
||
Moving to M10
Assignee | ||
Comment 7•26 years ago
|
||
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.
Updated•26 years ago
|
Target Milestone: M10 → M11
Comment 8•26 years ago
|
||
Moving to M11
Comment 9•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: kmcclusk → ramiro
Status: ASSIGNED → NEW
Comment 10•25 years ago
|
||
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•25 years ago
|
Assignee: ramiro → dcone
Comment 11•25 years ago
|
||
Reassigning to dcone.
dcone: when you are done, reassigning to pavlov@netscape.com for the linux work.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
Target Milestone: M11 → M12
Assignee | ||
Comment 12•25 years ago
|
||
Should this be split into separate bugs by platform so it's easier to track?
Updated•25 years ago
|
Target Milestone: M12 → M13
Updated•25 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•25 years ago
|
Target Milestone: M13 → M14
Comment 13•25 years ago
|
||
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•25 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•25 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•25 years ago
|
Target Milestone: M14 → M15
Comment 14•25 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•25 years ago
|
Target Milestone: M15 → M17
Assignee | ||
Comment 15•25 years ago
|
||
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•25 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•24 years ago
|
Comment 17•24 years ago
|
||
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
Comment 18•24 years ago
|
||
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]
Comment 19•24 years ago
|
||
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).
Updated•23 years ago
|
Whiteboard: [Hixie-P2] → [Hixie-P2][CSS1-5.2.5]
Comment 20•23 years ago
|
||
Any progress with this bug?
Comment 21•23 years ago
|
||
ATSUI (see bug 121540) provides some enhanced font weight functionality.
Comment 22•23 years ago
|
||
cc'ing myself
Comment 23•23 years ago
|
||
See [http://developer.apple.com/fonts/TTQualSpec/QS09/FQS9.html] for what ATSUI
AAT can do for this with suitably enabled fonts.
Comment 27•22 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•22 years ago
|
||
Updating OS since support for mac classic is dead.
OS: Mac System 8.5 → MacOS X
Comment 29•21 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•21 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
Comment 31•21 years ago
|
||
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•21 years ago
|
||
Comment 33•21 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•20 years ago
|
Assignee: sfraser_bugs → dbaron
Comment 34•19 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•18 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?
Assignee | ||
Comment 36•18 years ago
|
||
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•18 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.
Assignee | ||
Comment 38•18 years ago
|
||
The summary is:
"[FONT MAC] CSS font-weight: all font weights show as either normal or bold"
Comment 39•18 years ago
|
||
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?
Assignee | ||
Comment 41•18 years ago
|
||
(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•18 years ago
|
||
(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•18 years ago
|
||
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.
Updated•18 years ago
|
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 45•18 years ago
|
||
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•18 years ago
|
||
And here’s an XHTML testcase.
You need to log in
before you can comment on or make changes to this bug.
Description
•