> 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.
Also, without accessible web fonts, developers will have to use images containing rendered texts to get text pretty on their web pages, which is not so easy to index for a search engine.
> Except the part where they allow you to download them and serve yourself.
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.
... And you got these links from? What is the license for these .eot and .woff? Who says you can self-host them?
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.
So you are claiming that reason of very existence of Google Fonts is to collect not-so-useful-and-easily-could-be-collected-by-other-services-of-Google data? Can we stop the whole Google bashing it is getting ridiculous.
I personally think that Google does things like this because they can; they are not under money pressure (yet?) to have to really try to extract maximum value from every bit served or watt consumed, and can thus spend energy on initiatives like this that improve the web as a platform -- it's at best an indirect benefit, but fits their overall corporate strategy. And, it's cool.
I have my doubts about Google, but I don't have a problem giving them the benefit of the doubt here.
The motivations, as far as i know, are written on the about page:
"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".
sure, advertising. but the goal here is to make the web more user friendly and useful for people, through better looking design/readability etc. That helps us all, and if then in turn they can keep the ad platforms alive, good on them I say.
Google Fonts, Google Public DNS, Google Analytics, Google+ like gadgets, Google Adsense, Google CDN for jQuery etc, Google services like Search and Gmail, Embedded Youtube videos, Google Chrome word correction sugesstions and safe sites checks, Firefox safe page checks, probably many things within Android backend.
Probably they know with 99.9999999% accuracy how many online web users are out there.
In return for what? Google's not profiting off of Google Fonts, because I'm sure that whatever data they get from it could be collected by their other services.
If you're concerned about your own privacy in this respect, you can install a plug-in for most browsers that will prevent a real Referer being sent with your requests. Google will still serve you the web font, they just won't know which page you were viewing at the time.
(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.)
Imagine how ridiculous the web would look today if content creators had to restrict the images they used to some common subset of those preinstalled on clients' operating systems.
Would you condemn web typography to the use of "web safe fonts" forever?
Isn't it the job of the user agent to have options to override the choices of a website? Otherwise, the subset of "fonts everybody is sure to have" is just too small.
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.
I am in the middle of a redesign and the new design uses Droid Serif. I wanted to avoid an extra HTTP request and bundle the WOFF font file in the CSS (using data URIs). The other option was to host the font on my server to avoid the DNS lookup for yet another domain. (CSS is in the critical path for page loads).
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.
My least favorite thing about Google Fonts is that they look different on different browsers for each platform too. On my latest site design I had to put them on my server because they actually looked the worst in Chrome.
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.
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.
Don't forget that browsers will wait for the CSS file to download before rendering the page.
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.
YMMV, but we did plenty of testing for one site I currently work on with a heavy mobile access focus, and it wasn't even close. We could have added hundreds of extra KB in a CSS file and still beaten even a single additional image file that needed a whole extra HTTP round trip for a visitor with a typical intermittent mobile connection (poor reception, on the move, etc.). The multiple levels of set-up required in that context can easily dominate the overall time to seeing a useful page.
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.