Why are there 6 files in the fonts folder? - font-awesome

So the fonts folder of the FontAwesome distribution contains 6 different files.
fontawesome-webfont.eot
fontawesome-webfont.svg
fontawesome-webfont.ttf
fontawesome-webfont.woff
fontawesome-webfont.woff2
FontAwesome.otf
Why? Do I need all of them? I don't see anything obvious on the FontAwesome readme or website explaining why all these different formats exist.
I'd prefer to have only the ones I need checked into my project.

Different browsers support different formats, there is a handy table on MDN for font formats.
You could use that table to select which fonts you want to include - you could just supply the WOFF, which has reasonably broad support. But by including more formats, more people will get the font rather than the fallback.
What does each font get you?
WOFF is pretty standard for "modern browsers", and WOFF2 is the next generation. These are the formats you really need.
You can extend the support by adding the following formats to gain some old versions of browsers:
TTF/OTF - Firefox < 3.6, Safari < 5.1, Opera < 11, Chome < 5.0
EOT - IE < 9
SVG - Chrome < 5.0

This answer might help:
Why should we include ttf, eot, woff, svg,... in a font-face
Basically certain older browsers (or specific newer browsers) need different formats. By including all the formats, a client's browser can switch to the one it supports.

Related

Hosting Font Awesome Yourself: Do we need all formats eot, svg, ttf, woff, woff2?

I'm packing FA as part of my Angular 7 widget and web application using the approach Hosting Font Awesome Yourself. The thing is they explain to pack the whole /webfonts/ folder and it contains repeated fonts in each format.
Isn't it better to stick to one format e.g. svg and leave the others out?
What are the cons/pros, if any, of going for one specific format only?
If you need your web application that support in older browser too then you must host every font formats.
Unfortunately, there isn't a single format that works in all browsers, which means that we need to deliver multiple formats to provide a consistent experience.
Serve WOFF variant to the majority of browsers.
Serve WOFF 2.0 variant to browsers that support it.
Serve TTF variant to old Android (below 4.4) browsers.
Serve EOT variant to old IE (below IE9) browsers.
if you use only SVG font formats and leave the others out then it will support in Chrome(4.0 +), Safari(3.2 +) and Opera(9.0 +). you can check here the browser support for font formats.
The WOFF is the only format that support the majority of browsers. so
if you can ignore the older browser then I suggest you to use WOFF
font formats.

How could I embed a raster font in a website?

Let's say the font is a .fon or .fnt, could I embed these in a webpage? Is there a particular format for embedding a raster font?
Unfortunately, there's no way to do this today. But while the technology is still in its infancy, multicolor fonts are coming to browsers. This would allow you to convert those bitmap formats to plain OpenType TTFs. All but Microsoft's proposal would allow for bitmap/raster fonts to be used.
This technology already works in current versions Firefox on all platforms. Support in other browsers is coming.
Support to font embedding via #font-face covers EOT (IE only), WOFF, SVG, and TTF/OTF. So the font files would need to be converted to at least one of these formats (and, for best browser coverage, all of them).

#font-face with data URIs and Font Squirrel’s #font-face generator

I am developing a JavaScript application for modern browsers and I don't need to support older ones. I want to embed the fonts in my CSS file instead of loading them.
For all the browsers that I want to support, I just need the WOFF and TTF fonts.
Now when I use the Font Squirrel’s #font-face generator, with "base64 encode" -- it only gives me the data URI for WOFF type and NOT for the TTF type.
Why does it do it?
I believe the reason is to minimize overall file size / load time.
Some devices have a 25kb limit in order to maintain files "cached". When the TTF and the WOOF are base64'd the CSS file can exceed the limits and cause a reload each visit.
Browsers will use the first font "it can" (or "cascade" if you will). You will see the formats listed in the following order for specific reasons:
1. EOT - used to catch older IE (<9).
IE will choke with multiple "src". You'll often see ?#iefix involved in the EOT reference, or an additional selector with just the EOT file in there followed by a similar selector witht he WOFF and TTF. Plus, since old IE doesn't do datauri, we have to leave as an external file.
2. WOFF - Most modern browsers.
Most modern browsers will use WOFF. This format is very small, even with base64 encoding. So keeping it within the CSS makes sense. Plus WOFF may not upload via FTP properly and/or the server may not have the proper mime's set for the WOFF extension.
3. TTF - used to catch Android, and some older browsers.
The older browsers that need TTF are:
- old Safari (5.0)
- old IOS (<4.2)
- old Opera (10.0)
Again, including the TTF as "heavy" base64, the CSS file may be too big for some devices to cache. Keeping the TTF as a binary and as an external file is smart because it'll only get loaded/used if needed.
Here's simple chart based on caniuse.com's data:
---------------
EOT
---------------
IE >= 6
FF -
Chrome -
Safari -
Opera -
O mini -
O Mobi -
IOS -
Android -
---------------
WOFF
---------------
IE >= 9
FF >= 3.6
Chrome >= 16
Safari >= 5.1
Opera >= 11.6
O mini -
O Mobi >= 11.0
IOS >= 5
Android -
---------------
TTF
---------------
IE -
FF >= 3.6
Chrome >= 16.0
Safari >= 5.0
Opera >= 11.6
O mini -
O Mobi >= 10.0
IOS >= 4.2
Android >= 2.2

