Considering some of the sharp comments on the TypeCon's webfont monster panel about how bad-for-the-industry autohinting is...

I don't recall such comments. Who said what?

‘Good enough’ for what? Black and white text size rendering on XP?

"Considering some of the sharp comments on the TypeCon's webfont monster panel about how bad-for-the-industry autohinting is"

Were you at the same panel as me? Who was dissing autohinting?

Miguel used FontLab.

I do wonder if Adobe released auto autohinted fonts because they don’t expect most of them to be used for running text. The novelty types and scripts become illegible at text size, so there’s no need to hint those manually. And the rest are fairly narrow text faces designed for print—no amount of hinting is going to keep the fine details of Adobe Garamond from turning to blobs at sizes where Georgia reads perfectly. Out of the whole bunch only Myriad seems likely to get used at text sizes because it’s loose metrics and wide design have proven themselves onscreen.

"Good Enough" : Acceptable to majority of users and worth frustrating the few who are stuck in 2002. Technology marches on.

It's probably important to remember that these were the first TrueType fonts Adobe has produced in-house, so although Miguel obviously knows what he's doing the organization isn't geared up (process and test-wise) to ship TTF.

I'm more interested in Ethan's interpretation of the panel. Perhaps it's based on the Webtype trying to differentiate itself from the other providers via “quality over quantity”? To be honest I don't think Roger went far enough to state that point. You kind of had to read between the lines.

I was there and perhaps I was reading into the comments? My wife would concur that my listening skills aren't always the best ;-)

I'm more interested in Ethan's interpretation of the panel. Perhaps it's based on the Webtype trying to differentiate itself from the other providers via “quality over quantity”? To be honest I don't think Roger went far enough to state that point. You kind of had to read between the lines.

I applaud Roger for attempting to do everything right. 1) Reasonable, easy to use service, 2) Focus on quality, 3) Actual type designers working on the screen-font problem. Wow, and give it to me for 99¢! Umm, yeah. Others on the panel I thought were too "academic" about the state of webfonts. I don't really want to judge other's motives and we are all approaching this problem from different angles. I was by no means offended, but did find myself chuckling a few times. I've been working on the web developer side of the problem for over a year now and perhaps see things a bit differently than an invested type designer would.

>... the organization isn't geared up (process and test-wise) to ship TTF

But adobe, and so many others are geared up to define the spec, as if actual production and the spec from hell were two separate things.

Anyway, I thank John for his kind comments about us raising the bar, and cannot help but comment that not even a tree frog could limbo between our bar and the slime created by everything from webkit to cleartype, it stinks, it sticks and it's all the founder's fault.:)

On auto hinting, I have now officially given up trying to prod Adam into demonstrating if fl autohinting according to his tutorial "works"... with so many other libraries to point to, case closed.

The broader picture of hinted "custom web fonts" (beyond our script), I think, is that wired is right, the web is dead.

Cheers!

Miguel probably has thoughts. I'll add mine:

As I mentioned elsewhere here, every foundry has to strike a balance between quality and opportunity. Every foundry has its own idea of quality and resources to achieve it. And every foundry could spend several years creating the best possible fonts, but not everyone will wait for them -- and many customers have their own perceptions of quality.

As you might imagine, we're not pleased that the current state of web fonts requires TrueType. Adobe has decades of accumulated skill and knowledge in producing very nice Type 1/CFF fonts. Back in (IIRC) 1996-97 we had Monotype create some "superhinted" TrueType fonts, which we released as "WebType", but as everyone knows, those fonts are time-consuming (= expensive) to produce. (I was doing TrueType hinting for Monotype around that time, so I understand the process -- at least as well as memory permits.)

For many reasons, Adobe can't put a lot of time and resources into TrueType production. (We're still looking forward to the days when CFF looks as nice as expected in Windows.) What we've done for our fonts on Typekit is found the best semi-automatic process we can (still a lot of work from Miguel and others here), which I think allows us to produce above-average quality with a realistic amount of effort, and is clearly superior to some other methods. Our skills might rest mostly with CFF, but some of that skill is also general; creating good font outlines and hint parameters are talents equally applicable to TrueType.

Remember, too, that hints virtually don't matter on Mac OS at the moment. Even if it were possible for Adobe to allocate the necessary resources to produce really really nice TrueType fonts, that's still just for current Windows browsers. That's a significant percentage of browsers right now, but where will we be in just a couple years? We'll no doubt have nice CFF rendering with DirectWrite in new Windows browsers, and I don't know if anything will change for OS X. How much do we want to invest in current-soon-to-be-old environments?

