Now that browsers support real fonts in web pages and we can license complete typefaces for such use, let’s move past the hype of web type and think pragmatically about how to use real fonts in our web projects. Several experiments with the CSS @font-face property, including some preliminary work with the much-anticipated Typekit, have led me to a single, urgent conclusion: I need to know how my type renders on screens, in web browsers. To that end, I created Web Font Specimen, a handy (free) resource web designers and typographers can use to see how typefaces will look on the web.
Markup-and-style samples for testing purposes are nothing new. You probably already have a go-to resource bookmarked, be it the W3C’s HTML element sampler or something homegrown. Web Font Specimen is very much like the sample files we find or make for ourselves, with two important distinctions: its sole purpose is to exercise a typeface, and it is ours to share.
Web Font Specimen is available under a Creative Commons Attribution 3.0 license. I welcome and look forward to your adjustments, iterations, and improvements. We’ll return to this issue in the context of buying and selling type.
Let’s quickly go over what Web Font Specimen looks like and how to use it. Afterward, we’ll discuss ways of paying closer attention to web type rendering—as well as how this approach will influence type sellers, type designers, and web designers.
Web Font Specimen#section2
Head over to Web Font Specimen, download the .zip file, and preview the HTML in a browser. You should see something like this example. Rendering will vary depending on your setup, but the example specimen should come through just fine (it’s plain old Georgia—most of you should have it installed, and it was designed to look good on screen).
Scroll down and you’ll see Georgia exercised in headings, lists, and with varying emphasis. There’s a body size comparison, different leadings (line-heights), a showcase of glyphs, different measures (widths), different sizes with uppercase and sentence case, grayscale text, light-on-dark text, and, an assortment of color combinations. Reasons for including each of these in the specimen are listed alongside a labeled screenshot at Web Font Specimen.
Fig. 1. Glyphs at 42px.
Fig. 2. Headings, lists, emphasis, and leading.
Fig. 3. Grayscale and color, light on dark.
Kick the tires#section3
Next, you will replace Georgia with the typeface you want to test. See the README file in the download for instructions on how to do this. For additional information, see two of my posts at Nice Web Type—“Where to get web fonts” and “How to use CSS @font-face.”
You may notice that Web Font Specimen is built atop Nathan Smith’s 960.gs, which is a great resource for quick layouts. Just as I have done with Nice Web Type likes reviews, the text.css file that comes with 960.gs has been replaced by one that is more streamlined for our needs.
All that’s left to do is test the result and decide for yourself whether the way your typeface renders across operating systems and browsers is, indeed, acceptable.
What this means for type sellers#section4
Part of the reality of type sellers’ changing business is that they suddenly have a huge new market for their goods and services. Sure, we web designers have always used type in our sites: Replacement techniques, images with alt text, and fonts summoned with CSS have yielded some incredible typographic experiences (these and more are detailed at Typesites). However, we’ve rarely dealt with type the way print folks regularly do, because our experiences in web typesetting have always had more to do with the means than the end.
No more kiddie table#section5
For years, web designers have yearned to embrace typography in its fullest aesthetic and traditional capacities while bringing to bear all that we know about sound markup and universal accessibility. But the nature of our technical means for getting fonts into websites has acted as a barrier to setting realistic expectations for the appearance of web type on screens.
We’ve been so busy getting type into our sites, we haven’t had a chance to figure out why it looks the way it does when it gets there. As a result, web type rendering has largely remained a mystery. Rather than try to sort things out, we’ve simply treated web typography as a lesser art (with some wonderful exceptions), and our grumbles of dissatisfaction have reverberated.
Show us real type#section6
As web designers mentally overcome the print-is-better-than-web inferiority complex, type sellers know that a throng of new customers will expect to be treated fairly when browsing, sampling, and using type. Web Font Specimen is great when the typefaces we want to sample are in our possession. But when typefaces are locked within font delivery services, or behind a type seller’s shopping cart, how will we judge whether they are suitable for use in our web projects?
Type sellers need to provide some way to show the type they license for use with the CSS @font-face property in its actual intended context. They are certainly welcome (cordially and legally invited, even) to use Web Font Specimen as part of a try-before-you-buy experience. I hope they will, and not only because of our need to see how typefaces will look on the web, but because their type adjustments, iterations, and improvements will make Web Font Specimen better. Web designers will be watching to see how type pros think type should be exercised, and we will adjust our toolbox specimen to take advantage of their advice—if they haven’t already done so for us by re-releasing a better iteration of Web Font Specimen.
What this means for type designers#section7
If type sellers are unable to or reluctant to find ways to show their type in context on the web, type designers will not be able to showcase the nuances they have worked so hard to achieve in their fonts. To meet web designers’ type rendering expectations will be a significant challenge. The lasagna of complexity between the beautiful letters type designers draw and the type we all see on websites is largely undocumented and full of variables.
From glyphs to web type#section8
Working through several Typophile threads with folks knowledgeable on the subject, I have tried to envision the gauntlet type must endure on its journey from type designers’ mathematical points and curves to Web Font Specimen’s grid-fitted shapes made of light. Here is my working list of steps, which has been improved with several suggestions and blessed by David Berlow as “pretty good overall.”
- A glyph starts as a bezier-based shape.
- This shape is made in or brought into a font-creation program such as FontLab.
- Settings such as UPM (units per em), key dimensions (for vertical measurements such as x-height, cap height, ascenders and descenders), and metrics (for horizontal measurements such as sidebearings and kerning) determine how the letterform will act as a glyph in a font—e.g., how much room it will occupy at a given size, how close other letters may live.
- Hinting or instructions are added (automatically and/or manually) which can provide directions to conserve the font’s design character in environments where less-than ideal output is to be employed.
- The glyph is exported as part of a font, in either OTF or TTF format (in this context, I am ignoring all other formats—let me know if I shouldn’t). TrueType hints are ditched if the font is OTF.
- The glyph is confronted by operating-system-level and browser-level rendering algorithms. I am still trying to list these combinations for myself. I would want to cross-reference technologies such as Quartz and ClearType with headings such as OS rendering engine, browser rendering engine, result of combination (overrides, any ignored font data).
- User settings in various places (browser preferences, OS preferences) can modify how and when the rendering engines interact with font files. Windows users can turn ClearType on or off. Users can turn antialiasing off altogether. Certain preferences can limit the size at which antialiasing is applied. Listing these variables is another item on my to-do list.
- Finally, there are the physical qualities of a user’s hardware, such as the kind of monitor they use, its resolution, whether they run it at native resolution or not, and their settings for color and luminosity.
Steps four through six are important and must not be overlooked. These factors may be the bane of type designers—especially independent shops. In the eyes of a new audience that will judge typeface quality by on-screen rendering alone, the way a typeface looks across different operating systems and browsers is critical.
Without getting into specifics (let’s save them for the discussion forum), the possible rendering algorithm combinations most often conclude in one of two ways: 1) the rendering engine ignores hints from type designers and does its own thing, remaining as true as can be to typeface design, usually with a good-looking result (this is Apple); or 2) the rendering engine relies upon complex hints from type designers, tries to use that information for ideal readability, and only looks good if the type is designed and hinted to suit this aim (this is Microsoft).
What can type designers do? Well, three things. They can prepare their typefaces to look good across different setups (even though it’s quite difficult and time consuming), they can wage a campaign for type rendering standards, or they can lose business. These are awful options.
Should type designers decide upon something like a Type Standards Project, however, I’m sure they would find skilled advocates and passionate allies on this side of the shopping cart.
What this means for web designers#section9
Already we have read about some roles web designers can play. We must move past web typography’s stigma of subordination by embracing realistic expectations for the appearance of web type and, if type designers think it worthy, we might once again bring change to a situation (typeface rendering on screens) in which standards would help.
Meanwhile, we have to make sure type looks good in our sites today.
If we run our favorite typeface through a copy of Web Font Specimen, test it across browsers, and we like how it looks, then great! That’s the typeface we will use. But what if we don’t like the way it looks? What do we do next? What are our options?
If your type renders poorly#section10
If we (and our visitors) are lucky, we might be able to look for a different typeface that does render well on screen. Despite the foreboding aspects of type design in this emerging market, thoroughly-hinted typefaces already exist that render very well in different situations—and more are on the way. For though many type designers will be disadvantaged by not having the experience or resources to augment their work with fine-tuned hinting, many others will thrive.
Disappointing as it might be at times to have to choose a typeface other than the one we seek, at other times it could be devastating. If your project is entirely dependent on the use of a particular typeface, such as when following brand-based guidelines, we may still be stuck with replacement hacks.
Unless something changes about how many typefaces are rendered across operating systems and browsers—whether that change comes from rendering agents that accept standards of some kind, or from a greater selection of thoroughly-hinted typefaces—these are the realistic choices many of us will face when we decide to use real fonts with @font-face:
- use some kind of conditional logic to serve different typefaces to different visitors,
- allow our type to render in an unsatisfactory way for some visitors, and
- continue using replacement techniques.
Go forth and spec type#section11
To make change, the best thing we can do is argue for a better way by first understanding the challenges we face. To see how typefaces will look on the web, we just need a good specimen. I hope this article and Web Font Specimen make these activities easier and more fun for you, and that you find something of value here and use it to our collective advantage—for the betterment of typographic style and practice.
The biggest hurdle right now are the foundries themselves who, in similar fashion to the music industry, are still caught up in yesterday’s licensing models. I see a huge opportunity here for smaller, independent font foundries to get their fonts online, with Typotheque as an excellent example.
That we aren’t limited to boring old Sans Serif or Arial…
Long live font choices!
@tim
Thanks for this. Nice, nice work. Now I’m doubly glad I added Nice Web Type to the Linkworthy blogroll at Readable Web (where the current post is, apropos, a heartfelt review/recommendation of “DWWS3”:http://readableweb.com/designing-with-web-standards-third-edition/ )
So far, retail font vendors have shown nothing but reluctance to solicit web designers as customers. This is unlikely to change. They are not eager to move from marketing to print professionals willing to pay premium prices to a more volume based model with reduced prices likely to lead – as they see it – to a reduction in the price they can demand of print professionals, as well.
In other words, don’t hold your breath waiting for the retail font industry to get involved and start solving web-related problems. There is little motivation, and time, to do so. All efforts so far, vis a vis web fonts, have been directed not towards opening up a market for web fonts but in mitigating the possible damage to the prices that can be demanded from their traditional base of print-oriented customers.
It’s called self-interest. And it’s just the way it is.
See: “An Open Letter To Retail Font Vendors”:http://readableweb.com/an-open-letter-to-retail-font-vendors/ and comments for a take on how web designers are currently *not* being served in a way that is useful to them.
For a take on how the web design community is viewed in comparison to those in the print community by one of the type community’s leading voices – and someone who has been given a generous forum here on ALA – check out this video interview:
“Web Fonts Week: An Interview With David Berlow Of The Font Bureau”:http://fontfeed.com/archives/webfonts-week-david-berlow/
We face an unbridgeable divide, I fear. But I’d like to be proved wrong.
cheers, rich
this is going to be a fantastic revolution! And a great tool in helping with it but already the site highlights that you should be wary of cross browser issues; as the main body text looks awful in firefox but renders well in ie.
Good luck with the project though…love your work
Thanks, all!
Rich, I saw your Open Letter, and although I share many of your sentiments I don’t think type sellers are as unwilling as it may seem. I’ll be interested to know what it would take for a foundry to implement something like Web Font Specimen. My guess is that the issues are exactly the same as those of licensing fonts for use with @font-face: there is yet no way to protect font files from being stolen outright. If a foundry were to participate in a type delivery service or brew their own a la Typotheque, that’d be a different story. Otherwise, I would not be surprised to hear that many type sellers are already preparing ways to show their wares in web context … as soon as there is 1) greater browser support for WOFF/CWT, and 2) a way to scan for illegal use.
bq. The glyph is exported as part of a font, in either OTF or TTF format (in this context, I am ignoring all other formats—let me know if I shouldn’t). TrueType hints are ditched if the font is OTF.
Given the context, I think you’re confusing ‘OTF’ and ‘TFF’ as a _format_ and .otf and .ttf as _file extensions_. Some types of OpenType font can have either a .ttf _or_ an .otf extension, but still be the same font file inside.
A file with an .otf file extension is an OpenType font. A .ttf file is either an OpenType font _or_ a plain TrueType font. Which do you mean in the above context?
This you may know already: OpenType fonts come in two ‘flavours’. The OpenType format can contain the font data of two separate formats (TrueType and Postscript) and provides additional common properties and functionality. So, an OpenType font can be either, 1) Postscript-flavoured (more correctly called Compact Font Format, CFF-OT), containing Postscript curves and Postscript Type-1 hinting instructions. Or, 2) TrueType-flavoured, containing TrueType curves and TrueType hinting instructions [1].
CFF-OT fonts usually have an .otf extension, and the TrueType-flavour usually has a .ttf extension, but not always. A TrueType-flavoured OpenType font can have an .otf extension [2].
So, “_The glyph is exported as part of a font, in either OTF or TTF format_” is confusing as it could refer to either the OpenType Format font generally (including both CFF-OT and TTF-OT) and plain TrueType fonts, or is referring to just OpenType fonts, CFF-OT and TTF-OT, but not other formats (like plain TrueType). Which did you mean?
To say “_TrueType hints are ditched if the font is OTF_”, is either confused or wrong. If you mean ‘TrueType hints will be ditched if your font is CFF-OT’, this isn’t quite correct. If you’ve developed a Postscript-flavoured OpenType project, with Postscript hinting instructions, but then export to a TTF-OT font, then your _Postscript_ hints would be lost in the conversion. But there would be no _TrueType_ hints to be ditched. If your project is TrueType-flavoured, and you meant the TrueType hints are ditched if the font is TTF-OT, then this is just wrong; TrueType hints are not lost in a TrueType-flavoured OpenType font.
[1] The FontLab manual has a summary of the technical differences between Type 1 and TrueType hinting: “http://www.fontlab.com/fontlab-font-editors/fontlab-studio-8212-professional-font-editor/download-fontlab-studio.html”:http://www.fontlab.com/fontlab-font-editors/fontlab-studio-8212-professional-font-editor/download-fontlab-studio.html
[2] “http://www.microsoft.com/opentype/otspec/recom.htm”:http://www.microsoft.com/opentype/otspec/recom.htm
Brook, thank you! This is a wonderful clarification. (And actually, typophiles may have attempted to explain the same things to me back when I offered up “the list of steps in a forum thread”:http://www.typophile.com/node/60633 … I said at the time that I’d need to digest it some, and again here I need to digest what you’ve shared.
Your explanations and links are extremely helpful.
Yesterday I published “Azbuka CSS Typographical Library”:http://code.google.com/p/azbuka/ and I run into same problem, how to test the library. So I assembled HTML for “Lorem Ipsum Crash Testing”:http://www.allapis.com/Azbuka-CSS-Typographical-Base-Rendering-Library/Lorem-Ipsum-Crash-Test.htm . Web Font Specimen can be great for testing my next project. Thanks!
@Erwin & @Richard
Yes, this transition to allowing font use on the web is a arduous move, but it is happening. It should not be difficult to understand that foundries simply don’t want to put their software completely open and unprotected on a site — and just because browsers now support @font-face doesn’t mean it is appropriate to use immediately”¦ If you want to discuss DRM to help make the foundries feel a bit better, there are no options outside EOT (which no one outside of IE wants to support). Seeing as how customers don’t want DRM anyway, there needs to be a new solution and compromise. Luckily new options are coming just around the corner (& some are already here), new methods to host and render fonts, and of course the new formats — which will finally make most foundries comfortable with web fonts.
“We face an unbridgeable divide” — Richard Fink
This is just melodramatic, silly, and doesn’t help the cause.
“Our foundry”:http://www.motaitalic.com (for one) allows our fonts to be used on the web. Right now this means .ttf and .eot files — eventually we will move to .woff or .cwt when there is support. We offer a special “WEB Fonts” package that comes with pre-made subsetted fonts in several versions to help with download times. It is fairly “low-tech” compared with something like Typekit or Typotheque’s options, but the advantage is that you have the fonts, they can be stored on your server, and you also receive the “regular print versions” of the fonts to use on anything else offline.
@Tim
Nice job overall. Brook is correct with most of his comments but I think they are somewhat overly critical. He has a point with what he says, but the crux of the whole issue I believe is the misnaming of OTF when you are really meaning CFF-OT. OTF is the general term for both CFF and TTF based outlines, they are both in the OpenType wrapper. It is all just confusing because of TTF, OTF, Postscript all having multiple meanings and implications.
Much of what you say should be more acceptable if you simply replace most of the “OTF”s with “CFF-OT”.
Specifically regarding the comment “TrueType hints are ditched if the font is OTF”: Brook calls that confused or wrong. The way he interprets and explains it, that is true. However, I believe you mean to say that if you convert a hinted TTF font to a Postscript CFF-OT then the TTF hinting would be lost — and that is correct. However, it is an odd comment; why would you do that in the first place? Even if we say you were converting a TTF to CFF-OT, you would just run the auto hinter before generating the fonts, same as if you were making a CFF-OT from scratch. No designers are drawing fonts with TrueType outlines, they are converted to TT later. Therefore there is no real native TT development or reason to convert back to PS.
Cheers,
Rob
It’s amazing to finally be able to use alternative typefaces to the ‘web-safe’ fonts we’ve always been forced to use.
I second the suggestion to force browsers to use typography standards, a unified paradigm on type would be fantastic.
@Rob Keller
RK>”We face an unbridgeable divide” — Richard Fink
RK>This is just melodramatic, silly, and doesn’t help the cause.
Too many late nights with the Classic Movie Channel, I guess. I even know who Hermione Gingold is.
But to your points: I’ve visited your site. But my fictional colleague, persona, secret sharer, and sailing companion “Webmail”:http://readableweb.com/an-open-letter-to-retail-font-vendors/ is still confused.
He’s asking why you don’t advertise the availability of web server licensing on the home page? He’s also confused by the line that says “Using our fonts in CSS with @font-face is not allowed.” but yet it then says, a few paragraphs and a scroll later, that “The Web Fonts are licensed on a per-domain basis.”
Webmail is not known for his patience and he says he’s getting a headache trying to figure all this out. Plus, if it’s a commercial PDF you can do this, if it’s a non-commercial PDF you can do that. He says you need to provide a scorecard.
Even though you seem to have made an honest attempt at simplifying things, Webmail can’t figure out how he’s going to use your font without keeping your EULA under his pillow for quick reference and the problem is, he sleeps below deck in a hammock clutching his laptop.
But we both liked your fonts – BTW. Indic fonts are beautiful. Wish English looked that good.
regards, rich
@Rob Keller
RK>”We face an unbridgeable divide” — Richard Fink
RK>This is just melodramatic, silly, and doesn’t help the cause.
Too many late nights with the Classic Movie Channel, I guess. I even know who Hermione Gingold is.
But to your points: I’ve visited your site. But my fictional colleague, persona, secret sharer, and sailing companion “Webmail”:http://readableweb.com/an-open-letter-to-retail-font-vendors/ is still confused. He’s asking why you don’t advertise the availability of web server licensing on the home page? He’s also confused by the line that says “Using our fonts in CSS with font-face is not allowed.” but yet it then says, a few paragraphs and a scroll later, that “The Web Fonts are licensed on a per-domain basis.”
Webmail is not known for his patience and he says he’s getting a headache trying to figure all this out. Plus, if it’s a commercial PDF you can do this, if it’s a non-commercial PDF you can do that. He says you need to provide a scorecard.
Even though you seem to have made an honest attempt at simplifying things, Webmail can’t figure out how he’s going to use your font without keeping your EULA under his pillow for quick reference and the problem is, he sleeps below deck in a hammock clutching his laptop.
But we both liked your fonts — BTW. Indic fonts are beautiful. Wish English looked that good.
regards, rich
*I have no idea what happened to my earlier submit. Looked fine in preview
Dear Richard,
I am afraid your fictional partner/persona baffles me. I will forthwith only be referring to Richard to be more clear.
RE: Mota Italic allowing web embedding:
I appreciate you having a look to our “EULA”:http://www.motaitalic.com/info/legal/eula . It is a bit confusing so we have created a simpler “overview”:http://www.motaitalic.com/info/legal/eula-overview and we are working on some additional pages on the site to help clarify things a bit more. The EULA overview should be able to answer your questions if you couldn’t find them in the full EULA.
We have 3 font versions: Pro, Basic, and WEB. As the EULA states, Pro and Basic are meant primarily for “traditional” use, i.e. “offline” but while also allowing SIFR and FLIR. Those are covered first in the EULA (where it says no @font-face). Then later, Section 5 covers everything regarding the WEB fonts. That is where it states they can be used online with @font-face and are licensed on a per domain basis.
You will find all the information you are looking for somewhere. Admittedly, there is much improvement to be made and many more simple and clear ways to express our policies. We have been open for just over a month now though, and have had many, many other tasks keeping us occupied and from optimizing the current website. We are working on it now though and will have some more answers for you soon.
If you or anyone else has any specific questions for us we are always happy to have a chat and help you out. Just drop us a line at info@motaitalic.com.
Sorry for any confusion.
Cheers,
Rob
PS— Thank you for the compliments on Vesper.
@Rob Keller
You’ve made more of an attempt to bridge the divide than most, and it shows. I say keep going.
All I ask, as a web dev, is for no surprises. Price up front. License up front. That’s not too much to ask, is it?
With @font-face now a practical reality, you and the rest of the font design community are about to begin marketing to the general public.
A true story from yesterday as short as I can make it:
My wife is in an online program for a master’s degree in Nursing. Yesterday, she quoted from one of her books where it said that the two preferred typefaces for nursing papers were Times New Roman and Arial. After my going on for twenty minutes about all kinds of fontstuff, I got to the copyright part.
When I explained to her that if she were to print and widely distribute one of her papers using some other font (or Arial and Times NR for all I know) and wished to do so without legal risk, she could only do so with permission of the claimholder of the font.
She simply didn’t believe me.
When I told her the same held true if she wanted to distribute a custom edition of the Bible, either online or in print, she was even more incredulous.
And when I told her it still held true even if the font used was a recreation of a typeface used hundreds of years ago, she really thought I was pulling her leg.
But, according to those who make fonts, this is all true. Whether free or retail, you are demanding that first, permission be obtained.
This is about as close to claiming copyright on the use of language itself as you can get. No small matter.
And if this is the sweeping scope of the claims being made, I don’t think it’s unreasonable to ask for a high degree of ethics and forthrightness from the font-licensing side of the table.
I am hoping that ten years from now we are all prosperous and, looking back, we will be wondering what all the fuss and fear was about.
Rich
@Rich
bq. You’ve made more of an attempt to bridge the divide than most, and it shows. I say keep going.
Thank you.
bq. All I ask, as a web dev, is for no surprises. Price up front. License up front. That’s not too much to ask, is it? ??
I completely agree. (In our case we try to provide that info in the EULA, EULA overview, FAQ, and on the purchase page.)
bq. With @font-face now a practical reality, you and the rest of the font design community are about to begin marketing to the general public.
True, the potential market is larger and there are new people who will be interested in licensing fonts. And while your example is relevant to a great percentage of the population, it is not necessarily suitable for this discussion. Yes there are millions out there who have no idea how fonts or licensing work, but those people are not going to be going out trying to purchase fonts. At best they will search for a free font site. If they were to come across a commercial foundry and wanted a specific font, they would then be confronted with the implication and requirements of legally licensing them. This is why we have FAQs, tick boxes to say you read the EULA, and customer support. At the end of the day fonts are software, and just like any software you license it and are bound to specific usage terms.
bq. This is about as close to claiming copyright on the use of language itself as you can get.
The font you choose to use has nothing to do with the language of your text (not speaking of the characters included in the font). The font is simply rendering the text. This is no different than if you have a proper license for the text editor you typed the text in.
When will be the day when all browsers support all fonts? Search engine readability plays such an intricate role in web design and creates limitations on what we can do.
When will be the day that a web page will show the same in any browser? Going beyond fonts, tables, margins, and forms all have different outcomes once they are published to the web. Hopefully the future of web design involves universal browser guidelines and function.
Tim-
I want to applaud your selflessness in helping the community develop a standard way to test possible typefaces for web use. I emailed you awhile back crediting you as the creator of screen-based type specimens, and this project certainly drives that idea home!
*FontFont on Typekit*
The task to test possible typefaces for the web is more difficult than I think most imagine. Recently, FontFont, in my opinion one of the better foundries in the world, introduced several typefaces to Typekit. FontFont is made up of a talented group of informed experts, yet seems to have failed to redraw any of their faces to be worthwhile across different platforms when displayed at a size less than heading (display).
Part of the distinction between professional foundries and those creating free fonts is the ability to grasp the subtleties of spacing and form that make a useable body copy font. So, I was disappointed that FontFont was not able to provide styles that work well at body copy sizes for those that do not have Mac’s Quartz smoothing. I have not yet tested the Direct2D smoothing method (the upgrade to ClearType), and perhaps the fonts also work for that small audience as well.
*Typefaces for Screen v. Print*
I have a great deal of respect for FontFont and they may actually not be at fault for the fonts not rendering correctly at body copy size. The fonts they created styles for the web were never intended for the screen. This is an issue I brought up “a few months ago”:http://www.cooper.com/journal/2009/09/shadow_of_the_moon.html and I’m sure has been mentioned before and since.
Say we do reach a point, however, in which there are viable, for-screen drawn typefaces that stand up well across different operating systems and rendering platforms. Should we use your webfontspecimen? Yes and no.
*Formally-Specific Solutions*
Earlier this year Jason Santa Maria (a familiar name) gave a lecture at SVA in which he spoke about differences between print and web design. Certainly, I cannot speak upon Jason’s behalf, but comparisons between “well-designed magazine spreads and webpages that acted as content dumps”
highlighted the idea to me that we often design for the web as if any content could go within a given space regardless of its meaning. (Feel free to correct me on any of this, Jason).
*A Good Type Specimen*
A List Apart readers are likely familiar with that everything I stated in the above paragraph, but may not be in application to type specimen books. There are certainly foundries which merely display waterfalls of their type (descending sizes) accompanied by full character sets. This would be the equivalent of the kind of content dump I believe Jason was describing (except in print, not web).
However, good type specimen books showcase the unique character of the typeface and provide examples of how it could be used. For example, Hoefler & Frere-Jones, a foundry that makes typefaces appealing to many large corporations, has “a slideshow of possible usage”:http://typography.com/fonts/font_overview.php?productLineID=100013 for each one of their typefaces on their website.
Showcasing the personality, uniqueness and intended usage of a typeface is an obvious way to make a good specimen. That’s what makes things like your “Bello specimen”:http://nicewebtype.com/fonts/bello-and-proxima-nova/, with a motorcycle in the background, more appealing, and this holistic solution less appealing.
*A Typographer’s Test*
What you’re presenting to us feels less like a specimen and more like a test. Something people can rely upon to see how their typeface stands up in common situations online. That seems like a good thing. Type is subjective, and good type in one place may not be good type in another, but if your test was thorough — exhaustive in its process — it could end up helping type designers more than anyone else.
bq. Certainly, I cannot speak upon Jason’s behalf, but comparisons between well-designed magazine spreads and webpages that acted as content dumps highlighted the idea to me that we often design for the web as if any content could go within a given space regardless of its meaning. (Feel free to correct me on any of this, Jason).
True, though the two don’t need to be mutually exclusive. We _do_ design websites so that any kind of content can sit on our pages, at least adequately, though I don’t always believe appropriately. The best print publications have that exact same flexibility, basically allowing their design system to adapt when an art director decides it should.
And I agree about most type specimens being cookie cutter waterfalls, but I also see both sides of this. Sometimes, and with some foundries or typefaces, a very vanilla display might be suitable enough. Some foundries might wish to display their typefaces like that because it puts the impetus on the designer: we provide the instrument, you make it sing.
Though, I do tend to prefer the H&FJ; method myself. Context goes a long way for me when I’m looking to buy something. Seeing how someone matches a tie and a shirt together might make me buy that tie rather that just seeing the tie floating on a background of white.
Thanks for the comment!
bq. I was disappointed that FontFont was not able to provide styles that work well at body copy sizes for those that do not have Mac’s Quartz smoothing. […] I have a great deal of respect for FontFont and they may actually not be at fault for the fonts not rendering correctly at body copy size.
This has everything to do with the complexity of type rendering, which I am only “beginning to understand”:http://typerendering.com and which generous experts like Thomas Phinney help explain by sharing things like “Browser Choice vs Font Rendering”:http://www.thomasphinney.com/2009/12/browser-choice-vs-font-rendering/ (a recent post on his blog).
bq. Good type specimen books showcase the unique character of the typeface and provide examples of how it could be used. […] Showcasing the personality, uniqueness and intended usage of a typeface is an obvious way to make a good specimen. […] What you’re presenting to us feels less like a specimen and more like a test.
In my experience, Web Font Specimen is more useful in choosing a typeface for web use than you have inferred here by juxtaposing it with the idea of tailored specimens. In fact, examining the WFS specimen of a typeface has repeatedly given me a better idea of that typeface’s suitability for my project-at-hand than stumbling upon the same typeface in use as I browse the web. Similarly, I doubt its utility would wane if even tailored specimens of the same typeface were as readily available.
That said, you bring up an excellent point. And you’re right to reference both Jason’s thoughts about art direction and H&FJ;’s excellent work (in case you haven’t seen it, read “this post by/about their graphic designer, Brian Hennings”:http://www.typography.com/ask/showBlog.php?blogID=208 and his work).
Tailored specimens are inspiring. If they resonate with us, we discover a hint toward the emotions for which we are actively choosing a typeface other than the ones, “good enough,” that exist at our fingertips. Tailored specimens, like beautifully typeset web projects, breathe life into letters in ways no standard specimen can.
Web Font Specimen provides a benchmark for quality and helps us compare typefaces in common context. Necessarily, to achieve such goals makes it a relatively uninspiring sample … albeit one that our craft, at this time of reawakening, desperately needs.
My hope is that folks who sell type and designers with an eye toward art direction will think, as you have here, about how much more inspirational a type specimen can be. That’s why I encourage folks to take this, tear it up, use pieces, and make it better—and not only the specimen itself!
I wrote this ALA article so as to share for similar dissection the idea of real web type in real web context. Thank you very much for your critique. Let’s continue talking. 🙂
Thank you for your article as well as your contribution to web developers, it’s a relief to know that we can now safely “sample” texts and see their web renderings before committing to buying them. I haven’t had to go through the long and lugubrious process yet since I’ve just begun experimenting with web-design but I’m sure I’ll add web font specimen to my bag of tricks- at least until that glorious day of browser unity and peace comes around the corner.