Brick. Webfonts that look good
github.com
github.com
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.
Unrelated note: I locked myself out of HN because I had noprocrast turned on...
http://imgur.com/a/5FTc8 (top is brick, sorry for the misalignment).
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).
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.
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.
[1]: http://commons.wikimedia.org/wiki/File:Metal_type_kerning.sv... [2]: http://en.wikipedia.org/wiki/List_of_typographic_features
Site: http://brick.im
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?
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.
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?
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.
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.
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?
Yes, IE <9 doesn't support WOFF (only EOT). For a compatibility table, see http://caniuse.com/woff
Top is Brick, bottom is GF, both rendered in Firefox 27 on Windows.
I'll look into it for sure.
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.
Just pushed the commit, should be fixed now.
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".
That being said, this information should be explicitly presented (even highlighted) on the site, IMO.
Of course you'll need to add vendor prefixes.
Is there any way I can use JavaScript to pick swatches or set options like the type panel in illustrator?
I glanced at the CSS but couldn't find the reason.
Ligatures (nice), better weighting and nicer tracking all around.
Very nice.
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.
I plan on extending the contributing page on the wiki with pull request instructions soon.