The bottom line is this: Quality is always a big priority here, but there are many practical matters which weigh in. What level of quality is "good enough" for those people who want to use Adobe fonts on the web right now? We'll find out. Luckily, it's as easy as it's ever been to get bug fixes and improvements into a customer's hands.

I seriously think it is fantastic that Adobe is taking this position. Bravo. Thanks for weighing in Christopher.

I don't know, man. Selling something half baked seems very unadobish to me, at least when it comes to fonts.

FS> I seriously think it is fantastic that Adobe is taking this position

Mystery loves company, or like minds hint alike, your choice. :)

CS> How much do we want to invest in current-soon-to-be-old environments?

This issue is now 21 years old and Adobe is still fighting font wars. Bravo! ;)

I can't wait for this web fonts thing to go global, where I doubt TT technology can be replaced any more than it can be replaced in the situations we're seeing in the Latin market.

But light that rocket and I guess we'll see.

Cheers!

I don't know, man. Selling something half baked seems very unadobish to me, at least when it comes to fonts.

To quote Benjamin Braddock: "No -- it's not. It's completely baked."

We're quite happy with what we've put out there, but to repeat, one can realize a nearly limitless improvement in quality proportional to the time and effort spent. If we wanted to spend another two years on our web fonts, no doubt they would look better. (And maybe in two years they will.)

Everyone has probably noticed that new super-hinted TrueType fonts are few and far between these days. They take an extraordinary amount of time and effort. Does one get a return on that investment with a super-dense iPhone screen? Nope. So, just to be clear, when I talk about "current-soon-to-be-old environments," I'm talking about old viewing environments, not font formats. I'm pretty sure 300 dpi laser printers and monochrome screens are not as important as they were 20 years ago, either.

Well, they ain't doing a proper job on about 30% of all computers out there. That's not nothing.

Ethan: Technology marches on.

Well, yes, it does, but significant numbers of users of technology do not march on. They stay in their trenches. I say this as someone who made the mistake of ignoring a lot of rendering issues for a long time in the belief that everyone would be using higher resolution screens very soon. Not only did that not happen, but many users are still working with software that wouldn't scale effectively even if they were using higher resolution screens.

As to ‘good enough’, we really don't know what constitutes that. What I'm reasonably sure of is that ‘good enough’ is not equivalent to what users will put up with or might consciously declare to be good enough. Where is the reading speed and comprehension testing? What is an ‘acceptable’ level of degradation of reading speed and comprehension, relative to Verdana and Georgia as standards, in order to obtain the mere novelty of different fonts on the web?

What is an ‘acceptable’ level of degradation of reading speed and comprehension, relative to Verdana and Georgia as standards, in order to obtain the mere novelty of different fonts on the web?

Well said!

As to ‘good enough’, we really don't know what constitutes that. What I'm reasonably sure of is that ‘good enough’ is not equivalent to what users will put up with or might consciously declare to be good enough.

John, the whole point of using the term "good enough" is to describe something users would consciously declare good enough. At least that's my intention.

I was surprised after taking a superficial look at the Adobe fonts on Typekit. They appear to be autohinted TTFs converted from CFF by FontForge.

Ethan, it's not clear to me why you think that's what happened but the look you gave must have been superficial indeed because I didn't use FontForge at all. The Adobe fonts available through Typekit are TrueType fonts that were converted from carefully hinted Type 1 sources, with the help of FontLab. The conversion process within FontLab involves several steps which include removing all vertical glyph hints, setting the gasp table values and clearing the hmtx and vmtx arrays. The final TTF is actually built with AFDKO's MakeOTF, which assembles other tables such as GPOS, GSUB and name.

I do wonder if Adobe released auto autohinted fonts because they don’t expect most of them to be used for running text.

Actually we do, otherwise we would probably just release the display designs. At 7, 8 or even 9 ppem the text designs definitely won't deliver the same reading experience as Georgia, but as you go up in the range they will perform better.

Out of the whole bunch only Myriad seems likely to get used at text sizes because it’s loose metrics and wide design have proven themselves onscreen.

Myriad is actually a tightly spaced design. Its target size is around 16 point.

CFF by FontForge: what's that? What do I need to do to get it? Does this mean I have to spend a couple of days figuring out how to install FontForge again?

>What is an ‘acceptable’ level of degradation of reading speed...

You all should have made this journey first, made decisions on stds and hammered on this man's opinions later.

I knew i was talking to amateurs. Go to the other side of the isle, join Fink and Palin.

No cheers for you.

Miguel - My mistake. Typekit must be using FontForge to subset the font instead. It is unmistakable as the FontForge timestamp table (FFTM) is present in the fonts. I also assumed it because the em-square is 1000 units, which obviously is typical of CFF. TTF is usually 2048 (though I understand this no longer matters as much?)

Here's a side-by-side comparison of Adobe's autohinting vs. Font Squirrel's. I sampled Myriad Pro Light since the lighter faces seem to be more difficult to hint well. Neither is perfect. I think Adobe's looks a bit better at larger sizes, is a toss-up in the middle range, and Font Squirrel wins the smaller sizes.

Interesting comparison Ethan. The inconsistencies at the x-height is something that we've identified in Myriad and other families. I already have a fix for it and the updates should be out very soon. Stay tuned.

I was not present at the panel, but watched the discussion around it, mostly online, quite closely. The question I had after that was “If reading onscreen is important and growing, why did designing fonts expressly for low res display purpose never became a popular choice?”

The biggest reason I could think for this is inefficiency. Why design new faces from scratch when you can hint existing ones?

I was then thinking that this question could possibly be answered by tweaking the font’s outline to make a “screen” version of it—reducing contrast, increasing x-height, opening counterspaces, etc.—then hint afterwards. This benefits the foundry because they can “screen-version” their best sellers rather than invest a lot of money and time in the design of a new screen family.

I’d like to hear this side of the argument be presented more. Or is it answered already?

Bram, TT hinting was designed to enable a single outline to be adjusted at specific device pixel-per-em (ppem) sizes to obtain the best bitmap image at those sizes. As applied to an existing print type, e.g. Times New Roman, hinting enabled legible and consistent shapes in low resolutions. As applied to a new design intended specifically for screen reading, e.g. Georgia or Verdana, hinting enabled excellent readability building outwards from a base size for which the design was optimised.

The kind of size-specific screen design to which you refer is certainly something we've been discussing with regard to web fonts. David Berlow has convincingly made the case that, given the vagaries of today's rendering methods and how they interpret or do not interpret hints, the only way to optimise text type for for screen (i.e. optimise legible shapes, spacing and stroke density) is to fit outlines to specific ppem grids. Here is a hastily made demonstration I put together for the CSS3 session at TypeCon:

Since a lot of the first offerings of web fonts are converted and autohinted PS print types, I started with Adobe's Caeciliae Regular font, converted to TTF and autohinted with FontLab. The size-specific outlines were made manually using a variety of FontLab shortcuts to get me close to the different ppem grids (including changing the UPM of each font so that the grid was always 100 units). [The usual caveats apply that looking at screenshots of subpixel rendering is not the same as looking at the same font(s) rendered natively on your own system. There are variables in gamma, device pixel size, ClearType tuning, etc. that affect this.]

This image demonstrates two things: the first is that the size-specific designs are cleaner, sharper, blacker, have more consistent stroke density, are better spaced for low res, and generally more legible and more readable; the second is that size-specific designs do not scale linearly, which introduces a major problem. If you have experience looking at websites on mobile devices such as iPhones, this problem should be quickly evident. If text is displayed with size specific fonts, zooming text will cause one of two problems: either a font designed for a smaller ppem grid will be used at a larger ppem grid, which will look at best clunky, like this...

...or, if the device is clever enough to somehow get the larger ppem size font for the zoomed size, the text will reflow because of the non-linear scaling of the type and its spacing. So, for example, you might zoom in on a paragraph in a web page, only to find that reflow has shifted much of that paragraph to somewhere else on the screen or, even, off the screen. That is presuming, of course, that the device has some way to get the appropriate ppem size specific design for the zoomed text. In fact, there is currently no way to reliably specify a ppem-specific design even for un-zoomed text, because there is no CSS measurement unit that actually corresponds to device pixels. [The px unit, which used to refer to device pixels, is being redefined in CSS3 as a pixel at 96 dpi, (i.e. an absolute size of 3/4 pt instead of a relative size) which means that specifying e.g. 11 px in CSS will only display the font at 11 ppem on a 96 dpi device; at 120 dpi it will display the font at 14 ppem, and so forth.]

