- better kerning (space between L and o in "Lorem")
- better definition in some letters (like the l in "elit")
- cool stuff like ligatures (f and i in "overfilled")
- and swashes (the Q in "Quisque").
Great work! I'm consistently annoyed but how much stuff google fonts are missing and how slow they are to update their fonts to the newest versions. Crimson Text comes to mind.
Out of curiosity, why are ligatures considered good? I commonly notice them in print because it catches my eye and hinders my scanning. Is it just because I am adjusted to digital media that commonly lacks it and the surprise factor is outweighing some other benefit?
In some cases the results of not having ligatures can look terribly bad. For example for fonts where the 'f' ends with what looks like a dot: if you put that kind of 'f' with an 'i' after it, the dot of the 'i' and the end of the preceding 'f' make for a very, very ugly artefact which looks like two dots connected to each others. Not only I find this ugly but also actually distracting. It depends on the font used, the kerning, etc.
This kind of uglyness due to the lack of ligature if not as noticeable on digital media, where we typically don't have the 1200+ dpi that print does and where, hence, you tend not to have these kind of 'f' (for example) because fonts have been hinted (or specifically chosen / created) not too have these issues.
I hope my explanation makes sense: I'm not a native english speaker but I did write and typeset myself about a dozen books (most with Quark XPress, one with LaTeX)... And they were all using ligatures IIRC (I should check for my LaTeX one: it's been a long time).
Out of curiosity, why are ligatures considered good?
Ligatures are just single glyphs that represent multiple letters (or their equivalents). So for example the classic ‘fi’ pair is often turned into a ligature as I’ll discuss below, but the ampersand symbol ‘&’ is also a ligature (it originally came from the Latin word et, meaning “and”, although in many fonts today a much more stylised form is used).
In languages like English, ligatures are basically useful for two things: decoration (usually in slightly quirky fonts going for a certain stylised look, rather than everyday typesetting) and tidying up clashes between adjacent letters.
The ‘fi’ pair is an example of the second type. In classical typefaces designed for printing, the ‘f’ would often have quite a long overhang at the top. That worked fine when the following letter was something low like an ‘a’ or ‘o’; you’d just close up the spacing a little, perhaps allowing the top of the ‘f’ to reach over the next letter a little, and everything looked lovely.
Unfortunately, if the following letter was something tall, like an ‘l’ or a dotted letter such as ‘i’ or ‘j’, this left the typesetter an unwelcome choice between moving the letters further apart (creating an awkward space in the lower half) or keeping them close together (creating a dense area or even touching/overlapping symbols in the upper half). Either way, the result tended to be distracting when set at typical body text sizes. So, ligatures like a combined ‘fi’ were adopted as a solution, in that particular case following the spacing and general shape of the original letters but slightly adjusting the top area to avoid the clash.
Unfortunately again, at some point the idea that using such ligatures was automatically a good idea caught on, and instead of serving a useful purpose (fixing clashes in fonts where the design of the font created a clash) they became something supposedly desirable for their own sake, one of those examples of typographic snobbery that just won’t die.
That means today we see them not only where they are genuinely useful but also where they’ve been forced artificially. For example, you’ll get a sans serif screen font where the regular ‘f’ has a short overhang and would quite happily sit next to a normal ‘i’ or ‘l’ with no problems, and then someone comes along and creates a distorted ‘fi’ ligature for it where the ‘f’ is extended and then clumsily wrapped into the dot over the ‘i’, even though there’s no reason to do that and actually it distorts the shaping and reads worse than the original.
The other common mistake is to try and use techniques that work at body text sizes (where the useful kind of ‘fi’ ligature is a minor adjustment that should go unnoticed by a typical reader) and apply them at larger sizes for things like headings or pull quotes (where the adjustment becomes a big, obvious distortion when scaled up). In most cases, text set at large sizes would have been just fine with the original ‘f’ and ‘i’ glyphs and perhaps a touch of extra spacing, but sadly modern digital typography often lacks the hand-finished refinement that the old masters used to produce (at least in my rose-tinted view of history), because it’s just too much extra work to fine-tune everything.
And thus we get things like the example here, where perhaps the ligature has been applied at a size a little larger than it really suits, and so you get what looks like an ‘h’ in the middle of the word and to some readers it then becomes the very distraction it was supposed to avoid.
> this left the typesetter an unwelcome choice between moving the letters further apart (creating an awkward space in the lower half) or keeping them close together (creating a dense area or even touching/overlapping symbols in the upper half).
i just want to clarify that when it came to classic printing, the problem was much more pragmatic than aesthetic. The top of the f actually extended beyond the horizontal bounds of its sort[1]. If you didn't use a ligature, you risked damaging either your /f or your /i, but almost certainly you'd notice it when the line didn't pack flush. The the ligature was partly aesthetic, but it existed historically to make the act of printing work easily.
Now that kerning is better supported, 'historical ligatures' are something of a luxury, which is why they're still an opt-in feature in opentype fonts (you can see this distinction, btw, in the `rlig`, `dlig`, `liga`, `clig` and `hlig` opentype features[2]), except for brick, which is opinionated about these things.
Brick is a free and open source webfont service that serves fonts in their original form for beautiful rendering and full feature sets (kerning, ligatures, etc.)
I dunno. On OSX in Chrome, at least, they look absoutely identical except for the 'fi' ligature, and the "E" in "Etiam" is kerned one pixel tighter, and there are maybe 3-4 other spots where there is 1px difference of kerning.
I've got a sharp eye, but at 300k for Brick, vs 92k for Google Fonts, I've got to go with Google Fonts here, especially when I'll usually have a given Google Font cached anyways, so it's often 0. But I'm glad to be given the option, regardless, and the opportunity to compare.
And as for character sets, Google Fonts lets you pick the character sets you want, too. Does Brick provide any characters which Google doesn't allow you to add?
Speaking of the cache and download sizes, when I reload the Google specimen the font files return a 304 (not modified) status while the Brick ones return a 200 code and have me download the files all over each time.
So for me it's 300k each time the page loads (Brick) vs 92k for the first page load and ~0 each time after that (Google).
So if you add a `&subset=all` to the example page requesting from Google Fonts, they'll end up looking pretty much the same (though I think some things are missing in the example, like the swashes on the Qs).
I discovered this in reading the Lobster font's documentation.
I want to give a big thank-you to the fine folks at Fastly (http://www.fastly.com) who generously agreed to host Brick on their great CDN network. They're big fans of open source!
What the heck is with the bottoms of the lowercase a, w, and t? Is it really supposed to dip below the line like that? And is the fi really supposed to join up in this font, or are they just overlapping and it's a happy accident that it looks like a ligature?
Overall it looks quite a bit heavier. I can see that working sometimes but not always.
I'm pretty sure the fi is supposed to be joined; if you highlight it with your mouse, it highlights as one character (though on copy-and-paste it's two, as expected).
OpenType fonts usually look a bit heavier, but I don't think it's a big issue.
Alfred, love the project and effort. Everything looks great on my Mac.
On a current Windows 7 machine, Brick is much better than Google web font using Chrome, but both FF and IE v11 would be a show-stoppers for me, with random baseline shifts in the preview header making it look a little like a ransom note font.
Is there any browser compatibility lost by offering up only the WOFF format?
OK, the only difference is in the link to show the other sample and the use of Brick versus Google Fonts.
The ligature is nice. My eyes aren't good enough to notice kerning differences--but that may be because the HUGE difference between the two samples is the line spacing. Brick jams those lines together like sardines, and while Google Fonts goes at least somewhat overboard in the other direction, if I had to choose, that so-tight-it-squeaks line spacing makes Brick painful to read.
UPDATE: Whew, thanks! Much better. I'll have to take a look and see what changed.
I think I dislike the Brick version just for that ugly Q thing that takes up half a word, but it seems less bold and clear as well on Chrome on a Mac here. I often hear the Mac OS causes this sort of thing anyway, though, where "improved" fonts don't look much better in other web projects as well.
Only woff means no support for IE8 and the Android browser (<4.4). I checked on my Android 4.1.2 stock browser, the fallback is regular sans-serif. I guess, this type of progressive enhancement is acceptable.
That being said, this information should be explicitly presented (even highlighted) on the site, IMO.
Congrats, font rendering looks Awesome on Chrome (win7), miles ahead of Google Fonts (which honestly, sucks on Chrome, and made me lose an entire day searching for why webfont rendering looks so so bad on Chrome).
Again, thanks a lot!
Heh, they both look fine to me. I really couldn't see the difference... I'm a sucker for good design, but it seems my font style is in the incompetent zone.
The most noticable differences (apart from the rendering) are the fi ligature in the title ("overfilled") and the Q feature (where the tail is extended past the first letter ("Quisque").
Kerning is also better on OS X (with Firefox, Chrome and Safari 6), but it's hard to notice on the demo pages because, for some reason, the text body in the Google Fonts page is three pixels lower than in the Brick version.
I glanced at the CSS but couldn't find the reason.
They look identical in chrome on Linux, the "fi" looks better with google fonts but the brick version make the fonts look a tiny bit more plump and darker.
The fonts that are also in Google Fonts should have the same license; for the ones that are not, consult the license file in each font's directory, but all of them should be usable commercially.
iOS devices typically have a much higher DPI than a "normal" (though this is rapidly changing) screen.
Because of that fonts often look far better and "truer" to their original intentions, Macs/iOS have always favoured fidelity over legibility (when pushed) so it is perhaps not surprising they both look good.
http://brick.im/preview/brick.html
http://brick.im/preview/google.html
On firefox on osx, I see:
- better kerning (space between L and o in "Lorem")
- better definition in some letters (like the l in "elit")
- cool stuff like ligatures (f and i in "overfilled")
- and swashes (the Q in "Quisque").
Great work! I'm consistently annoyed but how much stuff google fonts are missing and how slow they are to update their fonts to the newest versions. Crimson Text comes to mind.