Posted on

Wide Open Faces: Choosing Fonts for Your Website, eBook, and Mobile App

I’ll be leading a session on font selection & usage at the 2010 MIMA Summit next Tuesday afternoon – Sept 28th.

As you can see from the title – the goal is to get beyond ‘web fonts’ and talk about all the different artifacts we publish and the benefits and challenges of using custom fonts consistently across the board.

Should be fun.

Update – Here’s the presentation:

Posted on

JustType.de's Kernest.com Interview With Garrick

Sebastian Brink from JustType.de interviewed me about Kernest.com. I took the opportunity to spell out some of the principles guiding Kernest’s ongoing development.

I’m taking the liberty of re-posting this here for archival purposes.


What is Ker­nest? What do you do?
Ker­nest is an font direc­tory and web font ser­ving engine. The web font ser­ving por­tion is powered by the open-source Fontue web font server.

When did you begin to work on it?
I wrote Kernest’s foun­ding docu­ment: ‘A Pro­po­sal to Create the YouTube of Type­faces’ in March of 2008. Then, after a sum­mer of con­ver­sa­ti­ons with type desi­gners and web desi­gners, I map­ped out how I wan­ted it to work and star­ted buil­ding toward a mid-July 2009 launch.

How many sites are using Ker­nest right now?
Ker­nest ser­ves thousands of fonts each day. Desi­gners can also down­load fonts from Ker­nest to host them­sel­ves. The @font-your-face Dru­pal module also pro­vi­des easy access to the fonts wit­hin the Ker­nest via Kernest’s API.

How many font fam­il­ies are cur­rently available?
As of July 2010, Kern­est offers more than 1200 indi­vidual fonts across more than 230 families.

What part of Kernest’s deve­lop­ment have you found to be the most problematical?
One of the big­gest oppor­tu­nities I see is making it easier to find the right font. This pro­blem isn’t uni­que to fonts on the web. It’s not even uni­que to fonts. Fin­ding the right photo, color, lay­out in a world where there are thousands of good opti­ons is a challenge.

Are you working toge­ther with type found­ries or font desi­gners to pro­vide their fonts via Kernest?
Abso­lu­tely. Chank Die­sel has been a huge sup­por­ter Kernest.

I’m always open to working with desi­gners and found­ries to make their web fonts avail­able, whe­ther through Ker­nest or working with them to set up their own web font ser­ver. Ear­lier this year, I open sour­ced Fon­tue, the font ser­ving engine power­ing Kernest.com, under the X11/MIT license in an effort to make it easier for com­pa­nies, found­ries, and desi­gners to set up their own web font servers.

How do you pro­tect them from pir­acy of their fonts?
Tra­di­tion­ally, foundries and font design­ers wrote up their own, dis­tinct license on how their work could and could not be used. More often than not, those licenses expli­citly excluded web use and redis­tri­bu­tion. Kern­est cur­rently recog­nizes 63 font licenses ( http://kernest.com/licenses ), of those, 5 (OFL, GPL, X11, Cre­at­ive Com­mons Attri­bu­tion, Apache) are pre­ferred. These 5 licenses — and a few oth­ers — allow design­ers and developers to main­tain freedoms — redis­tri­bu­tion, modi­fic­a­tion, unres­tric­ted use — that may be con­sidered ‘pir­acy’ in other licenses.

My con­ver­sa­tions with font design­ers have con­firmed that obscur­ity is more of a con­cern for their work than ‘pir­acy’. For some more writ­ings on the obscur­ity vs. pir­acy issue, I highly recommend:

Lastly, from a tech­nical stand point, Kern­est and Fon­tue are archi­tec­ted to con­serve band­width by only serving fonts to web browsers sup­port­ing @font-face.

Do you think “free” fonts often lack in qua­lity com­pa­red to retail fonts?
Every font has a range of appro­priate use. For some fonts – like a huma­nist sans serif — this range is wider. For other fonts — like Chank’s recently released CoCo Flower­font — that range is narrower.

The bene­fit of openly licen­sed fonts (vs. sim­ply free fonts) is that desi­gners have the free­dom to modify a font to make it more appro­priate to their pro­ject. These modi­fi­ca­ti­ons could be twea­king exis­ting gly­phs to bet­ter match a design, crea­ting new gly­phs, or adding a new weight or style to the family.

For more on this, I highly recom­mend lis­ten­ing to my pod­casts with David Cross­land and Ben Weiner:

Not every font works that well on the screen. How do you decide which fonts to include into the library?
It’s very simple.

I read the font’s license to con­firm that it sup­ports web use and redis­tri­bu­tion (and hope­fully com­mer­cial use). Ide­ally, the license is one of the 5 pre­fer­red licen­ses I men­tio­ned earlier.

After that — I ima­gine if a web page set in that font would make me smile. If so, I run it through Kernest’s font opti­miza­tion engine and add it to Kernest.com

Many of these fonts, I’ve cha­rac­te­ri­zed as ‘web native’ — meaning they have let­ter forms with large x-heights and open coun­ters and are openly licen­sed. More on Web Native fonts in Ker­nest — ‘Web Fonts – Identifying a New Species’ and Kernest’s ‘Web Native’ style tag

Some web­fonts have a much smal­ler x-height com­pared to usu­ally used fonts like Arial. If you define the font-size based on the web­font this will res­ult in a much lar­ger font ren­der­ing if the fall­back font from the stack is used. In this example the x-height of the Rabio­head font is much smal­ler com­pared to Arial and it’s barely read­able. I noticed that this is not the case with the fonts I tried from Kern?est?.com, Tit­il­lium in the example. Are you doing any­thing to equal the x-height of the fonts?
Cur­rently, Kern­est doesn’t modify the let­ter­forms of the fonts. Though, fonts with thin serifs, small x-heights, or high stroke con­trasts may not be con­sist­ently read­able onscreen, it may be the appro­pri­ate choice for the over­all design. If the fall­back is used — that most likely means the browser don’t sup­port a num­ber of web tech­no­lo­gies that will impact how a web­site is presen­ted — not just the @font-face declaration.

I encour­age design­ers to design the most appro­pri­ate exper­i­ence for all of a site’s vis­it­ors. Some­times that means design­ing very dif­fer­ent exper­i­ences for dif­fer­ent browsers and devices; increas­ing but­ton sizes for touch inputs, dif­fer­ent lay­outs, and spe­cify­ing different fonts.

What else are you doing to improve the font ren­de­ring? Spe­ci­fi­cally about the font ren­de­ring issues in dif­fe­rent browsers?
The bulk of the ren­de­ring issues across brow­sers are at the ope­ra­ting sys­tem level. The brow­ser can only ren­der fonts as well as the under­ly­ing OS can. Some brow­sers still don’t sup­port @font-face (Android, Kindle — just to name 2). Devices with web brow­sers are get­ting incre­a­sin­gly diverse, from my per­spec­tive — good web design pro­vi­des the most appro­priate pre­sen­ta­tion for a given devices capa­bi­li­ties. Some devices sup­port more appro­priate fonts, other don’t.

Some deve­l­o­pers are con­cer­ned about the relia­bi­lity of font ser­vices. What will hap­pen if your ser­vice goes down? What’s your response to this?
As I men­tio­ned ear­lier, desi­gners and deve­l­o­pers can down­load fonts from Ker­nest to host on their own servers.

What about the future of Kern­est? If an embed­dable font format like WOFF will become a stand­ard on all browsers do we still bene­fit from using Kernest?

Kern­est has served WOFF files to Fire­fox for quite some time now (since October 2009) and cross-browser font format com­pat­ib­il­ity is just one of the con­veni­ences Kern­est provides. There are a num­ber of ongo­ing pro­jects related to Kern­est in the works. There’s still lots of work to do in web fonts.

Now that desi­gners can use custom fonts on web­sites, what will be the next step to sophisti­ca­ted typography?

I fore­see the deve­lop­ment of web-native typo­gra­phic styles.

Posted on

Initial Thoughts on Google Offering Droid for @font-face Use

My initial thoughts on Google offering a hosted version of Droid:

This is more an extension of their mobile play than getting into the font hosting.

    Here’s why:

  • The Android handsets only display the Droid family of fonts.
  • Google’s stated a number of times they’re serious about being successful in mobile.
  • Google is a web app company – not a native-software-on-the-device company (i.e. Apple, Microsoft).
  • By offering a hosted version of Droid – they’ve made it much easier for their internal teams to simulate what their web apps (i.e. Google Docs, Calendar, etc) will look like on Android devices w/o needing to actually use a phone.

Of course, I reserve the right to change my position when I see Google hosting something other than Droid. :)

Update – I’m now changing my position :D
This guide explains how to use the Google Font API to add web fonts to your pages. As I mentioned on the Kernest blog – this is a huge win for openly licensed fonts.

Posted on

Fontue Font Optimization Workflow – Open Sourced

With the Fontue web font server open sourced, I’ve done the same for the workflow scripts I use to to generate the fonts for @font-face use.

It’s a pair of scripts that pipe fonts in and out of other conversion programs like FontForge, sfnt2woff, Batik, and EOTFast. Along the way, doing a little clean up of the font file itself.

These workflow scripts are now included in the Fontue source code.

Posted on

Kernest’s Web Font Serving Engine – Fontue – Now Open Source

I’ve talked to a number of people and organizations that want to start adding web fonts to their websites – but aren’t comfortable relying on a third-party service for something so integral to their online presence.

With that in mind, I’m pleased to announced that Kernest‘s underlying web font serving engine – dubbed Fontue – has been released under the MIT License.

Fontue is designed to be the lightest, fastest way to serve web fonts to @font-face supporting browsers while saving bandwidth and keeping CSS clean and readable.

Get more information at Fontue.com or download the latest version from Github.

Posted on

How to Make Safari Render Pre-GZipped Web Fonts

After too many sleepless nights, I’ve finally got Safari to render pre-gzipped fonts.

All the fonts in Kernest are pre-compressed on the server (in addition to saving a little bandwidth, it also saves a little disk space and a couple hairs of server performance).

I started with this post by Darren Rush on how to configure Apache to send pre-compressed files, rather than compress on the fly.

While most browsers don’t care if the server does the compressing or if the files are compressed ahead of time. Safari does. Particularly with front-end-oriented files like javascripts, stylesheets, and fonts.

If you take a look, Darren’s code – it ignores Safari (RewriteCond %{HTTP_USER_AGENT} !Safari ).

Turns out Safari just dislikes the idea of javascripts, stylesheets, and fonts using the ‘.gz’ extension.

Yep.

Pre-compress your files – just don’t name them ‘.gz’.

“you CAN’T use the ‘.gz’ extension when serving compressed CSS or JS files to Safari. It knows how to handle gziped files, as long as they don’t have the ‘.gz’ extension (it’s just that weird :)” – sopppas

The convention seems to be ‘.jgz’.

This change is fine – because all reasonable browsers look at the content-type and not the file extension. Unfortunately, the really fast Apache mod_sendfile module doesn’t pass content-type. Now those reasonable browsers now have no idea what they’re getting.

In my testing – the smaller file (~40% savings) and slower serving method is still faster than the larger file size and the faster serving method.