Google webfonts render choppy in Chrome on Windows
Asked Answered
B

12

52

I use the Google Webfonts service on my website and rely heavily on it. It renders fine on most browsers, but in Chrome on Windows it renders especially bad. Very choppy and pixelated.

What i have found out so far is that Chrome requires the .svg format font to be loaded first. The font i am using however, called Asap, was only available in .woff. I converted it to .svg using a free online service, but when i added that to my stylesheet (before the .woff), it didn't change anything.

I've also tried:

-webkit-font-smoothing: antialiased;
text-shadow: 0px 0px 0px;

Hoping that either would help the text render more smoothly.

Right now i've run out of ideas and i would hate to change fonts. Does anyone have an idea how i can solve this problem? I've been using the Adobe Browserlab to test the rendering, seeing as how i only own a mac. The link to the site is: www.symvoli.nl/about

Thanks in advance!

Edit April 11th, 2013:

Chrome 35 Beta seems to have finally solved this issue:

enter image description here

Benz answered 8/6, 2012 at 16:59 Comment(5)
Oh wow, thanks for bringing this up, I never noticed it before. Google webfonts are looking really choppy on my own sites as well.Statehood
Is it just Google webfonts that exhibit this issue? Or all @font-face fonts?Celina
I made a detailed blog post about this incl. fixes: How to fix the ugly font rendering in Google Chrome and this has also been asked here: https://mcmap.net/q/48618/-is-there-any-quot-font-smoothing-quot-in-google-chrome/1114320Trimetallic
what Chrome 35? It's April 4, 2014 and I still have latest 34. I'm confused.Lilybelle
Chrome 35 Beta, that is. thenextweb.com/google/2014/04/10/…Benz
E
66

Update August 2014

Google finally fixes this issue in Chrome 37 natively!!!. But for historical reasons I won't delete this answer.

Problem

The issue is created because chrome actually cannot render TrueType fonts with correct anti-aliasing. However, chrome still renders SVG files well. If you move the call for your svg file up in your syntax above the woff, chrome will download the svg and use it instead of the woff file. Some tricks like you propose work well, but only on certain font sizes.

But this bug is very well known to the Chrome developer team, and has been in fixing since July 2012. See the official bug report thread here: https://code.google.com/p/chromium/issues/detail?id=137692

Update Oct 2013 (Thanks to @Catch22)

Apparently some websites may experience intermittent spacing issues when rendering the svg. So there is a better way to skin it. If you call the svg with a media query specific to Chrome, the spacing issues disappear:

@media screen and (-webkit-min-device-pixel-ratio:0) {
  @font-face {
      font-family: 'MyWebFont';
      src: url('webfont.svg#svgFontName') format('svg');
  }
}

First approach solution:

The Fontspring bulletproof syntax modified to serve the svg first:

@font-face {
    font-family: 'MyWebFont';
    src: url('webfont.eot'); 
    src: url('webfont.eot?#iefix') format('embedded-opentype'),
         url('webfont.svg#svgFontName') format('svg'),
         url('webfont.woff') format('woff'),
         url('webfont.ttf')  format('truetype');
}

Further reading:

Exclaim answered 22/11, 2012 at 8:45 Comment(8)
It's a shame this is still an issue (last update Apr 24, 2013) code.google.com/p/chromium/issues/detail?id=137692#c104Corrigendum
I actually didn't have to modify the Fontsquirrel/Fontspring bulletproof syntax – I just used it as is and it fixed the rendering problem.Invalidity
Where to get SVG-files if only TTFs are available?Deepset
why then if you call from googles cdn (which is faster and a better practice ) do they send the true type before the svg. Bad googleSwatch
The Fontspring blog post has been updated to suggest using a Chrome specific media query to avoid some spacing issues when using SVG - fontspring.com/blog/smoother-rendering-in-chrome-updateArlettearley
This answer should be removed as Chrome no longer supports SVG Fonts!Santossantosdumont
@sidonaldson: I updated the answer, but there is no reason to remove the answer, even now when the issue is solvedExclaim
@TomSarduy sorry, I didn't actually mean deleted!Santossantosdumont
P
18
-webkit-text-stroke: 0.5px;

use it only on large text, since it will affect your page performance.

Possible answered 7/10, 2012 at 13:57 Comment(1)
How does this look on non-Windows Chrome?Zipangu
P
8

A fix has been suggested here by calling the .svg file first, http://www.adtrak.co.uk/blog/font-face-chrome-rendering/

Passe answered 31/10, 2012 at 11:50 Comment(0)
J
4

I've tried a number of solutions and finally came up with one that works with newer versions of Chrome which don't fall for changing the order of the files:

Essentially, I moved the TTF file into a Mozilla specific section.

