I self-host fonts for my website, but I only use WOFF. You don't need to use SVG, TTF or EOT unless you want to provide full support for all browsers. If you are happy to provide support for recent, modern browsers only, you can simplify things by just self-hosting WOFF files:
For browsers that don't support WOFF, just specify a browser-safe font in your CSS. Those browsers will ignore the Woff declaration and use the browser-safe font instead.
EDIT: As far as file size goes, I use two font weights on my site: Source Sans Pro regular and bold. Each font weighs 27kb - so 54kb in total. This is much less than many Javascript libraries and third-party embeds.
Here's my site (hope it's fine to link) - it's admittedly very simple and has no Javascript (although Javascript is needed to load the fonts!). In the end you have to weigh up the balance between page weight and performance for your own site.
Thanks. WOFF format now has enough traction that everything except Opera Mini supports it. Originally, Apple's IOS only supported fonts in SVG, of all things. Then they added TTF in 2010, and WOFF in 2012. Unless you need to support something pre-2012 and have it look pretty there, WOFF is enough.
If you need to convert a font for which you have the rights, there's Font Squirrel. (http://www.fontsquirrel.com/tools/webfont-generator). That tool can convert a font to all the popular formats. Throw in SVG if you need to support old iPhones.
You don't really need Google Fonts as a service any more. That was a workaround. Just host on your own site in WOFF.
I don't know. I've had some real issues with WOFF even on modern browsers (Chrome, Mac), where for example it won't render when you don't have an external monitor plugged in (really strange, I know). The only solution I found was using SVG instead.
Sorry, I worded my original post poorly. You need Javascript enabled to load fonts. For example, in Firefox, the WOFF fonts won't display unless Javascript is enabled (even if you have no Javascript on the page).
Yup yup true. Not exactly the same thing. I downloaded them all once to figure out why one of them was dying on Windows 98... just remembered that when I saw the article.
I'm curious - why would you want to host these yourself? Don't your users then lose the benefit of caching (e.g. if they also visit other sites which use the same fonts).
I am an edge case, but one where big CDNs are blocked, especially Google. Where the cache doesn't work, often nor do the entire pages they're supposed to serve; this does not apply only to fonts.
Web performance is complicated though and all the pros and cons interact in non-intuitive ways. A comparison of self-hosted, inexpensive CDN hosted, and original Google hosted may provide some performance surprises.
A few weeks ago suddenly a bunch of fonts changed messing up the layout of a site of a customer. I've also seen periodic slowdowns because the fonts would not load or load very slowly.
In general keeping the number of dependencies down is a good thing to do.
Based on your User-Agent, Google's CSS service only responds with a CSS to either a .woff, .woff2 .eot, .svg or .ttf font file. For local hosting you'll need to order these formats in a compatibility sequence, so every browser gets the one it supports (nice writeup here: http://css-tricks.com/snippets/css/using-font-face/).
As all files are the exact same ones Google is hosting in the wild, I don't feel like you'll lose any optimizations (which might be the case when using font generation services like FontSquirrel).
That's not correct. I just downloaded the same google font css using different user agents, one for Windows Google Chrome and one for OS X Google Chrome. CSS were different, both specified .woff2 format but actual font URLs were different. And downloaded .woff2 files were different as well. I used Open Sans font for that test. http://pastebin.com/edYbfxzU here's log, you can try it yourself.
I'll look into that and maybe provide some additional fonts on a per OS/Browser basis to download. The main problem is that it's impossible to have a static CSS snippet AND provide different files per User-Agent (a javascript solution might help). So until I've found a solution to this, you are absolutely right, these optimizations will get lost on local use!
For reference: I'm currently using the following User-Agents for fetching the font file urls from Google's CSS: http://pastebin.com/5SZ1Q6kj
There are examples of Brick v GF, Brick does indeed look better (to me), but at the expense of file size. The same fonts in the examples are twice the size of GF.
Are you allowed to do this with fonts you got from Google under their terms of service?
I always figured they reason they didn't make it easy themselves was cause they didn't allow it, but never actually checked. I would kind of like to serve google fonts with cache-forever headers -- google strangely doesn't. I'd also like to package them up in a web project I'd like to make runnable from local file system without internet.
One thing I really wish people would "get" is font variants... even font squirrel messes this one up.. you should set up variants to the same family, with the appropriate weight and decoration set...
In general I only specify what I will actually be using, but knowing the difference is helpful... I wish more font packs would do the right thing here.
Former downloads only provided fonts with the default Latin subset, this has been resolved (charsets are selectable). I'm sorry if this causes any inconvenience (please keep in mind, it's still a prototype)...
The only thing that bothers me is the generation of the zip file, but streaming these files without any caching on the server would be very expensive (especially on a single free heroku dynamo).
Google Fonts follows the Google API TOS. As far as I read it: no, as long as there aren't any further restrictions on the font by third parties.
> d. Data Portability
> Google supports data portability. For as long as you use or store any user data that you obtained through the APIs, you agree to enable your users to export their equivalent data to other services or applications of their choice in a way that's substantially as fast and easy as exporting such data from Google products and services, subject to applicable laws, and you agree that you will not make that data available to third parties who do not also abide by this obligation.
but also
> a. Content Accessible Through our APIs
> Our APIs contain some third party content (such as text, images, videos, audio, or software). This content is the sole responsibility of the person that makes it available. We may sometimes review content to determine whether it is illegal or violates our policies or the Terms, and we may remove or refuse to display content. Finally, content accessible through our APIs may be subject to intellectual property rights, and, if so, you may not use it unless you are licensed to do so by the owner of that content or are otherwise permitted by law. Your access to the content provided by the API may be restricted, limited, or filtered in accordance with applicable law, regulation, and policy.
"As far as I read it: no, as long as there aren't any further restrictions on the font by third parties."
My reading of 5e says the opposite. That 'unless expressly permitted by content owners' you shouldn't be allowing caching of content provided via Google APIs.
Perhaps we are arguing the same thing ultimately, but it's important to understand the distinction Google is attempting to make. They're basically trying to cover themselves by asserting that they are not granting any additional freedom beyond what the designer intended. Relicensing without permission is copyright infringement-- Google doesn't want the headache. Their safest course is to specify that unless you've been given license to do certain things by the content owner, that Google themselves is not licensing you to do those things.
Think of it like an affirmation from an open source project licensed under an MIT or BSD license. Although they might include GPL code from elsewhere, they'll generally state that they're not relicensing someone else's GPL code under the less restrictive license.
Hm, well then I will have to request the font files fetched from their hosted CSS, compress them and pipe this output (the resulting zip) without any caching on the server.
This may result in a higher latency, but might be more safe in regards to their ToS.
My personal opinion is to leave things as they are until you hear from Google. Simply be aware of the possible interpretations of the ToS. I do believe Argorak has the correct sentiment: that it's ultimately up to the individual font designer/cretor.
Your temporary caching, to me, seems fine. I read the ToS as saying that permitting your end user to obtain permanent copies might be disallowed ... at the discretion of the font designers. To be absolutely certain, you should check each font's license. Considering the fonts aren't Google's to license, I doubt you'll hear from them.
Interestingly, Google's own Fonts API which I'm using with my service, doesn't provide any information about the underlying license of each font (I previously wanted to include that info in the UI as well).
Applause!!!! I hate Google Web Fonts for their horrible interface to OPEN SOURCE FONTS for which they don't offer download links. It should be prosecuted as a crime. What the hell Google?
http://caniuse.com/#feat=woff
For browsers that don't support WOFF, just specify a browser-safe font in your CSS. Those browsers will ignore the Woff declaration and use the browser-safe font instead.
EDIT: As far as file size goes, I use two font weights on my site: Source Sans Pro regular and bold. Each font weighs 27kb - so 54kb in total. This is much less than many Javascript libraries and third-party embeds.
Here's my site (hope it's fine to link) - it's admittedly very simple and has no Javascript (although Javascript is needed to load the fonts!). In the end you have to weigh up the balance between page weight and performance for your own site.
http://www.interfacesketch.com/