After discussing this with numerous people at TypeCon, I'm not optimistic that we're ever going to have a mechanism that will enable ppem size-specific outlines to be reliably used.

John's answer and very nice illustrations, describe how optimization may be accomplished via the ppm-specific idealizing of the outlines. When I did my experiments, it was only to show what was being lost by not having x-hints applied when rasterizing for users, (a whole long story, but trust me they are gone). It was never my intent that a raft of ppm sized outlines would be bundled up and made available to anyone, or that font management software of any kind should be trained to deal with this.

In addition, in the process of drawing size specific fonts as John shows, I discovered if users have idealized per pixel fonts, they want another weight to compensate for their tastes. Thus the Franky demo was designed, a raft of 48 outline fonts representing sizes and weights of a gothic font from 8 to 16 pixels. A specimen exists here somewhere. This led me to redouble my efforts to get variation technology back on the radar. A good thing, as it is what Ralph Levine is referring to the need for at the end in Dave Crossland's notes on the Fonts WG meeting.

It was never my intent to show anything other than what was being lost by Apple in 1999, and MS in '04 when their anti-aliasing techniques were released as Quartz and ClearType. FreeType still/now makes x hinting for effect possible. But, as John points out, idealizing a single outline causes it to become non-linear to itself. So using the idealized metrics then passes to the application, which must keep track of the non-linearity via the TT hdmx table.

And application/OS using x and y hints on a font to produce the results John or I show would then be scaling according to what the per ppm instructions of the font said to do, per glyph, per width, presumably for a static page-based reading situation. In a zooming environment like the 365 dpi iPhone, or 185 dpi Pre, this kind of optimization would not be required, so it would not be a problem.

It's almost like two different worlds, zooming places, and reading places.

Examples of x hinting causing non-linear results are found on the Mac, I know, and probably continues on Windows when they are in aliasing modes. So, what hinting does to optimize reading in x at the cost of linearity, is hardly some kind of alien notion to the OS.

Bram>...why did designing fonts expressly for low res display purpose never became a popular choice?

Little market existed with the exception of bespoke device/OS fonts, like hinted Times or Mac and Win OSs, custom designed and hinted Prelude for the Palm Pre and etc.

Bram>Or is it answered already?

In a way, yes. We made screen optimized version of some of our more popular faces, and one new one, and hinted these.

Correction, Ralph Levine should be Raph Levien. Apologies.

David: This led me to redouble my efforts to get variation technology back on the radar. A good thing, as it is what Raph Levien is referring to the need for at the end in Dave Crossland's notes on the Fonts WG meeting.

Adam T introduced variants to the discussion in LA. I think what Raph was talking about was more generally a method to address something like optical size ranges (whether that be variants, a size feature, table, new OS/2 fields, or whatever). Adam's with you now, I think, in believing that something like GVAR or MM is necessary. I'm going to go look for any sign that this idea might find traction: discarded ideas do have a habit of coming round again in this business.

[By the way, thank you for a clearly stated and eminently readable post. I kept wondering, is this really Berlow?]

Speaking as a type enthusiast: I miss multiple master fonts.

I'd like to give you an update of what's going on on our end. The x-height misalignments have been fixed. The filled up counters (which Mike pointed out over on this other thread) have been corrected. And the clipping reported by users on Mac browsers has been fixed as well. The new fonts are in QE right now and should go live early next week. In the mean time, I've uploaded some screenshots which you're welcome to look at. Here are the links:

Myriad Light
Myriad Bold
Minion Regular

On all images, the before version is on the left, and the after is on the right.

Miguel, have you considered respacing the web versions for text sizes on screen?

John, some respacing could be done with the CSS. Not perfect, but it would certainly help the smaller sizes.

Technical question: If Miguel were to space Myriad (or other) for use at small sizes wouldn't that become a new font as they'd still want the other for larger sizes?

I suppose having optically spaced fonts for use anywhere (web, print, whatever) is the ideal.

Miguel, have you considered respacing the web versions for text sizes on screen?

No, we haven't. But I made many small changes to the outlines to improve the rasterization at small sizes. Things like nudging the f and t to get the crossbars to snap to the x-height.

I agree with Tiffany. Some amount of tracking via CSS will be necessary. Which is not much different from what designers are already doing for print.

I realize I'm being unnecessarily antagonistic, but Berlow tweeted yesterday that he'd like to see how a text face would compare with autohinting. Here is a quick comparison of his BentonSansRE. Flame away...

