New issue
Advanced search Search tips

Issue 31833 link

Starred by 11 users

Issue metadata

Status: Fixed
Closed: Sep 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

font-weight CSS property ignored if using @font-face which doesn't specify a bold-face version

Reported by, Jan 8 2010

Issue description

Chrome Version       : unstable
URLs (if applicable) :
Other browsers tested:
     Safari 4: ?
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

I have a <h3> element which is styled with font-weight:bold; but it is not 
being displayed as bold in Chrome (v Linux) whereas it is fine 
in IE and Firefox. The text uses a font called "GriffosFont" via @font-

What steps will reproduce the problem?
1. Open in both Chrome and Firefox 
(side by side).
2. Find the "Ten Stages of the GIPF Process" h3 element.
3. Notice it is bold in Firefox but not in Chrome.

Alternative way to reproduce:
 1. Go to and download the 
@font-face Kit.
 1. Once downloaded, open up demo.html in Chrome and in a text editor.
 1. Add <strong> tags in some of the demo text in the text editor.
 1. Notice how the text does not go bold when viewed in Chrome.

What is the expected result?

I expect the text to be displayed as bold. Even though the GriffosFont font 
does not have a bold-face version, Gecko manages to use thickened strokes 
to render a pseudo-bold, whereas in Chrome, whatever value I set the font-
weight, the text renders as normal, not bold.

What happens instead?

font displayed as normal weight (instead of bold).

Please provide any additional information below. Attach a screenshot if

Screenshots attached.

252 KB View Download
234 KB View Download

Comment 1 Deleted

Comment 2 Deleted

Note: I first raised this issue on doctype:

Someone there, confirmed that the problem does occur on Safari (4.0).
Note: Chrome manages to "enbolden" the font if you add the "font-variant:small-caps" 
attribute. This proves the necessary functionality is available but not utilised 

Bug still present after update to version unstable.
Bug still present after update to version 5.0.307.5 dev
Labels: -Area-Undefined Area-WebKit OS-All
Status: Assigned
Thanks for the report. I've confirmed the issue.

BTW, Firefox 3.5.6 for Windows on Windows XP SP3 seems not to support to enbold @font-
face fonts.

Related two WebKit issues:

 Bug 21466  - defining bold @font-face before normal font weight @font-face 'looses' bold @font-face (Esp. comment #4)

>Webkit doesn't imply following values if left out of the @font-face declaration:
>It should! (Gecko does, and it saves typing/moving declarations around.)

 Bug 34147  - [Qt or Gtk?] If @font-face does not provide an explicit italic/bold variant, regular is used

Thanks for taking a look.

> BTW, Firefox 3.5.6 for Windows on Windows XP SP3 seems not to support to enbold 
@font-face fonts.
I tested Firefox 3.0.15 on Windows Vista and it renders my test page ok

I tested Chrome version on Windows and version 5.0.307.5 dev on Linux and 
the issue occurs.

As a note: I initially thought of this issue as a "feature" rather than a bug but the 
reason I eventually decided it was a bug was that Chrome can make my font bold if it 
is styled as "font-variant:small-caps". So I decided, that Chrome is capable of doing 
bold with this font but it is not doing it in all situations.
I'll check in depth if we can or should fix WebKit to address the issue you reported, but I think there's a workaround.
For a regular font, please add "font-weight: normal;" and "font-style: normal;" properties to your @font-face rule explicitly like this:

<style type="text/css">
@font-face {
     font-family: "A";
     font-weight: normal;
     font-style: normal;
     src: url("http://HOST.NAME/PATH/TO/GriffosFont.ttf");
.test {
     font-family: 'A';
<strong><p class="test">abcde</p></strong>
<i><p class="test">abcde</p></i>
<strong><i><p class="test">abcde</p></i></strong>
<p class="test">abcde</p>

Then Chromium can apply synthetic bold and/or italic transformations to the regular font (see the screen shot).

If you see blurred synthetic bold text on Linux, please check  issue 22360 . That will be fixed in the next dev channel release:

30.7 KB View Download
That is absolutely fantastic info, thanks for the workaround - I have applied it and 
can confirm that it fixes my issue in Safari and Chrome in Windows. Thanks also for 
the heads up about  issue 22360  for Linux.
Much appreciated,
Thanks for the quick confirmation! Just one more comment:

> I tested Firefox 3.0.15 on Windows Vista and it renders my test page ok

I think it's because Firefox 3.0 does not support @font-face... Please try 3.5 or newer.

I upgraded to Firefox 3.6 on Windows Vista and it continued to render my test page ok 
with and without the explicitly defined @font-face properties workaround.
I see. That's great.

For my own reference:

- When we use "font-weight: normal;" in a @font-face, WebKit treat it as 400.
- When we use "font-weight: lighter;" in a @font-face, WebKit treat it as 200.
- When we use "font-weight: bold;" or bolder in a @font-face, WebKit treat it as 700.
- When we don't specify font-weight: in a @font-face, WebKit treat it as 100|200|300|400|...|900 (!!!). Not 400.
- If the weight of a font is <= 500 AND a requested font weight is >= 600, WebKit tries to synthesize a bold font.

For my own reference, part 2...

> - When we don't specify font-weight: in a @font-face, WebKit treat it as 100|200|300|400|...|900 (!!!). Not 400.

It turned out that the 100|...|900 mask is necessary for handling this case:
Without the mask, <i>...</i> text will be displayed in Times, not Arial.

Status: Started
 Issue 35739  has been merged into this issue.
A quick note to say that the latest development version of Chrome (5.0.322.2-r38810)  
has sorted out the rendering problem for Linux ( issue 22360 ) and so as long as I use 
the explicit font-weight workaround, the reason I opened this ticket is now a non-
My thanks to the Chrome team.

Comment 20 by, Feb 16 2010

Labels: Mstone-X kglater

Comment 21 by Deleted ...@, Nov 27 2010

You can solve the problem also using a free tool like this->
for generate a right @font-face
Owner: ----
Status: Available

Comment 24 by, Sep 16 2011

WebKit now treats font-weight as 400 when we don't specify it so is this problem no longer exist? If so, I'd like to close this issue.
Yes, I confirm this issue is fixed and I'm no longer suffering from it. Thanks very much for all your hard work you smashing developers ;)

Please close this issue (I had a look to do it myself but couldn't see how).

Comment 26 by, Sep 26 2011

Status: Fixed
Thank you for confirmation. Closing the bug as fixed.
Project Member

Comment 27 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 28 by, Mar 11 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 29 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment