When Safari added support for raw fonts over the strong objections of the web design and font community, one of the main concerns voiced was that unlicensed commercial desktop fonts would be posted to the web either in deliberate violation of the font’s EULA or in ignorance of license restrictions. Apple’s PR mentioning that “any” font could be used under their scheme fueled those concerns.

As I described at ATypI last year the motivation for only supporting raw fonts set to installable embedding is to minimize the risks around posting of commercial desktop fonts. Commercial desktop fonts are not set to installable embedding, and a Web designer flipping the bits in commercial fonts would no longer be able to claim ignorance around licensing. I hope this restriction will reduce foundries policing and legal costs, and reduce associated ill-will around sending C&D's to small web site owners.

This solution is not perfect. I would have preferred a new opt-in, and I know most font vendors wanted IE hold-out against any support for raw fonts. However, I hope that future IE blog posts will explain the motivation here, and remove the misconception that the definitions of the embedding permissions have changed.

Still interested in type designers and font vendors feelings about this. Given the publicity around font licensing, are the concerns of a few years back still valid? Have web designers got the message about font licensing? Should IE drop this restriction?

IE definitely should not drop this restriction, Si.

The reasons why WOFF exists and is being defined as a Web standard remain as valid now as they were a year ago when we started down that path. We've come a long way -- signalled not least by both Microsoft and Opera co-submitting the WOFF spec to the W3C along with Mozilla --, and that's because the concerns about casual misuse of TTF/OTF fonts in a Web-distributed environment are reasonable and need to be addressed. There's a lot of consensus now between font makers and browser makers regarding WOFF, including things like same origin restriction that I thought might be more contentious than it was.

My preference, as you know, is for IE9 to completely remove support for raw TTF/OTF before release. I don't see any good argument for a browser that supports WOFF to support raw fonts. The idea that this benefits free and open source font makers/users isn't very convincing, because any free or open source font can be freely and openly packaged as a WOFF file and gains compression in the process. Simply put, WOFF is a better technical format for web typography than raw fonts. Further, as I argued on the W3C font list last year, the onus is on protecting that which is most at risk, not on protecting that which does not require protection. Commercial fonts need protection from casual unlicensed use; free fonts do not need protection from technically beneficient formats into which they may be freely packaged.

I accept your arguments, Si, for why the embedding bit is implemented and how it protects the majority of fonts against unlicensed Web use with IE. But I still don't see any good grounds for supporting the raw fonts in the first place, and while the restriction will ‘reduce foundries policing and legal costs’ relative to open raw font linking, it will increase them relative to not supporting raw fonts at all.

As for checking off another random feature in the Acid 3 test... I call bullshіt on a nominal Web standards test that demands support for something that isn't a Web standard. And I think Microsoft should call bullshіt on it too.

I look forward to future IE blog posts further explaining the thinking behind the raw fonts support. But I'm not expecting to have my opinion reformed.

.

I hate to follow a squirrel dropping, but...

sii>Commercial desktop fonts are not set to installable embedding...

first off, for a recent client, we originally sent TT/OTF fonts set to Editable Embedding. They were unable to embed the fonts using MSOffice 2003. We tested the fonts locally using WindowsXP and Word 2007 and had the same result.

We rebuild the fonts as: TT/OTF with Installable Embedding. Our tests showed the fonts then embedding using WindowsXP and Word 2007. The client also embedded the fonts successfully with Word 2003, 2007 and 2010.

So on one hand you are saying that we don't set the bit this way for print clients, but on the other, if clients are to use fonts with the embedding bits as intended, we have to set for both print and web the same. I think that's a no-go part as they say in the airline industry.

In Mexico, I asked you what to call the introduction of a web font to the system so that it could be used for the display of web sites, but not appear in menus or the fonts folder, and you wanted to call it "enumerated to the system." So, what are we to call fonts with bits set to install, that enumerate but don't install? ;)

sii> Still interested in type designers and font vendors feelings about this.

I guess my meelings are fixed.

Cheers!

@sii

Thanks for your take on this. And you know I would not have minded one bit (sorry) if JH got his druthers and TTF/OTF were *not* supported. But I understand that the IE team's hand was forced by several factors.
(And if I shouted the "D" word a little too loudly, perhaps I've been insensitive. I can see that.)

DB's story sums up my misgivings, also. No matter what side of the argument I argue - and I can argue both sides, with feeling, on this one - nothing persuasive emerges.
All I'm left with is yet another weird complication I - and every web author, font designer, anybody - has to factor into an already complicated mix.

I mean, it would be a heck of thing if - in trying to help font designers - all you got for the effort was *everybody* muttering about IE9 and why the heck did MSFT make everybody's life more complicated? Just couldn't leave it simple, huh?
I think if you look five years down the road, maybe a lot less, that's what you're going to get.

. .. . ... <--- Ha ha who cares about fonts anyway. Look at me, I made lot's o' squirrel doo! Thanks DB for the laugh.

David makes a valid point there are a handful of commercial fonts out that that have been intentionally and in some cases unintentionally set to "installable". That's why it's important to note that we're not saying "installable = redistributable", rather "installable = probably not commercial" - there's no way to avoid the standard issue answer of "read the eula".

Cheers, Si

Sure, read the EULA. Read it over breakfast when there are no newspapers left. :)

But in terms of what the IE9 implementation is ‘saying’ -- which isn't necessarily the same as what Microsoft is saying here or at ATypI etc., but is likely to be louder and heard by more people --, I find it hard to escape the implication that ‘installable = web linkable’ -- since that is the functionality of the implementation --, and by principle of equivalence ‘web linkable = installable’. The latter is what I really think you should not be saying, or even suggesting coyly.

Thanks for you thoughtful responses. So, what you are saying Sii is that your products, in order to function as advertised, (and unless a user needs a font for both embedding in word and linking to IE), require that we put conflicting embedding bits in our fonts. Have I got that right?

Cheers!

>I find it had to escape the implication that ‘installable = web linkable’ -- since that is the functionality of the implementation --, and by principle of equivalence ‘web linkable = installable’.

Can anyone decode this? What "had to escape the implication".

Cheers!

David — There’s a typo. I’m certain JH meant “I find it hard to escape the implication . . .”

Yes, typo. Fixed.

>Have I got that right?

I would recommend licensing web-linked fonts in the WOFF format, and leave raw fonts to the open source and freeware crowd.

> I find it hard to escape the implication that ‘installable = web linkable’ --

Yep, that's indeed the main problem with this approach.

Geeze, I wish I could read better.

>I would recommend licensing web-linked fonts in the WOFF format,

Is that what Microsoft is planning to do?

Cheers!

@sii and everybody:

If this decision stands, I am concerned about the technical repercussions.
IE9 can't know if a TTF or CFF font is "unsuitable by reason of installability" as a web font until it downloads it and inspects. This takes time - at least until the font is cached.
At that point, if the font is deemed installable, I believe the plan is for IE9 to do a lookback to see if any other resource in *any other* @font-face font stack within the rule might be suitable. (Still more time taken.)

Frankly, I'm having trouble wrapping my mind around exactly what this means without testing and I find the IE9 preview unwieldy for testing. (When my consulting partner in New York passed away a couple of years ago, my Technet subscription and some other Microsoft affiliations fell through the cracks - so I don't have a build to play with, if there is one available.)
So I'll revisit when I have more hands-on and hopefully by then some other Typophile members might have had a chance to assess. It's vacation time.

Lastly, from the department of "Please Don't Pee On My Leg And tell Me It's Raining", I have found the IE Blog posts about this to be a tad on the spinful side. The "must not be set to installable" aspect of the TTF/OTF support is being deliberately played down - let us not talk falsely.

Along with JH, I eagerly await further explanation. (Although I think I could write it myself - perhaps I should and see how it compares.)

rich

>aspect of the TTF/OTF support is being deliberately played down - let us not talk falsely.

Raw font support should be played down as should EOT support. The future is WOFF.

It was a simple question: Is MS licensing web-linked fonts in the WOFF format?

Bundled fonts: We have boilerplate language in our product EULAs that disallows font format conversion and modification and also limits redistribution to temporary download to output devices (like laser printers) and document embedding based on the embedding permissions in each font. So based on this our product EULAs do not currently allow our fonts to be converted to WOFF for linking.

Individual fonts: We typically do not license individual Microsoft owned fonts to web developers. Instead we have an agreement with Ascender Corp to license them on our behalf. Ascender is free to license our fonts in WOFF format to their customers.

As Si has pointed out, Ascender is actively offering web fonts licenses for many of the fonts featured in Microsoft Windows and Microsoft Office. Our FontsLive.com web font service does indeed support WOFF. FontsLive also dynamically supports the other formats required to serve web fonts to the various web browsers.