BentonSansRE - Font Squirrel vs. WebType

I would imagine you'd get similar results comparing any well designed *screen* font with autohinting vs hand hinting – try Verdana. For most of the autohinted stuff I've seen it's "garbage in = garbage out" and/or "print font in = garbage out".

Sii - interesting, I suppose there is truth to that. But for what it is worth, the algorithm I'm using now isn't too smart yet: it strips out all previous hints and instructions, and recreates all the blues values. So from an autohinting perspective, I'm starting only with the outlines.

As a test, I ran a bunch of Adobe OTF print fonts through and here is the result:

Autohinted Adobe OTF

It is clear that monolinear-ish sans serif fonts do best. The serif fonts have issues here and there: clogging counters, some unevenness at a few point sizes. So the conclusion I come away with is: Duh, don't use Nueva Std as a text face.

How well does your autohinter preform for Greyscale rendering, Ethan?

Grayscale rendering looks like chunky barf. But misery loves company. Show me any font on Typekit or even the esteemed WebType right now that isn't horrible in grayscale. Is anyone even hinting for this anymore? I noticed that GASP table settings are all over the place too. It seems to be a dead rendering format that no webfont-er is willing to support.

Didn't we figure out just a month ago maybe as many as 1/3 of all users still see grayscale?

Typotheque is hinting for greyscale.

>Berlow tweeted yesterday that he'd like to see how a text face would compare with autohinting

Under normal jounalistic conditions, you would ask to use software I know you know is commercial. Are you a journalist?

Under the conditions of a competitor, you could not be so superficial in what you test, and you'd only show your own text fonts because of the first point. Are you a competitor?

If you are trying to prove superficially that one style of one simple family made specifically for this purpose autohints well, we're a commercial foundry, and have lots of styles and glyphs to hint and license. Are you a client?

If you can only suppose the obvious, you might be malingering around legal bounds for the publicity. Are you a minkey?

Ethan,
your autohinter seems to do a pretty good job in basic hinting, and I think we all do our hand hinting *based* on an auto hinting.

But there is more than just autohinting one single (sans serif, rather light weight, rather simple) font and show A-Z.

Serif/slab
Your example already shows that serif faces look much worse.

Problematic glyphs
What about the usual suspects like ß, ae, OE etc? S already causes problems.

Family
What about an Italic companion? Same behaviour? Stems jump at same sizes?

Bolder weights
What about bolder weights?

Critical PPMs
Your waterfalls are ok, but perfect would be when we could exactly see the ppms of the stems' jumps.

I'm not sure how this could help to focus the problem on quality and "good depending on the media", but which face do you use for writing in your ordinary word processor application, and which do you use most to set simple texts outside layout page programs, and at the same time you find comfortable on screen? (I'm sorry this does not apply to iPhone or similar things, since I use only an iPod nano).

I used to find myself using more or less constantly Verdana and Georgia. I ended up appreciating Georgia’s versatility (so much that I licensed Miller and tried to use its small capitals together with Georgia for eBook experiments. In the end, I bought Miller in Opentype OTF format rather than Truetype. I'm still unsure about that, since I have not enough familiarity with the behavior of Opentype on Windows).

But since I tested Cambria, I ended up using Cambia for almost any of the aforementioned applications.
I would like to hear what you use, or use mostly…

fontsquirrel -- I noticed that GASP table settings are all over the place too.

Could you elaborate on this?

You could as well say "there are OS/2 table settings all over the place" which however is saying nothing at all. Every OT font contains an OS/2 table. Which OS/2 table of course holds some settings.

Or are you speaking about specific settings? GASP contains settings (per PPEM size range) for a) greyscaling & gridfitting and b) ClearType & ClearType gritfitting, with a) and b) being independent of each other. So it is still not clear what you are saying.

.

Ethan is right. Auto hinting is serious business.

Here's Sarah in Windows GDI with ClearType enabled, before I ran her through the Font Squirrel auto hinter:

Here's after:

Impressive, but in Fontlab I got this:

Now, this is just one test, so it isn't necessarily indicative of anything.
But still, I think we've come a long way in a very short period of time.

rich

lol.

Sarahindipidy.

Are those real? (I mean the photos in general)

Are those real? (I mean the photos in general)

The first one for sure! ;-)

But even the first photo is palin' in comparison to the real person :-)

CL>But even the first photo is palin' in comparison to the real person
Excellent.