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

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

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.

Why are there 6 files in the fonts folder?

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.

Google Font not rendering In IE due to IE=EmulateIE8

The Issue : When IE=EmulateIE8 is used in header New IE versions are rendering it with IE8 Engine, But google Returns WOFF as the font format. so It does not render correctly in IE.
Woff Support -> http://caniuse.com/woff
<META http-equiv=X-UA-Compatible content=IE=EmulateIE8>
Code Used (because it is an old site and something breaks when this is removed!!)
So removing this is out of the question I think...
This is my IE 11 Rendering in default format (IE8)
and when switched to IE11 Font loads correctly and displays!
My question is
how to request an older font from google fonts?
Any other approach to this?

Embedding Base64 Images

Purely out of curiosity, which browsers does Base64 image embedding work in? What I'm referring to is this.
I realize it's not usually a good solution for most things, as it increases the page size quite a bit - I'm just curious.
Some examples:
HTML:
<img alt="Embedded Image" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADIA..." />
CSS:
div.image {
width:100px;
height:100px;
background-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADIA...);
}
Update: 2017-01-10
Data URIs are now supported by all major browsers. IE supports embedding images since version 8 as well.
http://caniuse.com/#feat=datauri
Data URIs are now supported by the following web browsers:
Gecko-based, such as Firefox, SeaMonkey, XeroBank, Camino, Fennec and K-Meleon
Konqueror, via KDE's KIO slaves input/output system
Opera (including devices such as the Nintendo DSi or Wii)
WebKit-based, such as Safari (including on iOS), Android's browser, Epiphany and Midori (WebKit is a derivative of Konqueror's KHTML engine, but Mac OS X does not share the KIO architecture so the implementations are different), as well as Webkit/Chromium-based, such as Chrome
Trident
Internet Explorer 8: Microsoft has limited its support to certain "non-navigable" content for security reasons, including concerns that JavaScript embedded in a data URI may not be interpretable by script filters such as those used by web-based email clients. Data URIs must be smaller than 32 KiB in Version 8[3].
Data URIs are supported only for the following elements and/or attributes[4]:
object (images only)
img
input type=image
link
CSS declarations that accept a URL, such as background-image, background, list-style-type, list-style and similar.
Internet Explorer 9: Internet Explorer 9 does not have 32KiB limitation and allowed in broader elements.
TheWorld Browser: An IE shell browser which has a built-in support for Data URI scheme
http://en.wikipedia.org/wiki/Data_URI_scheme#Web_browser_support
Most modern desktop browsers such as Chrome, Mozilla and Internet Explorer support images encoded as data URL. But there are problems displaying data URLs in some mobile browsers: Android Stock Browser and Dolphin Browser won't display embedded JPEGs.
I reccomend you to use the following tools for online base64 encoding/decoding:
Encode to Base64 format
Decode from Base64 format
Check the "Format as Data URL" option to format as a Data URL.
Can I use (http://caniuse.com/#feat=datauri) shows support across the major browsers with few issues on IE.

#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.