I firmly agree that WOFF is the future for web fonts and we should focus on that.

Installable Embedding is a reasonable compromise, so it is better than nothing for a raw font. Yes, we too would have preferred that IE9 not support raw fonts, but we understand their reasons.

Maybe we should instead focus on writing emails to the Acid3 folks to get them to add support for WOFF to their tests, so then IE9 could drop raw fonts! Rich - do you know who we should contact to start up a campaign to get WOFF support added to the Acid3 tests?

I mentioned the Acid3 test in Mexico and in an earlier post. Should point out that IE’s support for raw fonts is not a knee-jerk reaction to Acid3, but rather to keep pace with competing browsers font-format support. Note slide 29 here http://people.mozilla.org/~jdaggett/webfontsfuture.pdf

Si: ...to keep pace with competing browsers font-format support. Note slide 29 her...

Still doesn't make any sense to me. John Daggett's slide shows exactly what we don't want browser font-format support to look like: with TTF/OTF looking as if it is the cross-browser format of choice. It isn't, and IE9's embedding bit restricted implementation doesn't make it so: it just gives that impression in an un-annotated comparison that gives an incomplete picture. Here is what that comparison should look like:

In this view, IE doesn't need to keep pace with a non-standard font-format approach because you're ahead of two of the four other browsers in the standard approach. Why waste time and coding on supporting something that is unnecessary, doesn't provide any benefit, isn't compatible with other browser implementations of the same format anyway, [edit: excise ‘will make IE slower than other browsers due to added processing of checking embedding bits’ -- apparently not the case according to IE programmer], and makes me grumpy?

John, I do not believe the IE team added this deliberately to make you grumpy :-(

Richard, I've passed on the "perf" concerns to the appropriate engineer in IE.

BD> Ascender is actively offering web fonts licenses for many of the fonts featured in Microsoft Windows and Microsoft Office.

Thanks for that news.

The question is what will come bundled with MS software, and if the answer is that the installed base of EULAs is prohibiting change, you can imagine perhaps how the same environment effects other developers as the tide of format acceptance sloshes back and forth. Will your EULAs change as new systems and UAs are delivered?

JH> Here is what that comparison should look like:

...but what it really is, is red dots all along the top and blue dots all along the left column, (now with IE OT linking) with W3C and developers never dropping OT and SVG support. When WOFF becomes the future, I'll wear spandex for a week and fly around in a sky car in penitence for my ignorance.

Cheers!

>Will your EULAs change as new systems and UAs are delivered?

Don't know. Probably not. Will as you say, depend on what other font suppliers allow.

David: but what it really is, is red dots all along the top

Nope. The W3C are standardising a single web font format, and that's WOFF. None of the other formats supported by browsers for @font-face are W3C standards. The W3C will standardise some things that are to be expected of web fonts independent of format, but only one format is being standardised.

I've no idea where to buy spandex, but you can get your sky car here:
http://www.terrafugia.com/

Between web authors being able to license web font versions of MS fonts from Ascender and the possibility of Microsoft or a partner setting up a web font server system as Google are doing, I don't see any need for a Windows EULA to permit user conversion of bundled system fonts to WOFF.

:)

Sii>Probably not [EULA changes at MS]

Well, you can only go on for so long without changing the input as technology runs on to new outputs. Are not some or all of the fonts you’all bundle set for installing so they work with Word?

JH> The W3C are standardizing a single web font format, and that's WOFF.

Tell your vision to the website designers who need installable desktop fonts to do their jobs, now and for the unforseeable future. And to the founders making or licensing fonts only for the web. And to the godfather of web type, who's WOFF emedding for print. And tell it to the “other” Microsoft, the one that Sii bravely represents to us. And tell it to the phantoms making interactive web design tools. If you don't understand what I’m talking about, envision solutions today, and envision a plan for getting all kinds of developers and developerees to the all-WOFF future you and Mr. Davis have in mind.

But in the mean time, OT is the commonly supported format. So, (ahem), should we add some information to the OT spec, or what?

Maybe the garden fence idea of EOT and WOFF are great, but several kinds of time and thus many kinds of money are against them. MS helped us all cut the ribbon on the completed garden fence. But then, when we came back from the pub, there was a superhighway. This is, as they said, the best MS could do. A mass for the garden will be said at noon on the 28th, in the main chapel of St. Bonaventura de la Futura, corner of Baskeville and Helvetica, bring peas and carrots.

