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...
Related
I thought that the font squirrel webfont generator was used to make a font compatible for all the browsers. But I tried the classic
#font-face {
font-family: myFirstFont;
src: url(sansation_light.woff);
}
and it works for all the latest versions of the browsers Google Chrome, Mozilla Firefox, Opera, Microsoft Edge and even Internet Explorer... Is it used for older versions of the above? Thanks
The reason webfont generators continue to generate old fonts is because they follow the principle of "If it's not broken, why remove it?".
For example, EOT is is a font format that still occasionally shows up in font generators, despite being completely unnecessary in modern day. It supports Internet Explorer 6+.... and if you REALLY need to support a browser that's 20 years old, Font Squirrel can help with that.
...But in the modern day, you only need WOFF and WOFF2. The other font flavors are obsolete and unnecessary because all modern browsers can use .woff , and most can use .woff2 .
You can see compatibility here:
WOFF: https://caniuse.com/woff
WOFF2: https://caniuse.com/woff2
EOT: https://caniuse.com/eot
TTF/OTF: https://caniuse.com/ttf
As you said, the solution provided by Font Squirrel works great for all modern browsers.
However, if you need to target older versions I would recommend https://onlinefontconverter.com that generate a more complete #font-face css, also more font extensions are provided.
I use the following css when I need #font-face:
#font-face{
font-family:"Rage Italic";
src:url("../fonts/RageItalic.eot");
src:local("RageItalic"), local("RageItalic"), url("../fonts/RageItalic.woff") format("woff"), url("../fonts/RageItalic.ttf") format("truetype"), url("../fonts/RageItalic.svg#RageItalic") format("svg");
font-weight: normal;
font-style: normal;
}
I should use the font family Nunito [»] from the Google font library.
Due to some improvements such as site speed performance and concerns like independence, I need to run this technology locally.
<link href="https://fonts.googleapis.com/css2?family=Nunito" rel="stylesheet">
I used this tool for this: google-webfonts-helper [»]
My minimum browser support (Modern Browsers) will be IE9+. In this case, when I select that option from the tool, it gives the following #font-face block.
/* nunito-regular - latin-ext_latin_cyrillic */
#font-face {
font-family: 'Nunito';
font-style: normal;
font-weight: 400;
src: local('Nunito Regular'), local('Nunito-Regular'),
url('../fonts/nunito-v12-latin-ext_latin_cyrillic-regular.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
url('../fonts/nunito-v12-latin-ext_latin_cyrillic-regular.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}
Since the opening speed of the project was our primary goal, some questions were kept in mind.
As you can see, this code tries to load both woff and woff2 fonts.
The thing that comes to my mind is that since I included woff, why should I try to include woff2?
Wouldn't it be enough to include the woff type font set for all modern browsers (IE9+)?
Finally, I learned that IOS operating system based devices use ttf type font. As a matter of fact, when I use only woff, what is my minimum IOS support?
woff2 is the modern "standard font" and is supported on modern browsers. Woff2 is a more compressed font, so the woff2 files are smaller then the woff files. To support modern and some older browsers, both the woff2 and woff files has to be there. The priority is to ask if the font is present on the device, if not then present Woff2, and if woff2 fails, load the woff font.
If you look at the performance, the woff2 is the best choice. The woff is a fallback for older browsers.
Note that not both woff2 and woff are loaded. If woff2 is supported, the browser will only load woff2. On the other hand, if woff2 is not supported, then only the woff is loaded. Presenting both is the best option.
WOFF2 : modern browsers
WOFF : fallback if woff2 is not supported
TTF : Android-browser on Android 4.3 or older
EOT : Internet Explorer 8 or older
SVG : iOS-Safari 3.2-4.1. SVG webfonts are not supported anymore in most browsers
Note that svg files are huge files and bad practice if you're working on performance optimization.
So for best performance, and for very good cross browser presentation, woff2 and woff are enough. Your css looks fine, first check local, then try woff2 and then, if woff2 fails, a fallback to woff.
RE: your comment
To test the performance, I uploaded a Bootstrap page with Font-Awsome and Open-Sans. These webfont files are located in a subfolder on my domain. Each font has this priority:
src: local('Open Sans Italic'),
local('OpenSans-Italic'),
url('../webfonts/OpenSans/OpenSans-Italic.woff2') format('woff2'),
url('../webfonts/OpenSans/OpenSans-Italic.woff') format('woff'),
url('../webfonts/OpenSans/OpenSans-Italic.ttf') format('truetype');
The waterfall diagram shows that from each webfont only the woff2 is loaded. If you do not have to support the old 'Android-browser' on Android 4.3 or older then remove the TTF line from this css example.
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
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.
I am trying to understand why Font Awesome comes with various font formats and was wondering if it is no harm for use if I had to keep only one or two.
I want to identify things that I won't need for downsizing.
I have yet to come across with documentation that explains this.
#font-face {
font-family: 'FontAwesome';
src: url('../font/fontawesome-webfont.eot?v=3.2.1');
src: url('../font/fontawesome-webfont.eot?#iefix&v=3.2.1') format('embedded-opentype'), url('../font/fontawesome-webfont.woff?v=3.2.1') format('woff'), url('../font/fontawesome-webfont.ttf?v=3.2.1') format('truetype'), url('../font/fontawesome-webfont.svg#fontawesomeregular?v=3.2.1') format('svg');
font-weight: normal;
font-style: normal;
}
The reason why you have those different file formats is crossbrowser compatibility. There are many font file types, but I will tell you about the most common ones.
EOT
Internet Explorer pioneered support for webfonts since IE4, I believe; older versions, however, only accept .eot files: so, if you want to support IE<9, you have to include that. But .eot is a proprietary file type and is exclusively supported by Internet Explorer, also is very compact and has a kind of digital rights protection to avoid usage without license (the file can have an URL-binding, tying it to a specific domain).
SVG
When Safari implemented webfonts (version 3), they decided to go for the .svg, and Opera followed. Being Webkit Chrome also supports .svg. As you know, SVG is basically graphics in XML format: this made them convenient since the browser wanted to start supporting vector graphics, but it's not the best solutions as fonts in this format can be pretty large.
TTF and OTF
The more common .ttf and .otf are supported by all the modern browsers. These formats have been around since forever: TrueType replaced the bitmap fonts in the 1980s with an outline format, and OpenType is basically built on that standard with added typographical features (such as ligatures, variations and so on). These features are really important for a serious web-typography, but are still in the process of being supported:
See:
http://caniuse.com/font-feature
http://helpme.webink.com/customer/portal/articles/310119-what-browsers-support-opentype-features
https://www.typotheque.com/articles/opentype_features_in_web_browsers (2012)
WOFF
Lastly, .woff is basically .ttf/.otf with added compression (has a ~40% better compression than those) and metadata (for example, the license). It was specifically developed for the web by W3C for the web performance (bandwidth constraints) and has a suprisingly good support.
In conclusion, I don't think not putting them in the CSS will save you a few bytes, browsers are presumably smart on the fonts they download when encountering the #font-face property.
See: What fonts do browsers download when using #font-face
This all boils down to browser support.
For instance, woff doesn't work on IE8 or various mobile browsers, whereas eot does; eot only works on IE. svg doesn't work in IE8 or old versions of Android Browser.
If you don't need to support IE8 then you can probably get away with dropping the eot file altogether. Equally if you don't need to support various mobile browsers then you can probably drop the svg version too.
Different font formats are for different operating systems and browsers. I would suggest reading this article: http://www.paulirish.com/2009/bulletproof-font-face-implementation-syntax/