Roboto from materializecss weird font rendering in

Question

I'm using Materialize CSS coming with the Roboto 2.0 font. Font looks horrible in Chrome 43 and Firefox 37. Surprisingly with IE it looks very good (full resulution):

Same happens with other fonts like Lato and Open Sans and also on my work computer (same videocard and OS, if matters). Is there something wrong in my setup (Windows 7 x64 + NVIDIA GTX 780 1920x1080 display)?

Answer 1

In case anyone stumbles across this, it's a problem with the version of Roboto bundled with Materialize. A solution has been posted here https://stackoverflow.com/a/36803177/906360

Answer 2

It's font OS rendering issue. The simple solution is to use google font like:

<link href='http://fonts.googleapis.com/css?family=Roboto:400,700' rel='stylesheet' type='text/css'> 

Or the complex solution, but often the best, is to use @font-face with every type of file format for every browser.

@font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('webfont.woff2') format('woff2'), /* Super Modern Browsers */
       url('webfont.woff') format('woff'), /* Pretty Modern Browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
}

Answer 3

Nope, nothing wrong. There are a few things at play here that could impact how things are rendered.

The state of Web Fonts and @font-face is that browsers have varying support of various file types and those file types may render differently inside of the browser.

Commonly, you'll see these types:

• .eot
• .woff
• .woff2
• .svg
• .ttf

Browsers don't typically just support one of these types, they'll support a few and so the order in which they're listed in the @font-face rule determines which file type is used. To add to that, these files have varying sizes for the same fonts so that has to be considered.

Chrome in particular renders .woff poorly it seems and if you're linking directly to fonts.googleapis.com css to use web fonts you're at Google's discretion as far as which font is used/loaded and the service seems to prefer .woff/.woff2 for file size reasons.

You can read a lot more about this in detail at places like CSS Tricks, MDN, and other Blogs. Using custom web fonts still isn't as easy as it should be but services like TypeKit help with some of the heavy lifting.

Now all that is just dealing with varying file types for fonts. There are still plenty of CSS properties that can impact how a particular font displays in a browser, both vendor specific and general use.

Finally, we can't take the Operating System out of the equation, as operating systems have their own Font rendering engines. Here's a good article from TypeKit about some of those differences.

TL;DR - No, it's not likely your Graphics Card (although that can obviously play a part in it). It's most likely the font file type being used in the browser. Seems that opting for .woff2 then falling back to .eot (IE) and .ttf will produce better quality than .woff or .svg.

Hope that helps!

Answer 4

Have you tried specifying font smoothing/rendering?
It generally makes a big difference in my experience.

body {
  /* Better Font Rendering */
  text-rendering: optimizeLegibility;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}