No contact information? Oh well. If contacting me will help, then please do so as I have an offer to make.

Shouldn't Google be paying for this, if they want it so badly?

@abattis

I will be blogging about this to spread the word and donating some money, too.
Between what FontLab can do, FontForge can do, and now this - it looks like by the end of the year the problem of adequate hinting for Windows will be largely solved. At least for Latin-based fonts.

What's needed very much is an online front-end for this tool ala the Font Squirrel Generator.
You can't expect designers to be command line gurus and it will be hard to get feedback from the community at large without such a tool to upload a font and see the result quickly and easily.
(There's no doubt in my mind that it's only a matter of time before this tool is integrated into the FS Generator. But the more the merrier. :-)

rich

@David: Are you missing my email address (wl@gnu.org)? I've just added it to the web page. Or do you mean something different?

@Richard: A GUI is the main thing which I want to add :-)

@jens

Google? Why is it their problem? Is Windows GDI and TrueType their product?

The scandal is that Microsoft has not put any resources into this. The need for a simplified auto-hinting tool such as this has been plainly obvious for years now.
But so far all they've done is leave everybody swinging slowly in the wind, doing absolutely nothing to mitigate the situation for the benefit of type designers, web designers, and the billion Windows users out there.

The really crazy thing is that TTFs look better hinted in DirectWrite, too, so it's not as if the issue is being solved technically going forward.

The way fonts look in GDI is perhaps THE biggest barrier to adoption of web fonts. But as far as I can tell - MSFT doesn't give a hoot about it.

So be it. You might as well complain about the weather.

Jens: Neither I or Werner represent Google, and I can't speak for that company. Google did already provide some financial support to Werner to start the project, and I personally will be surprised if they do not provide any more. I think this project is something that many in this community will benefit from though - probably even yourself - so I think it makes sense to engage the wider community in helping fund it :-)

dbrerlow: good catch, thanks :)

Rich: You'll note that a GUI is mentioned in the video and is the top item on the roadmap section of the site :)

Wow.

But can you please switch from pledgie.com to kickstarter.com? Latter gets far more foot traffic and the crowd there is far far more engaged and enthusiastic. This project has all chances of going viral, and kickstarter is the place to be for that. 30K should be more easily achievable there (assuming you won't get a large check from a corporate sponsor).

»Neither I or Werner represent Google, and I can't speak for that company.«

I was indeed under the impression that you represented Google. But you are involved with the Google Font Directory, aren’t you?

»You might as well complain about the weather.«

I do, the summer in Berlin really sucks this year ;)

Reposted on HN and reddit.

@apankrat: Kickstarter is no option, unfortunately. You must be US citizen to use it. I'm sitting in Vienna, Austria...

@Jens: Du mußt einmal den Salzburger Schnürlregen genießen, so wie ich die letzten drei Wochen :-)

@jens
You should try Naples, Florida from June through September.
I don't bother to check the weather because it's the same sub-tropical oppression every day:
90+ degrees with high humidity and a chance of thunderstorms.

I take it you don't disagree with my assessment of Microsoft's behavior in regards to this. ;)

Companies which publish both layout software and fonts are in a conflict of interest situation.
Such behaviour is par for the course.

From the 'How it works' section of http://www.freetype.org/ttfautohint :

Intentionally, ttfautohint adds hints only along the y-axis.

So other than perhaps providing some better algorithms for automating y-direction hints, I wonder what ttfautohint does that is significantly different from what we've been able to do with a simple batch process in FontLab for well over a decade now -- and hence, Rich, perhaps why MS didn't see a need to produce an alternative? --, which we also had the ability to edit.

Don't get me wrong: I'm glad Werner is doing this, and will likely contribute some money, because I like having tool options, and when it comes to automation differences in algorithms are as important as different capabilities.

But if ttfautohint really ignores the x-direction completely, then it is of limited interest and is dependent on sub-pixel rendering environments, so doesn't help users employing XP standard font smoothing, which remains a significant demographic for the Web.

