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)?
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!
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;
}
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 */
}
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
Related
I want to use a font for my website, I got the overall research and found variety of formats for fonts, Now i want to know that what is the standard format?
Or What are the standard formats?
.TTF (True Type Font)
.EOT (Embedded OpenType)
.OTF (open type font)
.SVG (Scalable Vector Graphics)
.WOFF (Web Open Font Format)
So far, I've used all of these formats, something like this:
#font-face {
font-family: 'Font';
src: url('Font.eot'); /* IE9 Compat Modes */
src: url('Font.eot?#') format('eot'), /* IE6–8 */
url('Font.ttf') format('truetype'), /* Saf3—5, Chrome4+, FF3.5, Opera 10+ */
url('Font.woff') format('woff'), /* FF3.6+, IE9, Chrome6+, Saf5.1+*/
url('Font.otf') format('opentype'),
url('Font.svg') format('svg');
}
But in this case, the site is too heavy (size of all formats is almost 1MB) , So what should i do to be more optimized ?
Understanding Font File Types
WOFF / WOFF2
WOFF fonts often load faster than other formats because they use a compressed version of the structure used by OpenType (OTF) and TrueType (TTF) fonts.
SVG / SVGZ
ideal for mobile use
EOT
supported only by IE
OTF / TTF
The WOFF format was initially created as a reaction to OTF and TTF, in part, because these formats could easily (and illegally) be copied
ON THE OTHER SIDE:
Google Fonts offers this as a way to use their fonts.
SOME PERFORMANCE TIPS
Watch the file size
Fonts can be surprisingly heavy, so lean towards options that offer lighter versions. For example, favor a font set that is 50KB versus one that weighs 400KB.
Limit the character set, if possible
Do you really need the bold and black weights for one font? Limiting your font sets to load only what is used is a good idea and there are some good tips on that here.
Consider system fonts for small screens
Many devices are stuck on crappy connections. One trick might be to target larger screens when loading the custom font using #media.
In this example, screens smaller than 1000px will be served a system font instead and screens that wide and above will be served the custom font.
CONCLUSION:
Use OTF/TTF(all browsers) & EOT(I.E) for Desktop screens and use system fonts for small screens as they render faster.
And do consider google fonts. Best choice so far.
I just tested chrome (43) and firefox (37) and ie (10) - in all cases only one font format (respectively: woff, woff and eot) of the five was downloaded. Based on that small sampling, it seems* that including the various file types in your #font-face declaration doesn't have a negative impact on the user.
*If you happen to know how other browsers behave, let us know.
I got this weird result when using Lato font in Internet Explorer 8 (it looks fine in current Chrome and Firefox). The problem is missing horizontal strokes on letters. Screen below:
The problem is visible only when using font-size 13px and few other smaller ones (e.g. 11px).
I use official webfonts files from Lato's site (http://www.latofonts.com/) and CSS #font-face syntax (below I include only one declaration for regular font):
#font-face {
font-family: "Lato";
font-style: normal;
font-weight: normal;
src: url("lato/LatoLatin-Regular.eot"); /* IE9 Compat Modes */
src: url('lato/LatoLatin-Regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
url("lato/LatoLatin-Regular.woff") format("woff"), /* Modern Browsers */
url("lato/LatoLatin-Regular.ttf") format("truetype"); /* Safari, Android, iOS */
}
Suprisingly it works alright in IE8 when linking to Google Fonts version instead by including:
<link href='http://fonts.googleapis.com/css?family=Lato:400,700,400italic' rel='stylesheet' type='text/css'>
The result becomes:
What's the reason of this problem? Is there a way to fix it? Why does Google Fonts render differently than official webfont files? In what ways does Google process the original fonts?
I have the same problem, but due to my webpage viewers I found out, that different browsers (like FF) on different computers are showing missing horizontal strokes. The error might be connected with the fact, that the creator of the font just published 2.0 version. Google still has previous one. They are changing it, although latin characters aren't available by another error (see the discussion bellow on http://www.latofonts.com/lato-free-fonts/ ).
Paul Irish suggests that the 'bullet proof' way to load fonts is to render EOT first, followed by WOFF, TTF, and lastly SVG.
#font-face {
font-family: 'Tagesschrift';
src: url('tagesschrift.eot'); /* IE 5-8 */
src: local('☺'), /* sneakily trick IE */
url('tagesschrift.woff') format('woff'), /* FF 3.6, Chrome 5, IE9 */
url('tagesschrift.ttf') format('truetype'), /* Opera, Safari */
url('tagesschrift.svg#font') format('svg'); /* iOS */
}
Source: http://www.html5rocks.com/en/tutorials/webfonts/quick/
However, he doesn't explain why this is the correct order (I assume performance). Can anyone elaborate? Also, what are the quality differences? E.g. SVG appears to produce better scaling/antialiasing in Chrome.
There is no “correct order”, and it’s not a loading order but a list from which each browser is expected to pick up one font resource to load – namely this first one they support (and it works that way).
EOT comes first because it is the only one that old versions of IE support, but its position is really not important.
WOFF is generally said to the optimal for web fonts. Whether that is true may depend on opinions, rendering routines, and fonts, but it’s anyway the conventional wisdom behind the order
TTF and SVG are listed last because some browsers support only such formats. If they were placed earlier, those formats might get used by some browsers that support WOFF as well.
All other browsers - FF, Chrome, Safari, Opera and IE9 - works fine.
But in IE8 it wont load the #font-face font - but if you navigate to another page and then return, the font renders/loads fine.
See image:
Top: Text as seen once you navigate to another page, Bottom: as seen when the site first loads
CSS code:
#font-face {
font-family: 'FontNameHere';
src: url('/font/webfont.eot');
src: local('?'), url('/font/webfont.woff') format('woff'),
url('/font/webfont.ttf') format('truetype'),
url('/font/webfont.svg#webfontkKNhbsUZ') format('svg');
}
Thanks in advance.
Internet Explorer 9+, Firefox, Chrome, Safari, and Opera support the WOFF (Web Open Font Format) font.
Firefox, Chrome, Safari, and Opera support fonts of type TTF (True Type Fonts) and OTF (OpenType Fonts).
Chrome, Safari and Opera also support SVG fonts/shapes.
Internet Explorer also supports EOT (Embedded OpenType) fonts.
Note: Internet Explorer 8 and earlier versions, do not support the #font-face rule.
however,
IE8′s relationship with web fonts is a bit more complex than “it doesn’t support it”. It does actually support them, but in a way that makes using them a pain.
There are five types of web font formats:
Embedded Open Type (EOT)
TrueType (TTF)
OpenType (OTF)
Scalable Vector Graphics (SVG)
Web Open Font Format (WOFF)
Of the bunch, WOFF is going to become the standard. It’s supported by Chrome, Firefox (since 3.6), Opera, Safari, and IE9.
Of course IE8 knows nothing about WOFF and instead exclusively supports EOT (to be fair, this is largely because IE8 preceded WOFF). This means that to use a web font which can be displayed in both IE8 and other browsers, you have to supply EOT and WOFF formats.
To make matters worse, IE8 has a bug which prevents it from loading more than one format for the same font. Fortunately, there is a hack you can use.
Anyway, here’s the cross-browser CSS for #font-face
#font-face {
font-family: 'OpenSans';
src: url('fonts/OpenSans-Light-webfont.eot');
src: url('fonts/OpenSans-Light-webfont.eot?#iefix') format('embedded-opentype'),
url('fonts/OpenSans-Light-webfont.woff') format('woff'),
url('fonts/OpenSans-Light-webfont.ttf') format('truetype'),
url('fonts/OpenSans-Light-webfont.svg#OpenSansLight') format('svg');
font-weight: 300;
font-style: normal;
}
In this example, I’m using a font called Open Sans and its multiple formats (EOT, WOFF, TTF, and SVG) which are stored in the “fonts” folder on my site.
If you’re wondering why I included the SVG format, the answer is because mobile Safari (iPhone/iPad) supported only this format until version 4.1.
I know this is an old question, but it comes up quite high on Google searches so I thought there might be some value in adding an answer here...
I have not yet come to a definitive answer, but I was unable to find others suffering the same symptom you're describing.
Generally, with IE8, webfonts either work or they don't -- but I was having them not load on some page loads (usually but not always the first), and seeing them sporadically not load from page to page on a site I'm working on.
I use a separate development server and this problem only occurs there, not on production!
I haven't yet figured out why this is the case. My first instinct was MIME types for EOT fonts, so I added one on my dev server. That didn't fix it. I haven't had time to fully diagnose, and since production is more important and I'm quite busy I probably won't be able to dig in any further for a bit - but perhaps someone will see this at the top of some google results and it'll be a catalyst for them to figure out the issue...
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:
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:
CSS properties that affect type rendering
Smoother Web Font Rendering in Chrome for Windows
How to Bulletproof #font-face Web Fonts
-webkit-text-stroke: 0.5px;
use it only on large text, since it will affect your page performance.
A fix has been suggested here by calling the .svg file first, http://www.adtrak.co.uk/blog/font-face-chrome-rendering/
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');
}
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’);
}
}
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
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.
Another link reference for web font rendering in chrome -
http://www.fontspring.com/blog/smoother-web-font-rendering-chrome
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!
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
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;
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.