Cheers!

>Are not some or all of the fonts you’all bundle set for installing so they work with Word?

No. Historically there were four settings, no embedding, print and preview, editable and installable. Originally Word supported the installable setting as spec’d, and would permanently install (enumerate) embedded fonts set to installable in the system. Although such fonts were relatively uncommon this did cause some user confusion and support issues “how did font ‘x’ get on my system?”. With the Internet and the increased attack vectors and the possibilities of mischief we decided that support for installable embedding was probably a bad idea, and at that point Word started treating “installable” fonts as “editable”, at that point we also set the handful of “installable” fonts we were shipping to “editable”. In general we try to only ship fonts set to “editable.”

Earlier in this thread you mentioned having to set fonts to “installable” to solve customer issues. That’s not something I’d encountered before. Happy to investigate that at our end if you can provide a repro case.

David, we've been here before. Everyone was telling me that Type 1 PS fonts were going to be the commonly supported format for so long and that OpenType was only maybe going to be the future, maybe one day, maybe just on Windows, maybe never in Quark Xpress which was, of course, going to be the most widely used page layout software forever.

There is no ‘commonly supported format’ for web fonts. In terms of widely used current browsers there is a combination of EOT and TTF/OTF. Any web designer who thinks he can ‘do his job’ with TTF/OTF only isn't serving well over half his audience. So we're already in a situation of web designers having to serve multiple formats for different browsers, and that is the situation that is not going to change any time very soon. What is going to change soon -- what is already changing -- is browser makers rapidly moving to support a genuine common format in their new browsers, which is WOFF. I can say this with some certainty: EOT as a necessary compatibility evil is going to stick around a heck of a lot longer than raw font linking. From where I'm sitting, raw font linking is already an obsolete technology -- an ‘also ran’ like SVG, Flash fonts, PhotoFonts, etc. --, and IE9's embedding bit-restricted implementation does nothing to change this. Indeed, one of the things that I find weird about IE9's support for raw font linking is that it seems so 2009.

This is all very enlightening.

I have to agree with John, but with the sole caveat that alarms have been raised since the word "Napster" entered the English lexicon. Piracy is a thing of the present, past, and the future and I think that developers will be focusing on preparedness—and not—alternative directions.

That said... typography isn't well understood by the public. Unless you are explicitly worried about DESIGNERS stealing fonts—and on that we can agree—I'm not so sure how many people we can expect digging through web servers to pilfer out what they most desire.

