I think the issue we face in lower resolutions and smaller point sizes is that a quantitative comparison as you show is not fine enough for the kinds of decisions that have to be made on those smaller sizes.
I think we are looking at the same thing from different angles.
I am concerned with the case when someone finds a font that looks nice in his own browser, assumes that it looks as nice for everyone else and then proceeds to build a production website with it. I could be that person, and so I would appreciate a simple warning if the font may render differently in different browsers.
What I described was a simple way to automate the generation of such warnings, likely including some false positives.
apankrat: I am concerned with the case when someone finds a font that looks nice in his own browser, assumes that it looks as nice for everyone else and then proceeds to build a production website with it.
But isn't browser/platform testing a basic best practice in web design anyway?
That said, I'm all for ample warnings, Alex, and I'm sure Typekit will do their best to show render variation. Their impressive screenshot effort is evidence of that.
John Hudson: To me, the rush to the web fonts market looks pretty much identical to the rush to the desktop publishing market, so I'm expecting a lot of bad typography and difficult to read text, and the better part of twenty years to clean up the mess.
I too feared this a few years ago when @font-face was available but good webfonts were not. I'm happy to say my fears were not realized. Not then, and not yet. We're not out of the woods — webfonts haven't hit the mainstream — but I have increasing confidence in the ability of web designers responsible for major sites to make the right choices, typographic or otherwise. The web is a much more mature medium than DTP was in those early days of digital.
Stephen, just scroll up and re-read the beginning of this thread :)
That's my point: those who don't test their designs on all major browsers are bound to run into issues, webfonts or no.
>What I described was a simple way to automate the generation of such warnings, likely including some false positives.
I think what you described is a way for font developers to test one of the many criteria that lead to recommendations that web developers would find useful in developing typography on the web.
>I would appreciate a simple warning if the font may render differently in different browsers.
Consider it done. Simple Warning: Any font may render differently in different browsers!
I believe what you would appreciate is a simple warning system within a standard, developed and used across the type industry.
>At least by most web author's standards. Even for body text.
I think I'll add a sentence sniffer for readers who only want to read and write complete ones on the web. For some writers unfortunately, I think a stiff sentence is the only solution.
@jhUntil I see some indication that the typographic standards of web authors are significantly higher than those of scrapbookers, I will remain unimpressed by this criterion of success.
OK by me but yours or my opinion on the aesthetics isn't going to change anything.
Design-wise I'm surely not as picky as you are. Font-quality wise I'm probably just as picky as you are, and constantly frustrated.
I was looking at a blog called bobulate.com. Typekit is providing the fonts.
Now, I think the font for the body text sucks by anybody's standards.
But it does have a great virtue. It's not f-cking Georgia!
Let's tweet that one, too, while we're tweeting.
And when a better hinted font with the same visual qualities becomes available, it can be subbed for the sucky one with just the click of a mouse. And I'm sure that's what will happen. In the meantime, people have a way of adjusting their expectations and focusing on the content.
I don't really don't know what you want from people who've never had to deal with these issues before. For the first time in human history anyone can self publish and, on a neutral network, be on an equal footing with anybody else. And now, the choice of fonts has gone from around eight (families) to tens of thousands. Call me a populist, call me a cab, but that seems to me a good thing.
Considering that publishing is literally being re-invented for a new medium, I think we're doing rather well.
If some crappy typesetting is the price for all this, we're getting away rather cheaply don't you think?
You took issue with my statement that everyone is now a typographer but in a publishing environment where everyone can and, as a practical matter, has to be their own typographer how else would you like me to phrase it?
The barbarians are not only past the gate, they're sitting on your sofa and drinking your beer.
@sii...These are the voyages of the Starship Enterprise...
They most surely are. And comments like yours are the reason I've fought so hard for the <rimshot> tag in HTML5. ;)
bobulate, uses Skolar, which appears to be completely devoid of hints. This is a shame as it would make a good screenfont I think. Perhaps, Typekit could notify designers what level of hints are in the fonts. Another problem i see often now on sites that use webfonts, is the use of one font, while the rest of the site, such as on bobulate, uses fake bold and italics.
Rich: I was looking at a blog called bobulate.com. Typekit is providing the fonts. Now, I think the font for the body text sucks by anybody's standards. But it does have a great virtue. It's not f-cking Georgia!
I don't know about your system/browser, but on mine (Vista/Firefox) the bobulate body text is pretty much unreadable, thanks to it being a) a CFF font under Windows GDI, b) grey not black, c) set at a fixed px size that is too small on my screen.
There is no virtue in not being Georgia if the result is unreadable. Georgia is a great typeface, and from where I'm sitting it looks like remaining one of a tiny number of fonts that I would consider using for web text for a good while yet.
Heh, maybe what we'll see in a few months is the Georgia/Verdana reaction, when people start complaining that the web isn't as readable as it used to be.
Rich: You took issue with my statement that everyone is now a typographer but in a publishing environment where everyone can and, as a practical matter, has to be their own typographer how else would you like me to phrase it?
In coherent sentences? :)
But let me take issue once more: no one is forcing, as a practical matter, any self-publisher to be his own typographer. In very large part, the details of microtypography are taken out of his hands by the font itself, which is why it is crucial to have a well-made font, one that sets well and reads well. Similarly, macrotypography can -- and in many cases should be -- taken out of his hands by pre-made templates and style sheets designed by people who know what they're doing. And in the great majority of cases what the self-publisher should be doing is using Georgia or Verdana for text, because that's the best guarantee of readability, which is the prerequisite of text. If this self-publisher takes it on himself to use a different font, for the sake of novelty, he isn't being forced to be his own typographer: he's just doing something that, in all likelihood, he isn't qualified to do.
Rich, in all seriousness now, let me explain how I see the current situation of web text re. fonts.
You wrote: …the choice of fonts has gone from around eight (families) to tens of thousands.
I think the situation is more dramatic than that. Restricting our discussion to Latin writing system fonts, the choice has gone from exactly two font families that were designed and made for continuous reading on screen to some many thousand that were not.
Fonts fall into three categories when looked at with regard to web typography:
1. Fonts that were designed and made specifically to be read on screen, without regard to print conditions. There are a number of these, if one includes embedded OEM device fonts such as those David Berlow made for the Palm Pre, but in terms of the web there are essentially two, Georgia and Verdana, that can be reliably spec'd in CSS.
2. Fonts that were not designed specifically for screen reading, but which have been made in such a way as to have good screen legibility. Times New Roman and Arial are classic examples: print typefaces hinted for screen legibility. [That a font such as Times New Roman may become less, not more, readable when antialiased and spaced on a subpixel grid is a good indicator of the crucial role of proportion and spacing in the distinction between print and screen typography.] The Microsoft ClearType fonts also fall into this category, due to their being designed for use as document fonts in print at the same time as looking good within a particular screen rendering model. And the first offerings of text ‘web fonts’ from FontShop and other foundries also seem to fall within this category: typefaces designed for print being repurposed for the web with some hinting.
3. Fonts that were not designed for screen reading and which have not been made in such a way as to have good screen readability. This accounts for a very large percentage of Rich's ‘tens of thousands’ of fonts, and in Windows GDI environments includes all CFF fonts.
The good news about web typography is that I think Stewf is right that as a design medium the web is more mature than desktop publishing was in the years of typographic desolation, and there are a lot of sophisticated web designers capable of doing good work when given appropriate resources. But that doesn't change the fact that there are nothing like enough fonts in category 1 to maintain current standards of web readability if everyone suddenly wants to embrace diversity and novelty as typographic goals.
Let's look at fonts on the web in the context of the various stages in the evolution of Disney Studios:
2)Snow White And The Seven Dwarfs
4)The Lion King
Right now we're at Steamboat Willie. But I think we'll get to Snow White fairly rapidly.
Also, if some web authors are willing to sacrifice readability for "making a statement" with their choice of fonts and their typography, that's their choice and it's fine with me. I can't say I'll stick around to try and decipher what they've written under those circumstances, but it does make things interesting. I wonder how bobulate looks on a Mac?
Good catch on the synthesized bold and italic. I'm sure that's happening a lot. There's various reasons for it - all of which can be remedied. No reason it has to be that way.
Rich: Let's look at fonts on the web in the context of the various stages in the evolution of Disney Studios…
No, let's look at fonts.
john: how did you determine the Skolar font on bobulate is a cff font?
Mike, the current Firefox rendering in Windows is a good indication of the font flavour. In this case, the rendering is (bad) greyscale antialiasing, whereas if it were TTF on my system it would display with ClearType. Obviously this diagnosis will not be as easy when Firefox switch to DWrite rendering in future versions.
My understanding based on this diagnosis is that Typekit received a CFF font from the foundry, and this is what they serve to Firefox etc. as either .woff or (split and otherwise obscured) naked font, but for IE they convert it to TTF -- I don't know how or what kind of autohinting or hint conversion they apply -- to serve as .eot.
I wonder how bobulate looks on a Mac?
Mac OS X.5.8, Safari 4.0.5:
Mac OS X.5.8, Firefox 3.6:
(I note that the lines break differently.)
The difference between Craig's two Mac renderings is interesting. I'm guessing that this is due to different colour interpretation in the browsers, and that if the text were black the rendering would be cross-browser consistent?
Here's the black text; Safari, then Firefox:
Firefox does kern, Safari doesn't. Therefore the different line lengths.»believe.« in the last sample is an obvious case.
Thanks, Craig. Apparently grey is still the new black.
>>I don't know how or what kind of autohinting or hint conversion they apply -- to serve as .eot.
thanks John. It would appear none at all. The font does not look to me to have any hinting, when displayed as an .eot. This suprises me. I would expect some kind of hinting.
No hints, or bad hints? [Vista/IE7]
I would expect dropouts in more places and vertical alignment problems if there were no hinting at all.
id say no hints
If only the EOT could be cracked open and the font hacked out we'd know for sure.
I do know for sure :)
Please do not kill me for how awful Skolar looks in IE.
1. I do not have time (and skills) to manually hint it.
2. The font is originally hinted CFF. I do not have any further knowledge about how it is converted to TTF.
3. We did some experiments with TT autohinting and it, surprisingly, did not improve the appearance. It just got worse.
4. It annoys me a lot, but in the current situation responsible type designer is expected to cater for several rendering engines. Some are doing pretty well with CFFs (Safari) some are worse (IE). This is pretty much like developing multi-platform application. I do not have business environment to do that. And most of the type designers do not have it either. In this respect webfonts are too early. And it is not that type designers missed the train. Some rendering engines missed the train. … but I guess I am repeating what other people said already.
>Please do not kill me for how awful Skolar looks in IE.
Once again I think IE is probably the best of a bad bunch when it comes to Windows browsers (fake bold and italic aside)
sii, the safari settings can be much improved from what you show above. this looks like the "windows default" rendering settings, but it probably renders better than the other two you posted if you tweak the type settings a bit.
Correct, this is the default experience Safari users will get. Other options look better. But how many users are going to discover and change their rendering settings for @font-face sites?
Eeeehem. I heard about the same advice as regards ClearType (you need to tune it). Given your argument I hope I will never hear this advice again. ;-)
We did some experiments with TT autohinting
Which software did you use? As far as I am aware, there is no such thing as TT Autohinting in FontLab.
surprisingly, did not improve the appearance. It just got worse.
Strange. As far as I have tested, converting PS hinting to TT hinting in FontLab gives decent results, at least better than nothing. Setting the alignment zones before you convert is a good idea, though.
I can tell you for a fact (as has already been stated) that TypeKit EOT files are not hinted.
@sii - I discovered a method today that can crack open an EOT (lite). For better or for worse.
Tim: As far as I am aware, there is no such thing as TT Autohinting in FontLab.
There is, and if you set it up carefully you can get quite good results if you can count on subpixel rendering in the x-direction. FontLab TT autohinting is essentially a conversion of PS hinting data, treating PS blue zones and y-direction alignment CVT zones and PS standard stem hints as CVT distances. If the blue zones and standard stems have been appropriately set, the conversion of PS stem hints to TT instructions is quite good. Within a user-set tolerance, stem hints will be snapped to standard CVT distances. Links are anchored top or bottom relative to The TT autohinter also tries to apply interpolation. There are TT autohint options that provide additional control over the process, and the results are editable.
I've had clients who could not afford manual hinting, but were satisfied with what I call semi-automatic hinting, in which I set the vertical alignment zones manually and fill in and edit standard stems in the TT hinting dialogue, and then run the FL autohinter. Then I usually so some small amount of editing, e.g. popping up the xheight at some size or changing the ppem size at which a stem jumps in thickness. In some cases, where the target environment is subpixel, I find the autohinting results best if no x-direction instructions are used.
Is this kind of approach capable of making a top quality screen readability font? No. But in terms of converting existing PS designs to get decent screen display, then it is quite good.
Ethan,I can tell you for a fact (as has already been stated) that TypeKit EOT files are not hinted.
I can tell you for a fact that some are indeed hinted: http://typekit.com/fonts/1572
Does that look okay in Internet Explorer?
John,FontLab TT autohinting is essentially a conversion of PS hinting data
Exactly. Like I said above, there is no such thing as TT autohinting in FL, even though the options dialogue misleadingly calls it so. Autoconversion would be a more appropriate term.
treating PS blue zones and y-direction alignment CVT zones and PS standard stem hints as CVT distances
I think you are wrong there. It does not refer to the PS standard stems directly, you have to import them as TT stems and TT alignment zones first. Like I said above.
conversion of PS stem hints to TT instructions is quite good
Exactly. Like I said above.
Tim, I agree with you completely regarding "auto conversion" hints. I have been looking into this direction over the past few weeks as well, and I find the results quite ok. Not great, but exactly in line with what John says ("in terms of converting existing PS designs to get decent screen display, then it is quite good").
Indeed, to be precise, I used PS autohinting in FontLab and converted it to TT instructions and expected improvements. There are two options:
1. I did not do a good job
2. it got stripped off during Typekit conversion
Tim & John: thank you for the hints (I mean your help, not PS hints).
=> will do some more tests soon and let you know.
@Tim- Sorry, wasn't clear. Skolar arrived at TypeKit as a CFF. TypeKit converts to TTF and then to EOT. They did not instruct the TTF. If the fonts arrive at TypeKit as hinted TTF (ie: FontFont) then the EOT will be hinted.
@David - Since you supplied CFF OTF, they were not able to use TTF instructions.
@Dan- I agree, autohinting is decent. It gets you 80-90% of the way there. Good enough in my opinion. And I find that FontForge auto-instructing looks better than FontLab's.
This is what Skolar looks like in my IE:
You can see that it is unhinted because of the black or white bits "sticking out". This is because the extrema are not rounded. [Edit: just saw that Ethan confirmed this first-hand]. Hinting would not remove the ugly steps but it can make the curve look more natural (as it is the case in the top of the large o, by sheer coincidence).
They key to good TT "autohinting" results is to set the TT stems and zones carefully before you convert the hints to TT. The PS stems and zones do not seem to play a role. If you open an OTF in FontLab then the TT stems and zones will be filled in from the corresponding PS data but if you are working from vfb they may be outdated or empty.
@Ethan & Tim: I did supply TTF with TT instructions! But for the purpose of testing. I did not say that what you see is a result of TT "autohinting". I said we did tests which showed that it got worse for some reason.
And yes, I can see there are problems. No need to show me big print screens. :) Give me time to look into it.
@David - Huh. They are definitely sending CFF to Safari and FireFox (which is why I assume that CFF was the original file delivered to TypeKit). So are you saying they converted your TTF to CFF?
Tim: Like I said above, there is no such thing as TT autohinting in FL, even though the options dialogue misleadingly calls it so. Autoconversion would be a more appropriate term.
FontLab TT autohinting also does things like interpolating cusp positions, generating triple hints, and even attempts some deltas, all of which are TT specific and not directly converted from PS hints. The autohinting process is a combination of conversion of aspects of a shared paradigm (vertical alignment zones, standard stem values) and automation of some TT-specific features.
I think you are wrong there. It does not refer to the PS standard stems directly, you have to import them as TT stems and TT alignment zones first.
This applies if you wish to do any editing of the TT hints and are converting PS hints to instructions within a VFB. If you have not put any values in the TT stems and alignment dialogue, the autohinter will use the values in the PS standard stems and blue zones by default during TTF generation. If you have not provided such information, then FontLab will try to automate that too. Basically, what FontLab does during hint automation is to use as much information as you provide and automate whatever is missing, so you can intervene within the automation at almost any step, for the whole font or for individual glyphs.
David: I said we did tests which showed that it got worse for some reason.
Worse relative to what? And in what test environment (system/application)?
John:FontLab TT autohinting also does things like interpolating cusp positions
I personally found that this is something that should rather be done manually.
generating triple hints
After some experimenting I switched that one off. Can you show a convincing example of automatically generated triple hints in the y direction?
If you have not put any values in the TT stems and alignment dialogue, the autohinter will use the values in the PS standard stems and blue zones by default during generation.
Your FontLab seems to behave differently from mine. On both of my computers (FL 5.04 Mac and FL 5.04 Win) the lack of TT zones means you don't get links attached to zones, and the lack of TT-specific stems means the links are not linked to stems. PS information is completely ignored.
David,No need to show me big print screens.
I was merely trying to answer your original question whether there are any hints present in the EOT because you wondered whether they got stripped.
It was not meant to be a quality assessment.
Tim > I can tell you for a fact that some are indeed hinted: http://typekit.com/fonts/1572
Does that look okay in Internet Explorer?
It's hard to say since the fonts are all shown at large size and the italics are synthesized (I'm looking at the 'Weights & Styles' tab not the 'Browser Samples' -- see image below). Is there any way you could setup a page with a waterfall of one weight or two?
Tim, I wasn't suggesting that the TT-specific features of FontLab's autohinting were necessarily good, only that they exist and hence it isn't merely an auto-conversion of PS hinting. I've generally found the automation of interpolated cusps quite good.
Regarding the PS/TT stem data, it's been a while since I've used FontLab in this way -- most of our TTF work involves VTT hinting --, but my memory is that if one is allowing FontLab to autohint as part of its TTF generation process, then it makes use of PS standard stem and blue zone data. Note that this is a different process than running autohinting on the VFB file, which as you say requires importing of the PS data into the TT hinting tool.
for some reason IE is not serving up the right fonts. If you view this is FF, you will get the correct styles including the real italics.
I believe there is a known issue with font family styles in IE's implementation of @font-face.
@John - Actually IE does style-linking fine with the standard variations: Regular, Italic, Bold, Bold Italic. What it does not do is adjust based on number, like font-weight: 800; Typekit uses numbers and they just don't work on IE yet.