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/
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.
A typical #font-face setup:
#font-face {
font-family: 'myFont';
src: url('/fonts/myFont.woff') format('woff'),
url('/fonts/myFont.ttf') format('ttf'),
url('/fonts/myFont.svg') format('svg'),
url('/fonts/myFont.eot') format('eot')
}
Now, we have this definition of IE 9+, which translates to "modern browsers". Looking at font type support it is a big mess, though eot seems to be for IE8. Looking at the site "can I use" both woff and svg format is supported by all modern browsers.
So why do we add all these three formats, we only need one as all modern browsers support either woff or svg? What I do not understand either is that the order matters. So in the example above all modern browsers will download the "woff" format. There is no need to add svg. So why do we do that?
The background for this question is inline optimization. If I want to include my fonts as a Base64 string it is not very "optimizely" to inline all three font formats, it will only make the CSS unnecessary large.
So if your target is "modern browsers", just choose a format that the font supports and stick with that. Forget about this fallback that "every single example" on the web uses.
Maybe some formats looks better in some browsers than others, but it does not matter because the browsers will only download the first supported format anyways which in "modern browsers" will always be the first woff or svg on your font face list, or ttf if you do not care about IE.
So, I have just made a bunch of assumptions here. Is there really any reason to add all of them? You mostly get away with using either woff or svg?
You almost answered all your question yourself. :)
Here's a good read that might help:
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization?hl=en
Re SVG fonts, I think Safari on older versions of iOS only supported SVG webfonts. That's why it became popular in recipes. EOT was old IE. TTF is pre-woff non-IE. There's also woff2 around these days which is supported in Chrome, Opera, and non-release builds of Firefox.
For inlining font data, you need to detect your browser and send down the best supported version.
I'm using a custom font in a page I'm developing, Droid Sans, and at certain font sizes, the bottom is cut off, but only in Opera and webkit browsers.
It's easy to reproduce on Google's own webfonts page looking for Droid Sans and showing the whole alphabet at 18px: http://www.google.com/webfonts
It's especially clear for the lower case g.
Is there some css trick / hack I can use to increase the line height / show the whole character or am I really limited to only certain sizes of the font?
line-height and padding for example don't change anything and 20px font-size works fine and at the moment I am using Windows 7.
Edit: By the way, I am aware of a similar question here but as the accepted answer is changing the font size and the rest of the answers do not apply, it is of not much use to me.
Edit 2: An example that at least for now shows the problem (left hand column, under the slideshow, Il Cerca Viaggi).
Edit 3: The problem seems to be limited to Windows although I'm not sure which versions.
Edit 4: I have added a screenshot from Google Webfonts to show that the problem is not specific to the site I'm developing.
Although it is not the solution I am looking for, I have found a possible solution that might work for others:
In my original style-sheet I have specified the font as follows:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype'),
url('droid-sans/DroidSans-webfont.svg#DroidSans') format('svg');
font-weight: normal;
font-style: normal;
}
This is causing webkit browsers to use the woff file / format.
Changing the order of the font specifications and removing the hash-tag after the svg specification (why is that there anyway?), causes webkit browsers to use the svg file / format:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.svg') format('svg'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
This solves the problem, all characters are displayed correctly.
However, at least in Windows 7 64bit, the svg font is not as sharp as the woff font, it's kind of blurry so I will not be using this solution and am hoping for a better one.
To a similar question, one answer suggested that, while this appears to be a Windows font rendering issue specifically, hosting svg, eot and otf versions of a TrueType font (TTF) containing the font, which was not optimized for the web, had fixed the problem for its provider. If possible, get a clean, un-optimized version of the DroidSans font and export the web fonts yourself.
EDIT: Sorry all, I was out for the holiday and didn't have access to SO. Since I've been back, I've done a little research into exactly what's causing this problem on Windows machines...
It appears that the issue lies with the way the OpenType format is rendered on Windows machines. The issue with truncated descenders seems to transcend software type to affect multiple Windows programs attempting to render OpenType. Currently, you have the Embedded OpenType format (EOT) version of the font listed first in your CSS document under #font-face. Since Chrome and Opera both recognize this format, they'll disregard the subsequent source declarations and use EOT to display the font. Unfortunately, there doesn't seem to be a quick fix that you could apply to an OpenType font itself to force the software rendering it to allow adequate line-spacing for the lowest of its descenders on Windows machines...
However, you can be choosy about which fonts you feed to your viewers' browsers. Personally, I would recommend placing the SVG version first in your CSS, and for browsers that don't recognize this format, suggest TrueType (TTF) second, then WOFF, then EOT for browsers that don't support any of the aforementioned (some older versions of IE appear to support OpenType exculsively). If the SVG rendering isn't much to your liking, try TrueType first instead.
Alternatively, although I'm no longer really that confident that it will help, you can download a TTF of DroidSans at FontSquirrel and use a software package like Typograf to export web fonts (EOT, WOFF, SVG). Try rearranging the sources in your CSS as outlined above first, though.
ANOTHER EDIT: My erroneous use of TIFF instead of TTF has been redacted to avoid confusion in the future. Apologies for the mix-up, guys...
I am not sure but try to add this for padding to work
display:block;
padding-bottom:20px;
margin-bottom:10px;
line-height:normal !important;
line-height:55%;
Set the line height to normal, it is a firefox bug and use the line height in %
I think this might do the trick
It all boils down to the font itself.
Look here
http://jsfiddle.net/DdMej/2/
The first row uses Drod Sans by Google fonts.
The second row uses the font you have on your site.
edit 1
Screenshot
http://imageshack.us/photo/my-images/811/screeniy.png/
I too was seeing my Google Font 'Lato' cut off at the bottom portion of the rendered text. In my case, I needed to serve the font files locally instead of using Google Fonts. To do this I:
Converted the font from .ttf to webfont files with Font2Web
Served the font files locally as static file assets from the localhost
Included fonts in my css with the bulletproof #font-face implementation
This eliminated my cut off rendered text issue.
In CSS3 font-face, there are multiple font types included like ttf, eot, woff, svg and cff.
Why should we use all of these types?
If they are special to different browsers, why is the number of them greater than the number of the major web browsers?
Answer in 2019:
Only use WOFF2, or if you need legacy support, WOFF. Do not use any other format
(svg and eot are dead formats, ttf and otf are full system fonts, and should not be used for web purposes)
Original answer from 2012:
In short, font-face is very old, but only recently has been supported by more than IE.
eot is needed for Internet Explorers that are older than IE9 - they invented the spec, but eot was a proprietary solution.
ttf and otf are normal old fonts, so some people got annoyed that this meant anyone could download expensive-to-license fonts for free.
Time passes, SVG 1.1 adds a "fonts" chapter that explains how to model a font purely using SVG markup, and people start to use it. More time passes and it turns out that they are absolutely terrible compared to just a normal font format, and SVG 2 wisely removes the entire chapter again.
Then, woff gets invented by people with quite a bit of domain knowledge, which makes it possible to host fonts in a way that throws away bits that are critically important for system installation, but irrelevant for the web (making people worried about piracy happy) and allows for internal compression to better suit the needs of the web (making users and hosts happy). This becomes the preferred format.
2019 edit A few years later, woff2 gets drafted and accepted, which improves the compression, leading to even smaller files, along with the ability to load a single font "in parts" so that a font that supports 20 scripts can be stored as "chunks" on disk instead, with browsers automatically able to load the font "in parts" as needed, rather than needing to transfer the entire font up front, further improving the typesetting experience.
If you don't want to support IE 8 and lower, and iOS 4 and lower, and android 4.3 or earlier, then you can just use WOFF (and WOFF2, a more highly compressed WOFF, for the newest browsers that support it.)
#font-face {
font-family: 'MyWebFont';
src: url('myfont.woff2') format('woff2'),
url('myfont.woff') format('woff');
}
Support for woff can be checked at http://caniuse.com/woff
Support for woff2 can be checked at http://caniuse.com/woff2
Woff is a compressed (zipped) form of the TrueType - OpenType font. It is small and can be delivered over the network like a graphic file. Most importantly, this way the font is preserved completely including rendering rule tables that very few people care about because they use only Latin script.
Take a look at [dead URL removed].
The font you see is an experimental web delivered smartfont (woff) that has thousands of combined characters making complex shapes. The underlying text is simple Latin code of romanized Singhala. (Copy and paste to Notepad and see).
Only woff can do this because nobody has this font and yet it is seen anywhere (Mac, Win, Linux and even on smartphones by all browsers except by IE. IE does not have full support for Open Types).
WOFF 2.0, based on the Brotli compression algorithm and other improvements over WOFF 1.0 giving more than 30 % reduction in file size, is supported in Chrome, Opera, and Firefox.
http://en.wikipedia.org/wiki/Web_Open_Font_Format
http://en.wikipedia.org/wiki/Brotli
http://sth.name/2014/09/03/Speed-up-webfonts/ has an example on how to use it.
Basically you add a src url to the woff2 file and specify the woff2 format. It is important to have this before the woff-format: the browser will use the first format that it supports.
I'm using a custom font in a page I'm developing, Droid Sans, and at certain font sizes, the bottom is cut off, but only in Opera and webkit browsers.
It's easy to reproduce on Google's own webfonts page looking for Droid Sans and showing the whole alphabet at 18px: http://www.google.com/webfonts
It's especially clear for the lower case g.
Is there some css trick / hack I can use to increase the line height / show the whole character or am I really limited to only certain sizes of the font?
line-height and padding for example don't change anything and 20px font-size works fine and at the moment I am using Windows 7.
Edit: By the way, I am aware of a similar question here but as the accepted answer is changing the font size and the rest of the answers do not apply, it is of not much use to me.
Edit 2: An example that at least for now shows the problem (left hand column, under the slideshow, Il Cerca Viaggi).
Edit 3: The problem seems to be limited to Windows although I'm not sure which versions.
Edit 4: I have added a screenshot from Google Webfonts to show that the problem is not specific to the site I'm developing.
Although it is not the solution I am looking for, I have found a possible solution that might work for others:
In my original style-sheet I have specified the font as follows:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype'),
url('droid-sans/DroidSans-webfont.svg#DroidSans') format('svg');
font-weight: normal;
font-style: normal;
}
This is causing webkit browsers to use the woff file / format.
Changing the order of the font specifications and removing the hash-tag after the svg specification (why is that there anyway?), causes webkit browsers to use the svg file / format:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.svg') format('svg'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
This solves the problem, all characters are displayed correctly.
However, at least in Windows 7 64bit, the svg font is not as sharp as the woff font, it's kind of blurry so I will not be using this solution and am hoping for a better one.
To a similar question, one answer suggested that, while this appears to be a Windows font rendering issue specifically, hosting svg, eot and otf versions of a TrueType font (TTF) containing the font, which was not optimized for the web, had fixed the problem for its provider. If possible, get a clean, un-optimized version of the DroidSans font and export the web fonts yourself.
EDIT: Sorry all, I was out for the holiday and didn't have access to SO. Since I've been back, I've done a little research into exactly what's causing this problem on Windows machines...
It appears that the issue lies with the way the OpenType format is rendered on Windows machines. The issue with truncated descenders seems to transcend software type to affect multiple Windows programs attempting to render OpenType. Currently, you have the Embedded OpenType format (EOT) version of the font listed first in your CSS document under #font-face. Since Chrome and Opera both recognize this format, they'll disregard the subsequent source declarations and use EOT to display the font. Unfortunately, there doesn't seem to be a quick fix that you could apply to an OpenType font itself to force the software rendering it to allow adequate line-spacing for the lowest of its descenders on Windows machines...
However, you can be choosy about which fonts you feed to your viewers' browsers. Personally, I would recommend placing the SVG version first in your CSS, and for browsers that don't recognize this format, suggest TrueType (TTF) second, then WOFF, then EOT for browsers that don't support any of the aforementioned (some older versions of IE appear to support OpenType exculsively). If the SVG rendering isn't much to your liking, try TrueType first instead.
Alternatively, although I'm no longer really that confident that it will help, you can download a TTF of DroidSans at FontSquirrel and use a software package like Typograf to export web fonts (EOT, WOFF, SVG). Try rearranging the sources in your CSS as outlined above first, though.
ANOTHER EDIT: My erroneous use of TIFF instead of TTF has been redacted to avoid confusion in the future. Apologies for the mix-up, guys...
I am not sure but try to add this for padding to work
display:block;
padding-bottom:20px;
margin-bottom:10px;
line-height:normal !important;
line-height:55%;
Set the line height to normal, it is a firefox bug and use the line height in %
I think this might do the trick
It all boils down to the font itself.
Look here
http://jsfiddle.net/DdMej/2/
The first row uses Drod Sans by Google fonts.
The second row uses the font you have on your site.
edit 1
Screenshot
http://imageshack.us/photo/my-images/811/screeniy.png/
I too was seeing my Google Font 'Lato' cut off at the bottom portion of the rendered text. In my case, I needed to serve the font files locally instead of using Google Fonts. To do this I:
Converted the font from .ttf to webfont files with Font2Web
Served the font files locally as static file assets from the localhost
Included fonts in my css with the bulletproof #font-face implementation
This eliminated my cut off rendered text issue.