@font-face {
    font-family: 'MyWebFont';
    src: url('webfont.eot'); 
    src: url('webfont.eot?#iefix') format('embedded-opentype'),
         url('webfont.svg#svgFontName') format('svg'),
         url('webfont.woff') format('woff');
}
@-moz-font-face {
    font-family: 'MyWebFont';    
    src: url('webfont.ttf')  format('truetype');
}
Jaworski answered 21/6, 2013 at 14:37 Comment(0)
D
2

Answer by Tom & font-spring didn't do it for me for some reason. This fix by Sam Goddard did though :

After experimenting myself, I stumbled across what appears to be a decent, very easy fix for this issue. It appears that Chrome utilises the .svg file in the @font-face kit, and doesn’t like being called last. Below is the standard call for @font-face using CSS:

// font-face inclusion
@font-face {
  font-family: 'font-name';
                src: url('path-to-font/font-name.eot');
                src: url('path-to-font/font-name.eot?#iefix') format('eot'),
                url('path-to-font/font-name.woff') format('woff'),
                url('path-to-font/font-name.ttf') format('truetype'),
                url('path-to-font/font-name.svg') format('svg');
  font-weight: normal;
  font-style: normal;
}

As can be seen in the example, the .svg file comes last in the list of called URLs. If we amend the code to target webkit browsers, then tell them to solely utilize the .svg file.

// Usage
@media screen and (-webkit-min-device-pixel-ratio:0) {
  @font-face {
    font-family: ‘font-name';
    src: url(‘path-to-font/font-name.svg’) format(‘svg’);
    }
}
Disappointment answered 2/10, 2013 at 22:1 Comment(1)
It is preferable to add the relevant example, or information, rather than simply supply a link. Should the link ever go dead; you're left with an answer that has no substance.Facetious
W
1

It could just be the font your using "asap" doesn't render all that well at certain sizes. I changed the size of your h1 from 3.5em to 50px and it looks a little better. May not be the perfect solution but I have noticed that a lot of google webfonts can be unpredictable

Whatever answered 8/6, 2012 at 17:16 Comment(2)
But this unfortunately doesn't explain why it does render perfectly in OS X based browsers and, to my own surprise, Internet Explorer. But if anything, i will definitely look into this solution to at least try to smooth it out a littleBenz
Google Chrome uses anti-aliasing but the text looks more pixelated than in other browsers because it only supports horizontal anti-aliasing.Whatever
B
0

I develop in Firefox. My experience is that FF displays ttf fonts very well without any extra rules (beyond the @font-face calling the url for the font file). Chrome, however, is a different story. Even with with the -webkit-font-smoothing: antialiased; rule it still displays any font quite raggedly. Safari doesn't seem to have that problem, so it's not inherently Webkit that can't render a font cleanly, it's a Chrome problem.

I haven't tried adding the -webkit-text-stroke: 0.5px; rule, but will.

Of the answers above I really like Tom Sarduy's answer best. Aside from a good description of the problem, he gives a great @font-face stack to use to cover all the major browsers.

Boxthorn answered 24/3, 2013 at 22:17 Comment(0)
I
0

Another link reference for web font rendering in chrome -

http://www.fontspring.com/blog/smoother-web-font-rendering-chrome

Inefficiency answered 9/5, 2013 at 23:12 Comment(0)
Q
0

Had the same thing guys. Good in all browsers except chrome - even IE10 and 9 were fine. Dreamwaeevr CS6 also uses a similar version of fontsprings code, but has the svg at the end. Change it round for SVG before woff and ttf and all in the world is good. Tom is bang on with hos example there, in fact past that into your code and map paths to the fonts you need, and you're in business!

Quenby answered 17/6, 2013 at 15:54 Comment(0)
S
0

It seems that Google might serve different woff files depending on the browser and OS.

I found that if I download the font from IE, it's about 10k bigger than if done on Safari from the Mac for a particular font. 43k vs 33k. Also, the IE version seems to look fine on the Mac, but the Mac version doesn't seem to work fine on the PC. The Mac version looks the worst in Mozilla Firefox on the PC.

Try this: http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,600,400italic,600italic

SourceSansPro-Regular.woff PC version 27k

SourceSansPro-Regular.woff Apple version 24k

Smirk answered 30/7, 2014 at 21:58 Comment(0)
C
0

i have tried many ways: -loading the svg with font-face -webkit-font-smoothening ...

after

-webkit-transform: rotate(-4.7deg) translate3d( 0, 0, 0);

the rotating was smoother but the main problem hasnt gone.

For me the solution was adding:

-webkit-text-stroke: 0.5px;
Clinometer answered 2/9, 2014 at 7:15 Comment(0)
M
0

https://www.gettingthingstech.com/how-to-fix-jagged-font-rendering-in-google-chrome/

This post explains a little about google chromes experimental functions. Apparently enabling the "DisableWrite" option fixes the jagged fonts. This is obviously a fix PER machine and not on a full scale.

Millham answered 31/3, 2015 at 22:16 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.