Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 31833 font-weight CSS property ignored if using @font-face which doesn't specify a bold-face version
Starred by 11 users Reported by thomasfo...@gmail.com, Jan 8 2010 Back to list
Status: Fixed
Owner:
Closed: Sep 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
Chrome Version       : 4.0.288.1 unstable
URLs (if applicable) : http://gipf.bitvolution.com/how-it-works
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 4.0.249.43 Linux) whereas it is fine 
in IE and Firefox. The text uses a font called "GriffosFont" via @font-
face.

What steps will reproduce the problem?
1. Open http://gipf.bitvolution.com/how-it-works 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 http://www.fontsquirrel.com/fonts/GriffosFont 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
possible.

Screenshots attached.

 
Chrome_v4_0_288_1.png
252 KB View Download
Firefox_v3_5_6.png
234 KB View Download
Comment 1 Deleted
Comment 2 Deleted
Note: I first raised this issue on doctype: 
http://doctype.com/font-showing-bold-only-chromesafari

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 
consistently.

Bug still present after update to version 4.0.295.0 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
https://bugs.webkit.org/show_bug.cgi?id=21466 (Esp. comment #4)

>Webkit doesn't imply following values if left out of the @font-face declaration:
>font-weight:normal;
>font-style:normal;
>font-variant:normal;
>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 
https://bugs.webkit.org/show_bug.cgi?id=34147

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
http://gipf.bitvolution.com/how-it-works

I tested Chrome version 4.0.249.78 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.
thomasfotherby,
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:

<html><head>
<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';
}
</style></head>
<body><div>
<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>
<p>abcde</p>
</div></body></html>

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: http://code.google.com/p/chromium/issues/detail?id=22360

font_face_synthetic.png
30.7 KB View Download
yusukes,
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,
Tom
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.

http://trac.webkit.org/browser/trunk/WebCore/css/CSSSegmentedFontFace.cpp#L111
http://trac.webkit.org/browser/trunk/WebCore/css/CSSFontSelector.cpp#L196

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: https://bugs.webkit.org/show_bug.cgi?id=16348
Without the mask, https://bugs.webkit.org/attachment.cgi?id=28455&action=prettypatch <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-
issue.
My thanks to the Chrome team.
Comment 20 by karen@chromium.org, 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->
http://www.fontsquirrel.com/fontface/generator
for generate a right @font-face
Cc: bashi@chromium.org
Cc: yusukes@chromium.org
Owner: ----
Status: Available
Comment 24 by bashi@chromium.org, Sep 16 2011
Owner: bashi@chromium.org
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 bashi@chromium.org, Sep 26 2011
Status: Fixed
Thank you for confirmation. Closing the bug as fixed.
Project Member Comment 27 by bugdroid1@chromium.org, 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 bugdroid1@chromium.org, Mar 11 2013
Labels: -Area-WebKit Cr-Content
Project Member Comment 29 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment