Proxima Nova makes one hell of a good web text face.

Word.

The headline type looks good. The rendering of the Proxima Nova text is terrible (Windows, Firefox). This is, as Si Daniels put it, the 'elephant in the room' that no one is talking about: fonts look different in different browsers and on different platforms, and once one strays beyond well-hinted TrueType the quality can vary immensely. A font that looks good in one browser on one platform may be almost unreadable elsewhere. This is something that would-be web typographers are going to need to anticipate and test.

The so-called 'web safe' fonts like Verdana are safe not only in being installed on almost all computers, but also safe in the sense of being readable under a wide variety of different rendering systems and browsers, i.e. they are safe in a way analogous to web safe colours.

Scrolling presents occasional missing bottom parts of some lines:

Excellent point, John. I'm cooking something up to help web typographers with that....

I noticed that too Craig, thanks for showing others in case they didn't notice. It's a pretty big annoyance and it affects legibility – especially for a geometric sans like Proxima Nova.

his is, as Si Daniels put it, the ’elephant in the room’ that no one is talking about: fonts look different in different browsers and on different platforms, and once one strays beyond well-hinted TrueType the quality can vary immensely.

Something that’s been on my mind lately is that Microsoft needs to rethink how it helps type designers with designing fonts that will render well on Windows. I realize that there’s already a great deal of information, and VTT, available to us at Microsoft.com. And I realize that there are some strong arguments in favor of manually-hinted TrueType fonts with deltas for different sizes. But wading through the documentation and the software is not easy and takes a lot of time, especially compared to Adobe’s autohint-it-and-forget-it approach. Something along the lines of Using Fontlab to hint TrueType fonts for use on Windows for Dummies would be a really big help right now.

Wrong way, James.
Apple gave proof of concept that type can be rasterized in readable way ("Proxima Nova makes one hell of a good web text face."), and it does not matter if your font is TTF, CFF-OTF, hinted or not. I am particularly unfair now, but compare an unhinted TTF rasterized in Windows and in OSX. In Windows, with standard greyscaling you get a washed-out grey at text sizes (the thing Windows users blame OSX rasterization of) and with ClearType rasterization your horizontals cause problems at text sizes. Not so in OSX -- there you can even recognize the original design.
There's nothing wrong with fonts. Something's wrong with some rasterizers.

With @font-face and arbitrary fonts rather than a handful of especially adjusted fonts, perhaps Windows users will come to appreciate Safari's own rasterizer?

Karsten, I agree with you, but I doubt we’ll see Microsoft rethink it’s rasterization strategy any time soon, and I don’t want to start another argument about it. But if MS is going to dump TrueType hinting on tyoe designers, it could at least do a better job explaining things to a gang of Mac enthusiasts.

Microsoft needs to rethink how it helps type designers with designing fonts that will render well on Windows.

Right on James.
But don't blame type designers for not being up to speed on the technology.
It's Microsoft's business model that's to blame, which leads to complex technology that optimizes the performance of its own font solutions, to the detriment of the majority of font producers who don't have its margins of scale.
Apple, on the other hand, makes everyone look good.

It looks crappy in any browser i'm running on WinXP. I get descender clipping, fuzzy type, &c. Different issues in Safari and Firefox. So are designers going to start creating websites for Mac users only?

So are designers going to start creating websites for Mac users only?

No, but I expect that web designers will very quickly find that some of the fonts they want to use for text are only going to be worthwhile if they want to pay for custom work. Which might happen now that there will be some working cross-platform web font solutions. Even with custom font work big web campaigns will still be less expensive than running print campaigns.

I can see the bello and PN in safari - not in firefox. default font in firefox - am using the latest version. any idea why?

I can see the bello and PN in safari - not in firefox. default font in firefox - am using the latest version. any idea why?

Joshua, I've seen that as well on some machines running the latest FF 3.5 (not a beta). No idea!

It looks crappy in any browser i’m running on WinXP. I get descender clipping, fuzzy type, &c. Different issues in Safari and Firefox. So are designers going to start creating websites for Mac users only?

Paul, the descender clipping is an issue the Typekit folks have told me they're looking into. Might be correctable. However, your question about whether web designers will design primarily for Safari users (or Mac users) and let other folks "see what they see" ... that is an excellent question. More people need to be concerned about this.

The CSS disparities between Safari and other browsers are so monumental, and it is so tempting to think only of Safari, that unless other browsers start catching up fast ... well ... Joe Clark is going to have to write another book about the value of accessible design. And why not to design solely for one's most ideal visitors.

Using Fontlab to hint TrueType fonts for use on Windows for Dummies

1. Set up PS style blue zones to control vertical alignment and overshoots; be sure to provide blue zones for anything that you want to align.

2. Apply FL auto PS stem hints, Adobe FDK auto PS stem hints, or FL manual PS stem hints to glyphs.

3. Set PS standard stem values to average stem values; typically, you want just a couple of values for x and y stems capturing the main vertical stems for I/i and the top or bottom section of the O/o.

4. Make sure that TT generation exports are set to autohint unhinted glyphs; this autohint function will make use of the blue zones, stem hints and stem values that you have set up in the font.

5. Generate font and install.

ClearType handles this kind of hinting pretty well for most Latin font styles. Greyscale antialiasing in Windows will not look as good, although the alignments should be fine. Black and white rendering will not be good, but still the alignments will be fine.

Amazing. All that, just to have a vector outline look less horrible when forced onto a grid of pixels.

This doesn't have to be done at each possible font size, does it? Instead, the "hints" are like educated guesses helping rasterize a font in a relative way, right? If so, that's probably why web designers notice that a font that looks great at 13px looks oddly fuzzy and uncoordinated at 15px. Its hints might not be lining it up as well at 15px because the combination of hinting instructions and available pixels might not be as suitable (as the same hints at 13px).

Amazing. All that, just to have a vector outline look less horrible when forced onto a grid of pixels.

Actually, alignment zones and standard stem widths are a pretty good infrastructure for designing and building a typeface.
When teaching type design to students in a graphic design course, I've found that explaining the principle of alignment zones prioritizes the importance of x-height and extender length, as well as the function of overshoots.
This does tend to homogenize letterforms, however.

Also, I wonder if desktop publishing and the ensuing emergence of the Internet would have played out quite as broadly, had it not been for adequate screen representation of type through global hinting. And that began with TrueType, with ATM being developed and released in a rush by Adobe, which saved Apple. So you could say that alignment zones and stem hints are fundamental to the digital graphic culture we now have.

Nonetheless, a lot of the new typography of the digital era, that got the indie font scene started with grunge and deconstructed type designs, studiously avoided this kind of thing, despite the fact that Fontographer had the necessary hinting tools.

Nick, Fontographer did not have the necessary hinting tools for TrueType. It performed a pretty crude PS to TT conversion, and the results were never very good. Also, bear in mind that the kind of semi-automatic approach I described above -- which is very short of what one can achieve with manual TT hinting in FontLab, and very, very short of what one can do in VTT -- depends on the latest anti-aliasing models. With b/w and greyscale rasterisation, the results are not nearly so good.

FontLab's auto hinting for TT is pretty smart, and the nice thing is that it makes use of whatever level of information you put into a font, as I explained above. You can go further, and convert the PS stem hints to TT instructions and manually edit them, and you can do this for individual glyphs, letting the autohinting look after the others.

However, there are things you need to look out for. If your font contains zero-width glyphs with outlines, such as combining marks, FontLab will round these off the origin point at some sizes, causing the width to explode. In that case, you need to convert the PS hints to instructions and manually remove the links to the origin point.

@tim and all:
In light of the ins and outs of creating a screen-readable cross-platform, cross-browser font (thanks for the mini-lesson, Nick, John, etc...), your page looks very good, Tim.

I know I've commented on this before, to no avail, but it would be great if you would take the time to create EOT's for these examples. Ascender has just released a tool for creating these "DRM-Free" EOT Lite files. (Haven't gotten my hands on it yet. But I'll have it shortly.)

To be pesty about it: your answer to me, on this site, was that you'd prefer to let Typekit handle IE. Well, Typekit is now in Beta preview, I will look to see if these fonts are available. But what if they aren't?
Your examples would be more effective if they were more inclusive. If your intention is to advocate, and that seems to be your intention, I don't think there's a single site among the Alexa top 1 million that would even dream of excluding IE in this manner.
Just me 2 cents...

Cheers,

Rich

To just build on what Nick wrote... Yes, the age-old PostScript font hinting model is really one of the miracles of the desktop publishing age. John Warnock had to think up a way to get letters to look good at low resolution, because Adobe would have crashed and burned without it. So he came up with the appropriately-named font "hints". They just provide general information about font and glyph features which can be interpreted by any rasterizer. It's a very practical approach -- even today, when we're coming back around to "medium resolution" environments (high-res LCD screens and such) which became largely irrelevant in printers years ago, but were the primary concern in 1984.

One can look at all this and say, "So much technological complexity for something as simple as type!" or one can acknowledge that building digital fonts has always been a task for knowledgeable and skilled professionals -- for whom good ol' Type 1 hints are fairly straightforward, and an easy way to ensure a digital font is something better than a plain rasterized PostScript path.

I did some extensive TrueType hinting back in the day, and it was brain-numbing but very cool in its way. I don't mean to disparage that approach -- but I think everyone knows it's a lot of work, and difficult to apply to every font that comes down the pike.

By the way, I am on OS X/Safari, and Proxima Nova looks very nice!

This is how the Proxima Nova on this page looks to me:

I consider this unacceptably fuzzy and of uneven stroke density for text readability, quite apart from the clipped descenders.

Yeah, that doesn't look so great there.

>I’ve seen that as well on some machines running the latest FF 3.5 (not a beta). No idea!

Search previous threads on ’vertical metrics’ or “chopped off”.

> you could say that alignment zones and stem hints are fundamental to the digital graphic culture we now have...
Nick... I and other designers want to add the intra and inter glyph white-space to that fundamental list to make possible an end to typographic “x abuse” (we see a lot in this site). But the two main owners of TT/OT think the list is long enough at 2 things, alignment zones and ’page color’. And though ISO, the web’s users, and I ’want it’ otherwise, “type scaling” is set up that way by MS and Apple. Though all of the technology to handle readable web type exists, basically “it’s resolution’s fault” that you can barely ever have optimal quality for your needs.

Then, One could say that this web site’s apparent use of @font-face suffers from low resolution typographic x abuse the site developer has absolutely no control over with these or most outline fonts, now or ever.* And the site suffers @font-face abuse from the user’s perspective. I.E. the definition of the top 3/4 of the page as 2 assets, for the foreseeable future, does the user absolutely no good in transmission speed, and may in fact end up with that lovely script text appearing as Verdana, likely doing the publisher of the website nearly no good. Render unto pixels, that which is their due.

That covers text and display type on this type. But the sub heads, they are very nice and I like the color scheme.

@Hudson> This is, as Si Daniels put it, the ’elephant in the room’ that no one is talking about.

Thanks John for repeating a not entirely completely untrue statement. Since 2004 when the final hinting/fontformat/OS environment was being described for its eventual 2007 release from Longhorn into Vista, I and quite a few others have never called this issue an elephant in the room. ;)

Otherwise, “web text readability” has been a rather huge topic here and elsewhere. Search on that instead of ’elephant’ if anyone is interested. The fact that learned type people are supposing an emergency availability situation, and are supporting a new font format to utterly exacerbate the beast raw into a naked and raging elephant, is what surprises me.

>The so-called ’web safe’ fonts like Verdana,

...are, as John correctly points out, safe by availability and by contour design, and at 13ppx Verdana is particularly safe because it was drawn to fit that size, (delete the hints and it works about the same at 13, when anti-aliased). But mostly, web safe fonts are safe simply from their original selection as part of a class of published digital outlines to accompany everything; as Courier, Times and Helvetica (et al), are familiar enough for users to “fill in the blur” of the bad sizes, they just barely work. While Verdana et al are by contour design, made to minimize the blur by maximizing critical font-wide type design features, also in familiar forms people are used to.

>...I’m cooking something up to help web typographers with that....

I call help, ’recommendations’. When taken from groups of fonts, a data-base of recommendations will provide a web typographer with a ’ball park’ to start testing, or just go with the recommndation, for any particular use. I’d love to see what you cook up but people think adding this meta data to the OT font specification is the quickest and only way to begin addressing web text readability education on the scale required.

>...Microsoft needs to rethink how it helps type designers with designing fonts

See what happened on this forum when I quested for a clear cleartype specification in ’05? Search on “giant pile of excrement”, as far as I recall.

>I realize that there are some strong arguments in favor of manually-hinted TrueType fonts with deltas for different sizes...

You must mean Variations for different sizes. :) Deltas, they may be, that term has been demonized to an evil size-specific blot. Search on “Superpolator”

Cheers!

*Unless e.g. you set your OT/@FF-friendly browser’s text size to medium, then go to:
http://www.fontbureau.com/test/franky/
...there you can futz with the site’s typographic size and weight controls outside of the evil grip of everyone but me and some of my crazy ideas for “elephant training.”

Remember, set your OT/@FF-friendly browser’s text size to medium, set your OT/@FF-friendly browser’s text size to medium. Don’t forget, set your OT/@FF-friendly browser’s text size to medium.

Also: You can steal these fonts now if it suits you. Or you can wait, and steal better ones later. Or you can wait until the new font wrapper everyone is so hot for, is thoroughly undressed by time as it surely must be to be accepted, and then you can steal these fonts from that format. See!? Lots of choices! Sorry for the L.P.

Franky is impressive.

Does it have a serif companion?

Thanks, gferreira and Yes, there is a serif, but it is not to be so small. I'll tell everybody when and where one can start licensing the serif font in the raw naked undressed OT format soon. ;) Our plan is to give away all sans fonts, because they are so simple, but (I'm) to charge a vast fortune for licenses to (just) serif faces (kidding;)

This demo is 'even better than bitmaps' down to the bottom sizes, perhaps? and this is what elephant-aware type designers assumed (1994-98), then hoped (1999-2007), but now can only wish user's type looked like down to small sizes. Momma Apple and Daddy MS didn't get along on the TT/scaler/rasterizing-thingy, with each other, or with type's more industrious developers, and uncle Adobe didn't care then — so now, they get most of you design types, ISO, W3C and the biggest text-composing user-community, quality-puzzled. I get the rich who need solutions ahead of most other users, which might sound vile to you, but it makes this time possible. Speaking of which...

Franky and the type it produces, was a 2007, 31-day, 45-style, font lab beating on a demo agate for screens to counter the contention that there is no alternative to the 'well-studied' OS-default scaling techniques when deployed via default web font-sizing and then applied to small font sizes on computer screens. If type developers (e.g. me), can't control completely enough, the size-specific x dimension variation via hinting because of MS' scaler, e.g., and can't give users size-specific x dimension variation via any other means besides changing the contour, font name and forcing its use at only one ppm size, then that's what I had/have to do. It allows me, as I explained to Greg Hitchcock at Sota Seattle, to avoid all the format, scaler, rendering and web composition barriers to type quality — all I need is a baseline, a pixel-per-em, (a tiny user interface, @font-face and repeated warnings to set your browser to the medium fonts size, which I didn't have then, but I have now), and I can undress CT and Quartz quality for this purpose.

One sub-thing I also had to deal with, as your exploration of Franky benefits from, was people saying 'it's too light' or 'it's too heavy'. This has nothing to do with the detailed problem at hand, while having everything to do with the general problem at hand. Thus one can play with the text weight in this demo, but with a severe limit on the expansion of the text as the goal. Smaller sizes could get heavier, but as each pixel becomes proportionally larger at small sizes they would get really wide, so the smaller sizes don't get really wide in this demo, and some sizes get too tight.

If a lot of people agree on this realm of quality for small sizes (8-12 ppm), then we can move on to the middle sizes (13-26), where less of the same thing is required but variation for size is still required. And if everybody agrees then that text and agate is better this way, then much less of this kind of work and much more kerning, is required for display types. So, don't get me wrong, it's not all the scaling OS' fault, that browsers are just not OT-table-aware enough yet is clearly an up-n-coming issue.

I'm reminded always to remind you, with the PERM table, (unless it's called EPAR), part of this elephantine issue can be addressed. Without EPAR, there is little chance, in my humble opinion, of anything but a typographic idiocracy followed by more generalized idiocracy, far more idiotic than we now have. I don't think a few billion computers not knowing what year it was, was a problem compared to this. Back then, we all knew what year it was, and if not we could pick up a newspaper and (delighting subliminally in the quality of the text), read all about it. :-)

Cheers!

No sure I get this. The only browser I can get Franky to show up in, is Safari, and when the antialiasing is set to Windows Standard, I cant get anything to look good. If I set Safari to use Mac rendering, it is just like any other font rendered without hints.

David, can you post a screenshot of what Franky is supposed to look like? Like your best shot?

I answered Mike's excellent point directly. But don't forget, I'm not trying to solve the quality issue this way, it's way too hard on type and web designers, not to mention getting end users away from W3C's horrible font sizing solution. I'm just trying to display the quality issue in the only way I know that 'everyone' can see it on their own screens in the comfort of their own OS, rendering, size and weight preferences. This is just a test, but thank you @fontface.

Cheers!

Here is another example of a ppem-specific screen typeface design. (It works in Firefox and Safari on MacOSX)

David, following your PERM proposal, how would you set the "Scaling" recommendations for a design built on a 13ppem grid, but delivered as a CFF font with 1000 upm, to be used at 8px size and its multiples? :-/