John: I believe Werner will look into this, but I'm not sure he will produce good results in the time that the target $30,000 will allow :( That is certainly the long term goal, though :-)

Jens: I am involved with the Google Font Directory project as a independent, 3rd party consultant, yes.

John: I also want to add, I think its important that how it works isn't a secret and can be reviewed and discussed by the public, which is a substantial difference in quality to the FontLab process.

*blinks slowly* Okaaayy... Mebbe dat anti-rot stuff I bin 'elping sis slop on 'er 'ouse is vegging me, but this statement comes quite a few tuns north by borth-west to me.

Té: huh? :)

I am a bit surprised to see the y-direction-only approach being criticised (here and there) when at the same time 1) this is all that about every webfont producing foundry is offering right now and 2) this is what I understand to be the way to go according to Microsoft (my reading of some past months' Typophile posts).

To be clear, I do not say that I appreciate the y-direction-only approach, I only say that I observe a contradiction.

@John: FreeType has an experimental autohinter option (off by default) for special `hinting' along the x axis, and I want to investigate whether it can be transformed somehow into TT bytecode. From the file ‘afwarp.c’:

The idea of the warping code is to slightly scale and shift a glyph within a single dimension so that as much of its segments are aligned (more or less) on the grid. To find out the optimal scaling and shifting value, various parameter combinations are tried and scored.

Dave: I also want to add, I think its important that how it works isn't a secret and can be reviewed and discussed by the public...

Agreed.

...which is a substantial difference in quality to the FontLab process.

Which aspects of the FontLab process can't be reviewed and discussed by the public? [Serious question.]

The actual algorithm used to auto-generate the stem hints, I suppose. What else?

Karsten: this is what I understand to be the way to go according to Microsoft

With the caveat that this applies if one is targeting only subpixel rendering environments. Part of the continuing need for hinting with regard to webfonts is to support the still significant number of users not using subpixel rendering, esp. XP users.

John,

it's trivial to add hinting à la FreeType's autohinter along the x axis. Actually, it's even simpler because the blue zone code can be omitted (at least for non-CJK fonts).

Of course, this is on my TODO list :-)

If x complexity = y complexity then I guess all of basic quality manual hinting complexity is a ruse. And, when all the x and y hinting is automated, what to do about diagonals...

To not be too cryptic, you are warned here that the gap between y auto hinted normal fonts to average qaulity CT use, and even the simplest effective auto hinting of x with modest quality spacing, is larger than it might seem. Imagining from your perspective with all due respect.

Ah yes, I see it on to the TODO list now. Good, good.

With regard to expressing the ttfautohint actions in high-level hinting command languages, may I request that you prioritise VTT in this regard? I'm sure others will disagree and favour FontLab, but my take on this is that the people who are most likely to want to manually edit the hinting are those who want to do things that FontLab can't do anyway.

Add full OpenType Feature support – currently, all glyphs which can't be directly addressed with a character code in the ‘cmap’ table are handled with a fallback mechanism only.

Isn't it possible to address them via glyf table index, rather than having to support OTL tables?

Are there any other reasons you can think of for supporting OTL tables in an autohinter? Now you've got me wondering about auto-generating GPOS device adjustment lookups. :)

David: the gap between y auto hinted normal fonts to average qaulity CT use, and even the simplest effective auto hinting of x with modest quality spacing, is larger than it might seem

Yes.

I think it is worth exploring a very specific target area in terms of x-direction autohinting, though: stem density in full-pixel smoothing environments, esp.XP. This is where the absence of x-direction hints is most obviously problematic, and where trying to obtain better consistency in the darkness of stems is worth some effort in terms of impact on both appearance and readability. Sure, the results are never going to be as good as manual hinting for these environments including control of spacing and other distances, but the results can be better than what Frode showed in the other thread.

"I am a bit surprised to see the y-direction-only approach being criticised ..." That would be me, yes. This smells like the 80's too me: Back when everyone converted analogue to digital the cheapest possible way and as a results forced me to grow up through two decades of horrible typography.

John: I'm only learning this now. Like four weeks in or smthn. I can do better for sure. I already am. And I haven't gotten around to VTT yet.

Edit: Or did you not refer to my own hinting experiments, but rather the autohinter examples?

@jh

"Don't get me wrong: I'm glad Werner is doing this, and will likely contribute some money, because I like having tool options, and when it comes to automation differences in algorithms are as important as different capabilities."

We are on the same page! Tool options are a good thing.
For everybody.

"But if ttfautohint really ignores the x-direction completely, then it is of limited interest and is dependent on sub-pixel rendering environments, so doesn't help users employing XP standard font smoothing, which remains a significant demographic for the Web."

Here's where we start to part company. X direction, shmex direction. Picky, picky, picky.
If the font coming out looks a hell of lot better than the font going in, with the only effort being the click of a mouse or a keystroke, then something really critical has been accomplished.

In the early years of the twentieth century, Bell Telephone relied on female operators to handle the problem of switching. (Remember Lilly Tomlin's caricature?)
Anyway, as the phone system grew, the problem of switching started getting out of hand and the company undertook a survey and came to the conclusion that, at the current rate of expansion, in just a few years, every female in America would have to be employed as an operator to handle the volume. Faced with this, a method for automatic switching was developed and deployed only a few years later.
It's the same situation here. If we could clone Berlow or Tom Rickner to create an army of Berlows and Rickners hey, no problem.
But that's as absurd as having every woman in America employed as a telephone operator.

Every tool has it's own personality. At this point I've spent hundreds of hours with FontLab auto hinting and FontForge autohinting, and I know exactly what FL will balk at and what FF will balk at and what either one will gladly accept and improve.

Of course, fonts that are missing important characters or are internally inconsistent present special problems that consume more time. But that's a different issue, anyway.

The auto hinting provided by the Font Squirrel Generator is also quite excellent once you get the hang of the settings and prepping the font to get the best out of it. And while the back-end stuff at Font Squirrel isn't open-sourced, it's free and that's close enough for me. Kudos to Ethan Dunham for taking the bull by the horns. And he's perfectly entitled to profit from it and keep it proprietary if that's his druthers.

With ttfautohint, I welcome that someone is working on yet another tool, open-source, with input from the larger community. When I see that somebody like Greg Hitchcock is offering feedback to Werner, I get hopeful.

Frode: Or did you not refer to my own hinting experiments, but rather the autohinter examples?

These: http://typophile.com/node/83829#comment-473415

Dave,

I think my reply caused misunderstandings. Hinting along the x axis is far more complex and demanding than hinting along the y axis, at least for the Latin script. I was just replying to the technical side of FreeType's autohinter, which treats both axes (almost) the same. The results are very pleasing for the vertical direction, as ttfautohint demonstrates, but not as good for the horizontal one, which can be seen if you use, say, the ‘ftview’ FreeType demo tool to test the various autohinter modes. And there is no hinting for diagonals at all.

Please don't forget that the autohinter in FreeType has been designed to do real-time hinting. In my opinion, David Turner has done an excellent job in designing and implementing it. If you remove the real-time constraint, a lot of improvements should be possible.

The primary goal of ttfautohint was (and still is) to bring the quality of FreeType's autohinter to the non-FreeType world. With the suggestions and wishes you all provide, it should be able to make it more versatile.

John,

the main reason for needing OpenType support is automatic script recognition. How shall ttfautohint know whether a particular glyph is Latin or Arabic, say?

Regarding VTT support, this has no priority right now. The next step is to improve ttfautohint's basic abilities so that it does its announced job as expected.

For the stem density in full-pixel smoothing environments problem, as you call it, the already mentioned ‘warper’ code in FreeType might help at a very basic level. Again, this is something to explore in the next months.

@Frode: Have you read this nice, old article?

http://www.antigrain.com/research/font_rasterization/

The shown results are quite convincing, and DW ClearType is essentially heading into this direction IMHO.

lemzwerg: I just read halfway through. It's a bit too much right now, but in any case the writer says:

"I do respect the pixel grid, but only in the Y-direction. In the X direction the sub-pixel positioning must be allowed. In this case we can reasonably sacrifice some sharpness (very gently!), but obtain freedom."

In Win XP this sharpness you sacrifice is not reasonable. Yes, it can theoretically be done, but the system wasn't designed to allow and the system moves slow. This whole thing seems to be written from an engineeer's point of view: there's no mention (yet) of the importance of consistent rendering and weight of stems and rounds in x-direction. There's a reason why even colour is the alpha and omega of type design.

John Hudson: Which aspects of the FontLab process can't be reviewed and discussed by the public? [Serious question.] The actual algorithm used to auto-generate the stem hints, I suppose. What else?

I wonder if the output of the algorithm, being itself a program, is subject to the copyright of the algorithm - as that is the result of the yyparse() function in http://en.wikipedia.org/wiki/GNU_bison

Karsten – this is what I understand to be the way to go according to Microsoft
John – With the caveat that this applies if one is targeting only subpixel rendering environments. Part of the continuing need for hinting with regard to webfonts is to support the still significant number of users not using subpixel rendering, esp. XP users.

I know. This was my argument against y-direction-only.  :)
(The other part of the argument is that Microsoft – and Adobe – first of all address new platform/application versions when making new fonts for these. It allows them to make relatively safe assumptions about these fonts' target rasterizer. Independent foundries need to address whatever still-popular versions are out there. They cannot follow Microsoft's practice – the premise is a different one.)
Resolved anyway, however, since Herr Lemberg already wrote "it's trivial to add hinting à la FreeType's autohinter along the x axis".

@lemzerg

ttfautohint-Support Web Typography

Good luck and keep going. It sounds like you've got a solid grasp of the issues and the right priorities.

rich

Thanks, Richard! Being a very slow worker, I definitely need such a priority list :-)

Frode,

at the cost of larger fonts (due to more bytecode) I think your concerns regarding even stem colour along the x axis can be handled automatically to a certain extent by a forthcoming version of ttfautohint, using the techniques already available in FreeType's autohinter.

However, there is room for improvements, using algorithms not part of FreeType, but this is something yet to investigate.

Werner: the main reason for needing OpenType support is automatic script recognition. How shall ttfautohint know whether a particular glyph is Latin or Arabic, say?

Ah, that makes sense. In theory, there could still be some ambiguities, with the same unencoded glyph being used accessed via GSUB in more than one script, but I imagine those situations would be rare.

Regarding VTT support, this has no priority right now.

Understood. I meant that if/when you get to the stage of adding support for higher level language expression I would favour prioritising VTT talk over e.g. FontLab expression.

Extensis is seriously considering support. We will likely kick in some funding.

I can only second John's comment on the importance of considering x-direction hinting and non-ClearType GDI environments, however. This is important to Extensis, at least for another year or two. If there was no plan to address such rendering, we probably wouldn't help with funding today.

Regarding Rich's rejoinder: if it doesn't yield good results in the x-direction under GDI greyscale rendering, it may be worse rather than better in that environment, which won't fly right now for us.

T

@tp

"Regarding Rich's rejoinder: if it doesn't yield good results in the x-direction under GDI greyscale rendering, it may be worse rather than better in that environment, which won't fly right now for us."

I understand. And I'm usually the one arguing for Windows users and as much backwards compatibility as is feasible. But, forgive the pun, I think it's a grey area. There's always a cut-off point. (And I'm not sure what you consider "good results".)

I'd love to hear why it won't "fly". What's your thinking?
Ten years ago when I was doing network support in Manhattan, there was no greyscale anymore even then. (But I actually did experience a greyscale sighting just recently at a Marriott hotel in North Carolina. So, it does exist.)

But who's afraid of the big bad greyscale wolf?
And where is Sii when you need him? How about MSFT shares it's telemetry with us so we can actually know what percentage of users will get the degraded performance?

Later,

rich

Without going into painful detail, my estimate is 20% of web viewers are viewing on browsers with GDI greyscale rendering. That's too many for us, is my take.

Yeah, in a year and a half or two years it will be like 5-8% and that will probably be time to give up on these poor people. But not today.

T

JH: ...prioritise VTT in this regard?
I 2nd the suggestion for the same clearly described reasons. 

JH: ...the results [of automatic x hinting] are never going to be as good as manual hinting for these environments [low res enough to make adjacentcy fail regularly enough to effect readability]...

Is so utterly common up to 25-30 pixels per em, that auto hinting developers should simply surrender, IMHO, on the grounds that the tri-pronged diversity in x, glyphs + designs + x rendering technologies defines the problem as manual, unless someone has a breakthrough under development somewhere... ;)

Then to warp to the end of thread, I've been listening patiently to the puzzling over how many Vindows users are in Greyscale of some kind, and wonder "what's the goll-darn difference?" I've worked with clients, off web, where the font developer can make a staggering qualitative difference in low ppm text because the users are all in GS mode. But if font engineering cannot count on the vast majority or all of the users using GS, economics just say no!

Lemzwerg: "Dave,"

I assume this means me, though I'm usually either David, dberlow, or "guy with hair on fire because diversity in appearance of text at low res only severs those who seek to retard the web for the majority"...

Lemzwerg: ...don't forget that the autohinter in FreeType has been designed to do real-time hinting...

If by realtime, you mean on-the-fly or otherwise without human intervention, then I guess JH and my point of post auto hinting interaction are largely problematic and moot?

Sorry, @abattis. Musta been fumed out. Was thinking of Nick's statement right before your post.

@John Hudson: Whatever ttfautohint does or does not do, there are several cases where the result looks better than the original on my cruſty old Win98 laptop.

@dberlow (not called “Dave” :-) FreeType's autohinter has been designed about ten years ago (!) to do on-the-fly hinting. This then limited the possible algorithms to the ones which don't need too much processor time. It by no means implies that the derived ttfautohint processor has the same limitations.

The idea of post-processing the hints is probably the future IMHO if ttfautohint is going to be integrated into font editors. As far as I know, no font editor is able to add hints. Right now, all of them replace hints.

@lemzwerg

>As far as I know, no font editor is able to add hints.
>Right now, all of them replace hints.

I've added Deltas to existing hints in FontLab. But basically you're right and it's all a giant pain in the ass. There's no modularity that I can see. Everything is intertwined.
I think of TT hinting as connecting the points with rubber bands. Snip one band and all hell breaks loose.

TT hinting seems to me like a very poorly conceived system, frankly. It addresses a genuine problem but if Apple/Microsoft could go back and do it all over again, I doubt this would be the system devised.

But it's too firmly ingrained to replace. So here we are.

There are a number of proprietary autohinters out there (owned by various folks) that do auto-hinting and can produce VTT code, which can then be further tweaked by hand. I think I know of three or four such beasts. I tried talking one owner of such a proprietary auto-hinter into making theirs publicly available, but they resisted due to concerns about support costs/issues. (You know who you are! :)

This sort of approach seems immensely sensible and sane to me. It may or may not be cost effective in all cases, but it clearly is a huge leg up on getting hand-hinted fonts for a lot less work.

A regular auto-hinter that doesn't generate VTT code is still highly useful, of course.

Cheers,

T

"TT hinting seems to me like a very poorly conceived system, frankly."

To get to the point would be too much to ask but I'm sure you mean the compiled-to-confusion form of TT as shown via FL or VTT lacks the current UI needs of a user interface for "dummies like us."

Or perhaps not.

@db
Not. But not worth pursuing the line of thought. I'm sorry I wrote it already. More weather I'm complaining about.

Spent a lot of time reading off my iPhone yesterday.
It's an existence proof:
TT hinting will eventually go the way of the dodo - once you have the pixel density it's obviously not worth the trouble. Text clear as a bell, at any size. Print-like in a lot of ways.

If you'd like to take on THAT thought, I'd love to hear what you have to say.

Forever Dumbly,

rich

@TP: If the made it public free software, they would absolve themselves of the costs :)

@RF: Sure, everyone acknowledges that this is all a temporary measure until those screens are on tablet, netbooks, laptops and desktops, and this will take a few years.

Dave: Sure, everyone acknowledges that this is all a temporary measure until those screens are on tablet, netbooks, laptops and desktops, and this will take a few years.

The manufacturing costs of high resolution screens increase exponentially as screens get larger, due to the high attrition rate of dead pixels and other problems. Screen resolution will likely improve for smaller tablets and netbooks but not for laptops and desktop displays. Manufacturing an iPhone 4 display with 614,400 pixels for a smart phone is a different proposition from making displays of 8,516,520 pixels for a 13" laptop.

The "Devices sorted by size" chart here is instructive. Note that with the exception of the IBM T220/T221 'Big Bertha' displays (discontinued) all displays of 200ppi or higher are no larger than 8", with most being below 5". There is a fairly steady decrease in resolution as screen size increases.

I remember back when ClearType was first announced in the late 1990s, the indication from several major laptop manufacturers was that they would be moving to a baseline 120ppi resolution within a couple of years. It didn't happen. It seems to me that 'those screens' are always 'a few years' away.

It may happen, but I stopped holding my breath around 2002.

John, isn't the typical Macbook somewhere around 130 ppi?

Frode, the Macbooks range from 100-130 ppi. My comment re. 'it didn't happen' was that 120ppi+ didn't happen in the time frame of a couple of years that was expected in the late 1990s, and it didn't happen across the board.

[Note also that 120ppi was only the baseline necessary to hit the ClearType 'sweet spot'. There's a long way to go from there to a place where one doesn't need hinting.]

Not enough DPI soon enough... I told you so in 2005!? ;)

You did indeed, David. And you were right.

I was lulled into false confidence by the first signs of 120+ ppi laptops appearing in the early 2000s, which I took as a sign that the manufacturers really were going to follow through. Instead, such screens became speciality items for high-end machines -- such as my 133 ppi Toshiba and 145 ppi Dell -- and there wasn't a general increase in average display resolution for either laptops or desktop displays. In trying to understand why it didn't happen, I learned more about screen manufacturing and the problems of attrition as you increase resolution. So now I'm sceptical about the likelihood of significant increases in resolution for larger devices.

Re: Hi DPI screens.
Gonna be a long time comin', that's for sure. abattis might be as gray as me by then.

In the meantime, all Werner's got is 377 bucks according to Pledgie.
And a not insignificant percentage of that is from me.

All talk no action so far, ladies and gentlemen.
I mean, I don't want to call anybody cheap but, uh, I heard that one of the guys on this thread is so cheap he turns off the gas while he flips the burgers on the barbecue.
But then again, being cheap can get results. Copper wire was invented when two of the guys on this thread found the same penny at the same time in the hotel lobby at TypeCon.

Once again the link is:
http://pledgie.com/campaigns/15816

> "All talk no action so far, ladies and gentlemen."

Lol, I wish. Unfortunately, the unenvisioners had diagnosed the problem as needing a wrapper, and 'ave put it in place. On the heels of this suckcess, they now endeavor to stuff more Barf into it so that WOFF is going to become a tourniquet around the neck of web publishing ;(

David,

your last comment is completely cryptic for me. Could you elaborate, please?

lemzwerg, ttf auto hint outputs ttfs, I assume. Since ttf is the actual default font format of the web accepted I think by all the major browsers, including the latest visions of IE, you have no need to concern yourself with decrypting my comment.

Yes, ttfautohint emits TTFs, but this could be changed to any outline format which uses TrueType bytecode for hinting.

Perhaps more money would be raised if this were publicized on the web design blogs and forums, or perhaps associated with fonts in the Google font directory itself - "don't like the quality of this font's hinting? Pledge here!"

I think Sii is on the right track, but... I think the idea in a lot of cases if for the message to be, "don't like the quality of this font's hinting?", click here, and the ttf will be auto-hinted, re-manufactured, re-located and re-served.

dberlow: Don't put the cart before the horse :-)

Sii: Yes, I'm doing what I can to publicize it, and I'll speak to the team about that idea too :-)

@dberlow

"... and the ttf will be auto-hinted, re-manufactured, re-located and re-served."

Well, that's exactly what's beginning to happen at Kernest Konstellations with the RasterBRIDGE™ line of fonts. I agree with abattis in that, without good tools, what's the point of reprocessing? (I think that's what he meant.) It's the first requirement.

Have you donated yet?

>Have you donated yet?

Lol, that information is only available in the smoke-filled back-rooms of the type mafia cabal. You want to cut off a pinky, you're welcome to apply.

abattis quoting me> Don't put the cart before the horse :-)

I have a pretty clear notion that the horse and cart arrangement is seriously in need of rethinking, from one end of web typography, (what the font?) to the other, (what the output device?). At http://t.co/EzTowt1, one can read the early public emergence of the notion that it's more than fonts that need hinting. To be as clear as possible on this, people outside of my circle of fiends are starting to realize that a three column grid with two gutters and two margins has a lot in common with a lowercase "m". The sooner the developers of auto-hinting catch on to this, the sooner the idea I just spotlit will spread from fonts to where hinting needs to begin. Have at it ;)

David: ...ttf is the actual default font format of the web accepted I think by all the major browsers, including the latest visions of IE...

There isn't any single default font format of the web today, because compatibility with the large number of older versions of browsers still in use requires serving at least two different formats.

IE9's raw TTF webfont support requires installable document embedding permission and is explicitly targeted at libre fonts. Personally, I wouldn't want to set the embedding bits on a font in that way just to be able to serve it to IE9 in that format, since that embedding bit can be legitimately interpreted by any piece of software as allowing the font to be installed on the recipients system, independent of the action or intention of the webfont licensee. IE9's raw TTF support really only makes sense in the context of libre font licensing.

With the release of Safari 5.1 in July, current versions of all the major desktop browsers now support WOFF, as do a growing number of mobile browsers. If we eventually reach a point at which there is a single served format equally supported everywhere, that format is going to be WOFF, because that's the only format on which browser makers are all concentrating, the only format that is on the road to being a W3C web standard, and the only format for which there is a web-specific implementation spec and test suites.

The font data content of WOFF files is likely to remain predominantly TTF for text for a long time to come, I reckon; but we've already seen an increase in the use of CFF for display web type.

>I wouldn't want to set the embedding bits on a font in that way just to be able to serve it to IE9 in that format,

How you say in Canadian? The horses are out of the barn on the embedding bits.

>WOFF, because that's the only format on which browser makers are all concentrating

Proof is in the pudding, and the pudding says otherwise.

And on the side, like a slab of quivering bacon, if that's not true, then what's all the nonsense about absorbing SVG into OT?

..with a hint of lime, it saves time ;-)

David, we're clearly eating different puddings. As I pointed out, as of July all the major desktop browsers support WOFF, all the major browser makers have been actively involved in the specification of the WOFF format. I don't see effort being expended on other formats, and IE9's raw TTF support is so heavily laden with caveats about the installability of the fonts on remote systems that I doubt if many of your colleagues will want to license for it.

And on the side, like a slab of quivering bacon, if that's not true, then what's all the nonsense about absorbing SVG into OT?

In general terms, it is about finding a way to add colour and animation to scalable fonts. In specific terms it is about supporting emoji characters.