

Brick. Webfonts that look good - alfredxing
https://github.com/alfredxing/brick

======
makmanalp
Comparison:

[http://brick.im/preview/brick.html](http://brick.im/preview/brick.html)

[http://brick.im/preview/google.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
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?

~~~
Chris_Newton
_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.

~~~
nsfmc
> 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.

[1]:
[http://commons.wikimedia.org/wiki/File:Metal_type_kerning.sv...](http://commons.wikimedia.org/wiki/File:Metal_type_kerning.svg)
[2]:
[http://en.wikipedia.org/wiki/List_of_typographic_features](http://en.wikipedia.org/wiki/List_of_typographic_features)

~~~
makmanalp
Nah, I think they're just enabled here by default to show them off. You can
fiddle with them with CSS3 font-feature-settings properties:
[https://developer.mozilla.org/en-US/docs/Web/CSS/font-
featur...](https://developer.mozilla.org/en-US/docs/Web/CSS/font-feature-
settings)

~~~
alfredxing
In a way, yes. All settings can be controlled through CSS, so tweak to your
liking!

------
alfredxing
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.)

Site: [http://brick.im](http://brick.im)

GitHub:
[https://github.com/alfredxing/brick](https://github.com/alfredxing/brick)

Usage:
[https://github.com/alfredxing/brick/wiki/Usage](https://github.com/alfredxing/brick/wiki/Usage)

------
crazygringo
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?

~~~
bjxrn
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).

Is this just me?

------
bigbento
You can request all subsets to include a font's ligatures with Google fonts.

See:
[https://developers.google.com/fonts/docs/getting_started#Sub...](https://developers.google.com/fonts/docs/getting_started#Subsets)

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
I want to give a big thank-you to the fine folks at Fastly
([http://www.fastly.com](http://www.fastly.com)) who generously agreed to host
Brick on their great CDN network. They're big fans of open source!

~~~
kevinbowman
I think that should be www.fastly.com ?

~~~
alfredxing
Yep. I'm still locked out with noprocrast so while I can add comments, I can't
edit. 5 more minutes...

------
devindotcom
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.

~~~
alfredxing
Is this on Firefox? Seems to be an issue.

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
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?

~~~
alfredxing
Thanks!

Yes, IE <9 doesn't support WOFF (only EOT). For a compatibility table, see
[http://caniuse.com/woff](http://caniuse.com/woff)

------
huhtenberg
Alfred, I applaud the effort, but take a look at the baseline of /w/ and the
stem of /a/ \- [http://imgur.com/O3QoCO8](http://imgur.com/O3QoCO8)

Top is Brick, bottom is GF, both rendered in Firefox 27 on Windows.

~~~
alfredxing
Thanks! Hmm, seems to be an issue. Renders fine in Chrome though, and there
doesn't seem to be anything wrong in FontForge either.

I'll look into it for sure.

------
jejones3141
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.

------
jamiesonbecker
Why do the demo pages have different styling (esp line-height, it looks
like).. makes it harder to see differences in two different windows.

~~~
alfredxing
Sorry about that! It's probably a difference between the fonts served by Brick
and those by Google.

Just pushed the commit, should be fixed now.

------
Buge
On Windows Firefox "Vestibulum" is kerned the same between the fonts. Brick is
a bit heavier and they both user subpixel rendering.

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
Google fonts look better to me (Chrome, Windows)

~~~
richardwhiuk
Agree - especially the uppercase K and the lower case t. (Switching between
between the two tabs in Chrome on Windows 7).

------
cheshire137
The kerning between 'V' and 'e' in 'Vestibulum' is very obvious:
[http://brick.im/preview/brick.html](http://brick.im/preview/brick.html)
versus
[http://brick.im/preview/google.html](http://brick.im/preview/google.html)

------
SimeVidas
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.

~~~
alfredxing
I'll put that in the GitHub usage wiki page.

------
lnanek2
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.

~~~
alfredxing
You can disable swashes with a line of CSS: `font-feature-settings: "swsh"
off;`

Of course you'll need to add vendor prefixes.

------
sogen
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!

------
err4nt
I like what you're doing, anything to improve typography on the web makes the
whole experience better no matter what the design.

Is there any way I can use JavaScript to pick swatches or set options like the
type panel in illustrator?

~~~
alfredxing
The features available in the OpenType panel should also be available through
CSS's font-feature-settings property: [https://developer.mozilla.org/en-
US/docs/Web/CSS/font-featur...](https://developer.mozilla.org/en-
US/docs/Web/CSS/font-feature-settings)

------
jlas
So these are slightly better versions of fonts already on
[https://www.google.com/fonts](https://www.google.com/fonts) ? At first glance
I thought you were offering new ones.

~~~
alfredxing
I chose 10 of my favourite open source fonts; some are on Google Fonts, others
(like Latin Modern) are not.

------
codelap
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.

~~~
alfredxing
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").

~~~
pygy_
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.

------
jbeja
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.

------
noir_lord
Small but significant win for Brick on Chrome (32)/Linux for me.

Ligatures (nice), better weighting and nicer tracking all around.

Very nice.

------
cfjedimaster
I thought you meant this first -
[http://mozilla.github.io/brick](http://mozilla.github.io/brick).

------
ezequiel-garzon
If I understand correctly, Google Fonts may be used in commercial websites.
Does the license vary between different fonts in this case?

~~~
alfredxing
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.

------
greytwo
How does one incorporate this into a webpage?

~~~
alfredxing
Usage is at
[https://github.com/alfredxing/brick/wiki/Usage](https://github.com/alfredxing/brick/wiki/Usage)

------
krick
Cool. But how does that stuff work? Are there any "typefonts for dummies"
materials?

~~~
alfredxing
A reference for custom fonts via @font-face:
[https://developer.mozilla.org/en-US/docs/Web/CSS/@font-
face](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face)

------
guanche
As far as I can see; iOS renders it just fine in both implementations

~~~
noir_lord
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.

------
kbar13
cool! how do I request additional typefaces and/or contribute?

~~~
alfredxing
For now, open up an issue on GitHub.

I plan on extending the contributing page on the wiki with pull request
instructions soon.

------
bdcravens
Name reminds me of Designmodo's "framework", The Bricks:

[http://designmodo.com/the-bricks-addons/](http://designmodo.com/the-bricks-
addons/)