IE Incompability for header title

Working on the following site:
Markup Medya
If you look at the header, there is header text which displays fine on Firefox and chrome, but in IE 10 it shows very small. Not sure what s wrong there and need help with that.
This is a font issue. You have several #font-face declarations in your CSS, but you are only specifying font files in the the .woff format.
This will give you an issue in more than just IE.
Please note that in order to support all browsers, you will need to supply your fonts in several formats -- to cover all the browsers in common use you'll need .eof, .woff, and .ttf formats.
See this Bulletproof #font-face article for more detailed discussion of which browsers support which formats and how to write your #font-face declarations in order to get the best possible cross-browser coverage.
If you haven't got your fonts in all the required formats, you can use a tool like FontSquirrel to help you.

#font-face declaration in css doesn't work

I'm helping my sister convert a website that somebody did for her in flash into html.
They use fancy fonts in the flash that I am trying to define in a css file through #font-face. I tried opening the page in firefox, IE and chrome, but nowhere do I see the proper font.
The declaration that I am using is:
#font-face {
font-family: "VAG Rounded";
src: url("http://judith.huinink.net/chilax/VAGROUNL.OTF");
}
http://judith.huinink.net/chilax/index.htm contains the html.
http://judith.huinink.net/chilax/chilax.css contains the full css.
I checked that I can download the font file, but it simply doesn't use the font when I open the page in a browser. I must be overlooking something. Does anybody have any suggestions?
font-face goes mainstream
As of January 2010 all major new browsers support font-face
Safari 3.1
IE - all versions
Firefox 3.6
Chrome 4
Opera 10
See http://webfonts.info/wiki/index.php?title=#font-face_browser_support
Update
In the last year, browser support for fonts has improved rather dramatically. I'd suggest reading Tim Brown's excellent article on the subject, which describes in detail how to get web fonts working in most modern browsers.
Original answer
In realistic terms, #font-face is completely unusable right now. Only two browsers support it — Internet Explorer for Windows, version 5 or better, and Safari 3.1.
Worse, IE and Safari do not support the same font formats. IE supports only EOT, while Safari instead supports the more common TrueType (.ttf) and OpenType (.otf) formats.
Almost no browsers support #font-face: When can I use...
http://www.css3.info/preview/web-fonts-with-font-face/
How to use #font-face in all browsers that support it: at Jon Tangerine's blog
ttf2eot is a nice font converter for Unix and Windows so you don't have to use the horrible old Microsoft WEFT. It converts the whole font, not just some characters.
Here's a javascript to use with sIFR that disables sIFR for #font-face enabled browsers.
Flash needs to die, so here's another alternative to sIFR: facelift. It's a serverside script that generates images.
The problem with afaik all sIFR replacements is that selecting and copying text doesn't really work -- you either don't see the selection, or it's impossible to select less than a word or line. There's also Cufón which uses <canvas>, so it only works on newer browsers, most of which have #font-face anyway.
Do the right thing, use the state-of-the-art technology now: #font-face with TTF or OTF, and fallbacks for IE and old browsers. Preferably keep your HTML clean and implement those fallbacks in separate javascript and CSS files. For IE you might need to use "conditional comments" as explained in my first link above. For browsers with javascript disabled, always specify a list of replacement fonts with the web-safe fonts at the end.
Check out the ever popular sIFR or with no flash dependency, typeface.js
I've come across situations where WWW must be included in the domain. Without it, it wouldnt work.