(Funny story: The only person I know who ever tried to pirate a font did so after I suggested they take Pentagram's "What Type are you?" test. Touching in a perverse way.)

As to db's concern: I'm no software developer but should we see no reason why a TTF/OT conversion service should not be made available? I'm fuzzy on details concerning current conversion services (!!) but if what WOFF has to offer us is compression and meta data I do not see—in theory only—how those elements cannot be tacked on retrospectively but a nicely built piece of code.

It's always comforting when people who are fuzzy on the details agree with John. ;)

JH> Any web designer who thinks he can ‘do his job’ with TTF/OTF only isn't serving well over half his audience

You missed dah point. What I said is that web designers who use Photoshop e.g., CANNOT do their job without OT (Comprendo!?). But as of IE9, they can do their jobs and serve well over half the audience too.

Unless someone drops support for OT before MS releases IE9, the planets are aligned for people making fonts and web sites, (as opposed to people making trouble and quite literally nothing else).

Cheers!

sii> Originally Word supported the installable setting as spec’d, and would permanently install (enumerate) embedded fonts set to installable in the system. [...] this did cause some user confusion and support issues “how did font ‘x’ get on my system?”

Please — Enumerate, was a term you gave to me to describe an installed but menu-invisible font. You seem to be confused by my use of your term. Installed means (meant) the user was able to see the font in menus, and we were looking for another term when users could not see the fonts in menus — Remembré?

And yes, I can imagine users who spend 2% of their entire lives watching windows updates with 100's of files, becoming utterly alarmed by fonts showing up in their menus via documents. As we all know most windows users have their font menus memorized, so the support for install-bit fonts must have been truly and amazingly massive.

But overall, it seems MS has "roto-tilled" the definitions of the embedding bits so users and developers no longer can count on the definitions matching actions of your products. Is that a fair description of the state of Microsoft's treatment of these bits found in ISO's OFF specification?

Cheers!

@sii,

>Have web designers got the message about font licensing?

And what might that "message" be, pray tell?

Here's my challenge to you Sii: write up a one, two, hey - even three paragraph guide called, "Font Licensing: What Web Authors Should Know" and publish it. Tell me simply, briefly, succinctly, and accurately exactly how web authors should go about making decisions regarding font licensing. Go ahead, I double dare ya.

The fact is - in the absence of a universal standaradized font license - you can't do it. Nobody can. Not you, not your lawyers. Plus you wouldn't do it anyway because such a thing would need to draw a "bright line" - and FUD (fear, uncertainty, and doubt) works much more to your advantage.

The best I can do is parrot Hillel:
"Do not do unto others as you would not have them do unto you."
Howzat sound for a rule of thumb?

I fear, frankly, that IE9's enforcement of the bits is born of nothing more than petulance - a wag of the finger. If MSFT is collectively pissed that, with regards to EOT and web fonts, it got the rug pulled out from under them, I can understand that. But I hope everybody isn't being made to pay for MSFT's frustrations.
You win some, you lose some.
Arguing "consistency" - which what the argument is going to be, right? - is, in this instance, baloney.

Here's what I've decided to do:
Once IE9 goes into public Beta and the practical implications of handling raw fonts this way - on web authors, font producers, whoever - becomes more clear, I will be using EOTFAST's mailing list - for the first time - to hang a lantern on this and get a reaction. The list is pretty large at this point and includes a lot of font savvy people who actually know what embedding bits are.

This will be done transparently so everybody can be kept in the loop.
And the results will be published.

On the subject of data - I have no doubt that the IE team has compiled much data to support this decision. The problem is that data from a world in which there is no ubiquitous @font-face support and every other browser ignores the bits, means zilch.

@bill davis

>web fonts licenses

Ascender is not offering "web fonts licenses" but you keep saying it does.
I know they pay you to do that but still.
You may feel it's harmless sales puffery - putting your best foot forward.
I call it Orwellian Newspeak. A subscription to a FHOS service is not a "web fonts license" by any web author's - or anybody's - ordinary understanding of the term.

Bill, the terms and conditions under which Ascender decides to offer fonts is Ascender's decision. My objecting to it or not objecting to it rests on practical considerations from the web user's and web author's point of view.
But call it what it is, please.
(Or are we going to have to have yet another smack-down to settle this once and for all?)

Later, I gotta go aggravate other people now.

David, sorry for confusing the term enumerate.

>But overall, it seems MS has "roto-tilled" the definitions of the embedding bits so users and developers no longer can count on the definitions matching actions of your products. Is that a fair description of the state of Microsoft's treatment of these bits found in ISO's OFF specification?

No, not at all. The embedding permissions were defined with foundry input, and we’ve gone to lengths to ensure that we observe them, for example in locking documents that contain a print & preview embedded fonts. The fact that we stopped installing "installable" embedding fonts, but didn't propose changing the wording of the spec meant that we were not imposing our view on the rest of the app development community.

>And what might that "message" be, pray tell?

Just because you can link to any font via @font-face doesn’t mean you are allowed to, in fact you probably aren't. Read the license, check with the foundry.

>Here's my challenge to you Sii: write up a one, two, hey - even three paragraph guide called, "Font Licensing: What Web Authors Should Know" and publish it

No problem...

Just because you can link to any font via @font-face doesn’t mean you are allowed to, in fact you probably aren't. Read the license, check with the foundry.

WRT the IE team (like all the browser makers) just supporting raw fonts over the objections of font designers, and letting the market sort things out would have been the path of least resistance. The fact that Mozilla and IE did take on board the views of type designers and submitted WOFF for standardization speaks to them doing the right thing.

WRT to Ascender, for sure they're pushing a service model, that seems like the best approach right now from a support (need to serve four formats) and business perspective. But I know they are licensing WOFFs - as I licensed two fonts in that format for our IE9 Web fonts demo.

RF -- Here's my challenge to you Sii

As a little reminder, this has been discussed here. Trying to keep people busy? Explain yourself. Explain yourself again. And again ... Your "requests" -- lowercase and all-caps versions alike -- have been heard and understood and the answer was: Read the EULA please.

RF -- The list is pretty large at this point and includes a lot of font savvy people who actually know what embedding bits are. This will be done transparently so everybody can be kept in the loop. And the results will be published.

I feel sorry for those who subscribed.

>As a little reminder,

Now you tell me. I'll never get those eight minutes back. :-(

When Rich starts speculating on the psychological motivations behind things he half understands, the conversation must be close to over.

David: What I said is that web designers who use Photoshop e.g., CANNOT do their job without OT (Comprendo!?). But as of IE9, they can do their jobs and serve well over half the audience too.

Well no, they can't, because the fonts that they're using in Photoshop are not licensed for Web linking. And even if they were, most of them wouldn't work as raw fonts with IE9 anyway on account of the fact that the embedding bits are most likely set to 'Print and Preview', which is the most common setting for commercially licensed fonts. So they're going to need new licenses and new fonts, regardless of what format they're serving to particular browsers. [Of course, you're going to want to do that anyway, since you want to add metadata to your web-licensed fonts.] And they're also going to need EOT because any web designer who doesn't care about IE6-8 isn't really a web designer, not matter how pretty his websites look in Safari, any more than someone who beautifully roasts a suckling pig for a large party of people whom he has been told are mostly vegetarians is a real chef.

