- 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?
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.
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.
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.
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").
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.
[+] [-] makmanalp|12 years ago|reply
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.
[+] [-] esrauch|12 years ago|reply
[+] [-] keeperofdakeys|12 years ago|reply
http://imgur.com/a/5FTc8 (top is brick, sorry for the misalignment).
[+] [-] ionelm|12 years ago|reply
[+] [-] alfredxing|12 years ago|reply
Unrelated note: I locked myself out of HN because I had noprocrast turned on...
[+] [-] ams6110|12 years ago|reply
[+] [-] alfredxing|12 years ago|reply
Site: http://brick.im
GitHub: https://github.com/alfredxing/brick
Usage: https://github.com/alfredxing/brick/wiki/Usage
[+] [-] crazygringo|12 years ago|reply
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?
[+] [-] bjxrn|12 years ago|reply
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).
Is this just me?
[+] [-] alfredxing|12 years ago|reply
EB Garamond, at 300KB, is the largest font in the catalogue right now, since its character set is huge (the other fonts are around 80-100KB).
And while Google does let you choose character sets, not all special glyphs are included (for example, ornaments).
But I agree with you: choice is everything, and it's always better to have an alternative.
[+] [-] mineo|12 years ago|reply
[+] [-] bigbento|12 years ago|reply
See: https://developers.google.com/fonts/docs/getting_started#Sub...
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.
[+] [-] alfredxing|12 years ago|reply
[+] [-] kevinbowman|12 years ago|reply
[+] [-] devindotcom|12 years ago|reply
Overall it looks quite a bit heavier. I can see that working sometimes but not always.
[+] [-] alfredxing|12 years ago|reply
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.
[+] [-] hornbaker|12 years ago|reply
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?
[+] [-] alfredxing|12 years ago|reply
Yes, IE <9 doesn't support WOFF (only EOT). For a compatibility table, see http://caniuse.com/woff
[+] [-] huhtenberg|12 years ago|reply
Top is Brick, bottom is GF, both rendered in Firefox 27 on Windows.
[+] [-] alfredxing|12 years ago|reply
I'll look into it for sure.
[+] [-] jejones3141|12 years ago|reply
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.
[+] [-] jamiesonbecker|12 years ago|reply
[+] [-] alfredxing|12 years ago|reply
Just pushed the commit, should be fixed now.
[+] [-] Buge|12 years ago|reply
On Chrome, Brick kerns "Vestibulum" better. Brick is the same weight as Google. But Brick does not use subpixel rendering while Google does.
On both browsers there was no difference in the kerning of "Lorem".
[+] [-] avodonosov|12 years ago|reply
[+] [-] richardwhiuk|12 years ago|reply
[+] [-] cheshire137|12 years ago|reply
[+] [-] SimeVidas|12 years ago|reply
That being said, this information should be explicitly presented (even highlighted) on the site, IMO.
[+] [-] alfredxing|12 years ago|reply
[+] [-] lnanek2|12 years ago|reply
[+] [-] alfredxing|12 years ago|reply
Of course you'll need to add vendor prefixes.
[+] [-] sogen|12 years ago|reply
[+] [-] err4nt|12 years ago|reply
Is there any way I can use JavaScript to pick swatches or set options like the type panel in illustrator?
[+] [-] alfredxing|12 years ago|reply
[+] [-] jlas|12 years ago|reply
[+] [-] alfredxing|12 years ago|reply
[+] [-] codelap|12 years ago|reply
[+] [-] alfredxing|12 years ago|reply
[+] [-] martinml|12 years ago|reply
[+] [-] jbeja|12 years ago|reply