https://developers.google.com/fonts/faq#Download_Fonts
> You can download the fonts to use them for your mockups, in your documents or to host them on your own server.
Google Fonts exists because it's in Google's best interest if everything is online. Having freely available high-quality fonts is a [small] way to help move that along.
Update: No cookies are set by Google either, they're just doing analytics by the user agent sent. The actual font files have 1 year expires headers on them as well, so cookies would be of limited use.
Yeah, you try that. It's a single format that you need to convert yourself to produce woffs, eots and other variations needed for the actual self-hosted deployment, and no matter how you convert, they will never come out looking the same as Google's native versions. This "go ahead, host it yourself" is disingenious and manipulative at best.
http://themes.googleusercontent.com/static/fonts/droidsans/v...
http://themes.googleusercontent.com/static/fonts/droidsans/v...
http://themes.googleusercontent.com/static/fonts/droidsans/v...
Rocket science or not, the bottom line is that these are not available from Google Fonts. You are expected to either use hosted version or muddle through the conversion process.
@font-face generators are dime a dozen. The issue is that they generate kits of subpar quality for Google fonts.
I have my doubts about Google, but I don't have a problem giving them the benefit of the doubt here.
"A web with web fonts is more beautiful, readable, accessible and open. " Google Fonts makes it quick and easy for everyone to use web fonts, including professional designers and developers. We believe that everyone should be able to bring quality typography to their web pages and applications."
If you have some actual evidence that the last part isn't true, and that it's really some big scheme to "log visits", what is it, exactly?
FWIW - my dealings with the team, which mostly involve reviewing occasional open source font contracts, makes me believe they really are just crazy about making web typography good. But i'm really interested in whatever sinister theories people have.
I mean, you know what they say about people who like "Signika Negative".
1. What "trillions of visits logged" means, exactly. IE what you think is being logged past a request for a font.
2. What you think the data is actually used for
The web font loader is open source, so this should not be too hard to explain what it's sending that you think is valuable and why.
Or you know, you could just continue on with meaningless ad-hominen attacks, since well, you never responded to anything i asked.
Probably they know with 99.9999999% accuracy how many online web users are out there.
(I'm not making any comment on Google's general strategy or how many people would actually understand that they might wish to protect their privacy in this way, just pointing out that it can be done.)
Would you condemn web typography to the use of "web safe fonts" forever?
Why not let everybody have websites look how they want them to look? I'm kinda sad this vision gets so little attention, that instead we all try to push our vision on our visitors. Even if the web turns app platform.. just like we have configurable desktop managers, browser could still let everybody customize how websites look - if only websites could stop with the "story telling" and "experiences", and concentrated on utility and information. We're too addicted too shiny for our own good already.
Both are easy to do but I abandoned both of those ideas after watching this interview http://www.youtube.com/watch?v=sqesm0euf9M
Google Fonts makes a lot of optimizations that are platform-specific. e.g. serve smaller files to Macs, larger files to Windows. It is not worth doing all this yourself.
IE8 can handle up to 32KB[1], and more recent versions of all major browsers appear to have much higher limits. IE7 and below didn't support data: anyway.
[1] See http://caniuse.com/datauri, and confirmed by Microsoft's own technical documentation.
In terms of file size, a naive implementation of replacing reference to image files with data: URIs carries a theoretical overhead of 1/3. However in practice, as long as you're serving the relevant CSS file gzipped, you're likely to see less than 5% overhead on a single file. If you've got several similar image files converted to data: URIs within the same CSS file, you might even see a significant gain because the compression can remove more redundancy.
In terms of HTTP requests, generally fewer is better, so it's hard to go wrong here by using data: URIs instead of separate but relatively small image files.
The only major factor I can immediately think of that is clearly in favour of separate image files, unless you're really at the level where the decoding performance for data: URIs makes a significant difference, is that the image files can be cached independently, which may or may not be a win depending on how you manage your CSS and how often the various parts of it change relative to each other.
Far better to let "unnecessary" image files load later via separate HTTP requests than to delay everything just so that you can save one or two HTTP round-trips.
This is a big issue on mobile.
I'd advise comparing both methods on https://developers.google.com/speed/pagespeed/insights/
Of course it's less of a dramatic comparison if you don't have all that set-up overhead to worry about, but then the time to download an extra 200K of CSS is negligible on basically any broadband or stable 3G or better connection today, so we don't tend to worry much about that sort of situation. In practice, our decision on how to transmit medium-sized images is often based on cache-related factors.
Just remember, kids, that it's the only reason Google Fonts exist.