So you'll end up with multiple versions of the same TTF/OTF files kicking around on users systems and servers, with different embedding bit settings, to achieve the same thing in the same IE9 browser that you can achieve on the same day -- not in the future -- with WOFF.

Rich: Here's my challenge to you Sii: write up a one, two, hey - even three paragraph guide called, "Font Licensing: What Web Authors Should Know" and publish it.

Or just take the ‘Font Licensing: What Desktop Publishers Should Know’ guide that every major foundry produced c.1995 and change some of the wording. I know you're very new to all this font and typography stuff, Rich, but some of us have been here before, some of us more than once.

JH>...most of them [OT fonts] wouldn't work as raw fonts with IE9 anyway on account of the fact that the embedding bits are most likely set to 'Print and Preview'

Our new garden fence!

>...they're also going to need EOT because any web designer who doesn't care about IE6-8...

...they're also going to need OT because any web designer who doesn't care about all the other browsers...

>any more than someone who beautifully roasts a suckling pig for a large party of people whom he has been told are mostly vegetarians is a real chef.

So you can imagine my reaction when neither real chefs nor actual vegetarians are involved in the recipe process and the suckling pig is cleverly made of oddly-shaped squash.

Cheers!

David: ...they're also going to need OT because any web designer who doesn't care about all the other browsers...

Of the two browsers in John Daggett's comparison that do not currently support WOFF, one is a co-sponsor of the WOFF format standardisation, and the other appears to be actively engaged in WOFF implementation. Also bear in mind that unlike IE, these other browsers have a proven track record of getting new versions out more often and getting users to update. Backwards compatibility with browser versions that only support raw font linking is not going to be a significant issue.

There are other browsers not included in John D's comparison, of course, including any number of embedded browsers on mobile devices, but they too have a vested interest in implementing web standards and most have a push model for updates (my Palm Pre updated itself a few days ago, without me having to do anything except acknowledge that I wouldn't be able to make phonecalls while it happened).

John: Backwards compatibility with browser versions that only support raw font linking is not going to be a significant issue.

So, my everlasting point, those browsers will maintain backward compatibility forever.

What's the plan? How do we get to an all and only WOFF future?

Cheers!

David: ...those browsers will maintain backward compatibility forever.

So? They'll presumably continue to support SVG fonts forever too. That doesn't make SVG a necessary format for any font foundry to license for.

Browser makers want a single, cross-browser compatible web font format. Web authors want a single, cross-browser compatible web font format. Font vendors want a single, cross-browser compatible web font format. And all three groups have very clearly identified WOFF as the only format on which they can all very readily agree.

Today, the W3C approved transition of the WOFF File Format 1.0 from a working draft to a public review stage.

What's the plan? How do we get to an all and only WOFF future?

By only licensing fonts for web use in WOFF format.

Given the way browsers are now upgraded, I'd say that within a year more than half of users will be working with WOFF-enabled browsers, and the majority of the rest will still be working with browsers that only support EOT. The number working with browsers that only support raw font linking is going to be very small. EOT is going to be a much bigger albatross around the neck of web authors and font vendors for very much longer.

JH:

>Browser makers want... Web authors want a single... Font vendors want...