I feel the need for a field to say how many emUnits correspond to one pixel, but maybe I'm just doing something wrong.

Does the emUnits/pixel ratio change across the different sizes of Franky, or is it constant?

Thanks!

I love the proxima and bello combination!

Here is another example of a ppem-specific screen typeface design. (It works in Firefox and Safari on MacOSX)

And doesn't work -- at least not in any way that is readable -- in Firefox on Windows Vitsa:

David: I’m just trying to display the quality issue in the only way I know that ’everyone’ can see it on their own screens in the comfort of their own OS, rendering, size and weight preferences.

Is there some way in which I can see the Franky test in Firefox on Windows? I went to look, but get my default browser font instead:

Also on Windows here and I get the same result as John in Firefox, but (seemingly) the correct 'Franky' font with Safari.

Ironically, in light of this...

In downloaded and installed Safari for Windows, then took myself off to the Franky test page. I had about three seconds in which to look at the nice typeface, and then my entire system crashed. Blue screen of death crashed.

Maybe I'm hysterical because of the heat, but I found this very, very funny.

I'm going to try it again now. Wish me luck.

Phew. No crash this time. I'm willing to blame something other than Franky for the previous experience.

This is what I see:

1. Franky left, Verdana right, with Windows 'Standard' i.e. non-CT smoothing:

.
2. Franky left, Verdana right, with Windows Cleartype smoothing:

.
3. Franky left, Verdana right, with Safari's own smoothing:

This is weird: if I use the little minus button on the Franky test page to reduce the size of the text, the CT display of Franky looks much better, and I wonder what is the 'correct' size, but the linespacing massively increases (but not for Verdana). However, if I switch to Safari's full fuzz rendering at this size, the linespacing reverts to the normal tighter spacing; back to CT and it increases again. Funky, Franky.

And doesn’t work — at least not in any way that is readable — in Firefox on Windows Vitsa.
Yes, but I think this can be fixed. To be continued...

>Maybe I’m hysterical because of the heat, but I found this very, very funny.

I bet not nearly as funny, to me, as sitting at 144 dpi with a yellow background waiting for a new aesthetic. ;) Does that help cool ya down? I just heard yesterday that the NW is baking, and I hope it passes soon, in the meantime, it's funky, raw, and naked time.

>Does the emUnits/pixel ratio change across the different sizes of Franky, or is it constant?

It changes, because the units per em was kept constant. This is not important unless something does want to react to pixels per units, as the Perm table, and my proposed Size table are designed to slightly enable.

>David, following your PERM proposal, how would you set the “Scaling” recommendations for a design built on a 13ppem grid, but delivered as a CFF font with 1000 upm, to be used at 8px size and its multiples? :-/

The first half if easy, but why exactly would one want to deliver for the wrong size? I.E. if it's for 13 ppm, it should not be used at 8, 16 or 24?

Tomorrow, I'll try to republish the expanding list of requirements to make Franky Quality happen, hopefully without Franky Quantity ;)

Cheers!

Updated.

I can’t see modular serif b actually getting used as a text face. It’s heavy and chunky which makes letters glob together at text sizes. The tight, uneven spacing makes matters worse. What’s really annoying is the way that s always appears to be dry-humping the next letter, this really mucks up the rhythm of the text.

Your test now appears to render correctly, Gustavo. Can we see a specimen with black text on white? And some actual text?

This looks nice Gustavo, but it is unreadable for me at least, beginning in the design; much of the 'shape contrast' (e.g. between the truly round 'o' and the mostly square 'n'), has been eliminated, (for the sake of simpler rendering?). It's nice for display though, as it is...

Cheers!

Rendering of Proxima Nova and the other fonts look good for me (running Windows Vista + Firefox 3.6). And my captures look different than John's ones. Probably this is due to some update Firefox got in between, as the other posts have some months now:

.
If the improvement in rendering is due to a Firefox update, this is a good new. Anyway, there are fonts in TypeKit site which render poorly in my screen:

It's because Typekit has made improvements since this discussion first started. I don't think the browsers are doing anything different.

Mark, what style is to be the "Bold" of Proxima Nova's Regular?

Cheers!

Proxima Nova Bold.

It looks like it's the same width as Regular, as though it was a "grade" or 'duplexed'...

Cheers!

It's not. Do you have a link or something so I can see what you're looking at?

Oup! nevermind, I was looking at http://www.ms-studio.com/FontSales/proximanovacond.html, and seeing the composition was not changing width from weight to weight, but I didn't notice the composition was changing instead.

Cheers!

.