Browser makers just want OT, it's all OS's can use. Why would they want to convert and enumerate instead of just enumerating? Web authors have not asked for WOFF, just sanity. Font vendors is a relative term: those who do, vs those who talk about talking about it.

>...[all have] identified WOFF as the only format on which they can all very readily agree.

How about now that WOFF has NONE of the features promised; no std. meta data, no embedding bit disambiguation, no garden fence and before it'll be popular enough, or compatible with interactive design tools, OT will already have established itself.

>By only licensing fonts for web use in WOFF format.

That's your plan ;) Like I said, we're in business and this would be bad for our business. EOT was the last albatross, and WOFF is the next one, but through it all, we'll supply OT and no one will complain.

Cheers!

David, you're wrong. Just wrong. I'm tired of debating with you. You and I have a lot of things that we agree on that, in my opinion, are now more important than the web font format issue which is out of your hands. It isn't out of my hands, because I'm actually involved in the W3C standards process, but ultimately all that process can do is provide a mechanism and trust that its benefits will be obvious to browser makers and to our colleagues. I think the benefits are significant and that the result will be that raw font linking is as dead-in-the-water as I want it to be and you will ultimately be happy for it to be.

What is more important? The quality of text fonts on the web. Let's get on with it shall we?

>David, you're wrong. Just wrong.

I have one of the longest resumes on the planet on this issue from a typographic point of view, so please be specific, (or at least choose a winner).

>Let's get on with it shall we?

I stand opposed, John, as a result of quite expensive and time consuming "getting on with it" you will not only experience as a user, I'm sure, as all the fonts, css and templates are open to "study".

>It isn't out of my hands, because I'm actually involved in the W3C standards process...

Meet your latest gesticulation, IE9.

>I'm actually involved in the W3C standards process, but ultimately all that process can do is provide a mechanism and trust that its benefits will be obvious to browser makers and to our colleagues...

I stand opposed, John, as a result of failure of trust coming from the users you have now, and correctly, left out of the "clamor" for WOFF.

Some progress at least.

Cheers!

David, am I reading you wrong? Will FontBureau be distributing OT fonts for the web? Will the webfonts for the Ready-Media website templates you are developing be OT as well?

David, I have been specific. I've pointed out the specific reasons why existing raw font linking in some browsers is irrelevant to the future of web fonts, why IE9's peculiar hobbled raw font linking doesn't change this but only confuses people, why the proven upgrade take-up of all the non-IE browsers makes raw font linking compatibility a short-term issue, why EOT fonts will be a compatibility issue for very much longer than raw font linking, why all the major browser makers have either already implemented WOFF support or are in the process of doing so, why even the browser (Opera) that first introduced raw font linking has already implemented WOFF support, and why no one other than you is still talking about raw font linking.

Meet your latest gesticulation, IE9.

I have. It supports WOFF. Oh, and DWrite rendering for both TTF and CFF. These are significant developments. Implementation of raw font linking that by design can't be used for the majority of fonts and is untouchable by most font vendors because it actually makes web fonts less protected than desktop fonts, by treating them all as installable, is not a significant development. It's just confusing and unnecessary.

fs> Will FontBureau ...

That's secret. Your second question, I have to say R-M templates are made in indesign. I asked, several times, but John seems to think only WOFF-only world only. Oh well, I guess we won't be licensing any of his templates ;)

JH> David, I have been specific.... and why no one other than you is still talking about raw font linking.

All I said is that for the first time, all the browsers will be supporting OT. That's all.

And you have not said how the spandex future works, that OT was here, and then it was gone. That OT sites, designers and development processes were here, and then they were gone.

DW has nothing to do with the topic, but I'm delighted by this 'significant' development.

>It's just confusing and unnecessary.

I understand the first thing, but it'd have to be proven to me that IE with OT linking is unnecessary. And MS obviously agrees with me.

Cheers!

I realize this is off-topic, but did you just say that the Ready-Media WEBSITE templates are being designed in indesign? I realize the magazine ones are... but the RM website says that you are designing the fonts for the WEB templates.

fs>...you are designing the fonts for the WEB templates.

Arguing about formats and piercing the wording of technical documents are not my main jobs. Text designs for the web are an obvious part of the greater "getting-on-with-it" that John speaks of.

That's all mostly in my rear view mirror, though I've got one more family to complete and other designers to help along. These fonts all look outstanding in IE9 regardless of embedding permissions, for the thread's sake.

Cheers!