Spontaneous reaction:

Would it be less confusing if all commercial font producers opt for a no conversion policy, and make the WOFFs themselves?

Yes.

But then ... what about a Win-to-Mac-and-back application conversion tool a la TransType? No need for application developers to ship two or more versions. All power to the end user. :)

I don't think we should force font producers to disallow any user action carried out on their own products (including such conversion). We can't predict the reasons producers will have to allow/disallow whatever they might see fit.

hhp

>Will commercial font licenses that allow for user conversion
>of desktop fonts into WOFF fonts add to web font
>licensing confusion?

You mean it can get even more confusing than it already is? Seems like the question is off the mark.
Why are you stopping at WOFF? Today, and for quite some time to come, having just a WOFF file doesn't do squat.
How about EOT? How about SVG which authors need for mobile Safari on iPhone and iPad?

Better yet, come see my talk at ATYPI: Destination Web to get the scoop on the advantages and disadvantage of all these formats.

This was a question about font licenses. It assumes that WOFF will replace all of the formats you mention. If by some reason it doesn't you can replace (or add to) WOFF with SVG, EOT, FINK, HEF or whatever becomes the dominant format.

Yes font licenses are confusing, however standardized language (as you see with PDF - mostly) can be helpful.

As far as I know by far the most foundries already have a no conversion policy for all formats other than the delivered one, don’t they?

Mostly, but there are some notable exceptions - eg. Adobe. I also think that customers may expect this to be covered in embedding or redistribution sections of the EULA.

.

Since the purpose of woff is to be converted to a desktop format, I think it's a trick question.

Since the purpose of the panel was to explain woff to the public, I guess it was a trick panel.

Cheers!

We should avoid the term ‘conversion’ when talking about creating WOFF files. WOFF is not a font format, it is a font delivery format. The SFNT font data content of a WOFF file is 100% identical to the un-WOFF'd font: there is no conversion of that data taking place, only compression and wrapping.

I don't think it will be possible to get all foundries to formally agree on a single policy with regard to whether to permit WOFF creation by customers, any more than it has been possible to get them all to agree on a common EULA. One can certainly point out to foundries that permitting customers to create their own WOFF files from licensed desktop fonts sort of means not taking advantage of one of the features of WOFF, which is the ability to include web specific and customer specific metadata in the WOFF'd font. If you allow end users to create their own WOFF files, those files are indistinguishable on the web from illegitimately created WOFF files from existing desktop fonts. Since one of the main ideas behind WOFF was to draw a line, at the delivery format level, between new web licensed fonts and existing desktop licensed fonts, surrendering control of the WOFF metadata to customers undermines this.

Smart foundries will be serialising their WOFF files, matching fonts to customers and to licensed domains. Very smart foundries will be inserting serialisation information and whatever recommendations or other metadata into the font prior to WOFFing. A smart WOFF creation tool for foundries will automatically perform these steps, e.g. using data from a customer database, as part of creating a WOFF file for delivery to or serving on behalf of a customer: insert license specific data into name table and add any custom tables to font; digitally sign font; create WOFF file.

Might have been answered already, but are there any audio/video/transcripts of the presentation from Typecon?

It would be quite nice if a select couple talks were made available on the TypeCon website after the event to serve for posterity, further education and discourse, and as a reminder of what you miss when you don't attend TypeCon.

My EULA allows for conversions/embedding/linking with WOFF, @font-face, EOT, EOT Lite, Cufon, sIFR, FLIR. I didn't attend TypeCon. Please explain how forbidding WOFF conversion is better for my customers. If it makes customers confused about other EULAs, I'm definitely going to do it!

WOFF is not a font format, it is a font delivery format. The SFNT font data content of a WOFF file is 100% identical to the un-WOFF'd font: there is no conversion of that data taking place, only compression and wrapping.

This is what makes WOFF a different animal, and generally friendly toward flexible licensing. We've just updated the SIL Open Font License FAQ to clarify many things, including in which circumstances WOFFing a font is allowed without triggering a required name change.

I do, however, agree that it's best for everyone if foundries would provide WOFF versions of their fonts, and be clear about their licensing. So although our fonts are licensed with the OFL, and could be WOFFed by users, we're still scrambling to create canonical WOFF versions.

Bimp.

Well, it’s time to move on to a third bunch of typotech ninnies, but I wanted to briefly summarize:

First we blasted through the hogshead of flaming BS surrounding ClearType and the ClearType collection, eventually getting an admission that CT is not the revolution in screen reading users were looking for. It’s just patented to look that way. :o

Then about ten days ago, though none here or at TypeCon commented, The W3C published an admission that WOFF brings absolutely no benefits to end users, web developers or font developers that are not already benefits of the "raw" fonts WOFF wraps. See, "What are the benefits of using WOFF?":o

And now — on to the next stop in the Berlow, type technology comedy tour.

Two Berlows go into a bar, the first one says to the bartender, "I don't know what to have, beer or a martini." The second brother says, "I'll have a bottle of Ibis in a plain brown wrapper." The first brother repeats, "I just can't decide!" Then Brett Favre, who has been waiting an eternity for the bartender, walks over to the pair and says, "Would you two stop woffling!"

ChrisL

FAQ's tend to develop over time, and I'm sure with your input the working group can update the answer to that question to include advantages over raw fonts such as the metadata, compression and most importantly foundry support for the standard.

>And now — on to the next stop in the Berlow, type technology comedy tour.

Well you could skip the tour and review your own FAQ... http://www.webtype.com/info/help/ which doesn't currently include a question on the "benefit" of your service, compared to say the other ten web font services out there. ;-)

The W3C published an admission that WOFF brings absolutely no benefits ... that are not already benefits of the "raw" fonts WOFF wraps.

I agree that this section is strange, because it seems to be highlighting general benefits of web fonts, not WOFF specifically. However, the real benefit (expected, but not yet realized today) is implied earlier in the article:

"Until now, downloadable fonts have not been common on the Web due to the lack of an interoperable font format."

The primary benefit of WOFF is (will be) browser interoperability. Secondary benefits -- harder for developers and end users to grasp because they are more abstract -- are font protection and the increased number of choices that that security is expected to bring.

Agree the question is comparing real fonts to images and Flash. But TTF is more interoperable than WOFF (and likely will be for quite a while). Also "security" implies WOFF is secure, which it isn't.

But TTF is more interoperable than WOFF (and likely will be for quite a while).

Huh? When WOFF is supported by all new browsers (does anyone not expect this soon?), will it be less interoperable than raw fonts, which won't be supported in any version of IE?

Sii>...which doesn't currently include a question on the "benefit" of your service, compared to say the other ten web font services out there. ;-)

I think the benefit or our service is obvious, which also has nothing to do with WOFF. I also think the WG has all the help it needs with frequently asked questions, and there are, as far as I remain concerned, no benefits to be found from WOFF that are not benefits of what she wraps. Metadata belongs in the format, not the wrapper, compression by subsetting is the only good compression and it is format independent, and most importantly foundry support for WOFF is meaningless compared to OS and app support of TT/OpenType.

Sii> But TTF is more interoperable than WOFF (and likely will be for quite a while).

Yes I saw that was going to be the case a year ago and IE9 confirmed it for us all, (theoretically).

The only benefit I see for WOFF over plain TTF/OTF is the compression, it might not matter much for small fonts, though.

Re. compression: as Tal reported during TypeCon, based on a testing of a few hundred fonts the average compression in WOFF = 47%.

To declare that subsetting 'is the only good compression' is begging the question and ignoring the fact that any subsetted font can be subsequently compressed with WOFF. Subsetting has various problems for font vendors, web authors and even website visitors unless one means by subsetting just splitting a larger font into discreet character sets and licensing them separately. Interactive web content makes it hard to anticipate what characters are actually going to need to be displayed.

Re. the FAQ: I don't know who wrote that. It isn't something that the working group produced collaboratively, and I suspect it will be subject to review now that we're aware of its deficiencies. Thanks, David.

KH> The only benefit I see for WOFF over plain TTF/OTF is the compression...

The benefit you note is just perfect for the end of the list I linked to above.

JH> ...that subsetting 'is the only good compression' is begging the question and ignoring the fact that any subsetted font can be subsequently compressed with WOFF.

Compressed with WOFF? WOFF is not an application. The compression is for WOFF. As such, subset or not, the compressed WOFF-bound TTF is smaller than a compressed and wrapped WOFF of the same font 100% of the time. So, an un-WOFF bound compressed TTF has the slightly better benefit over a WOFF, in compression terms.

JH> Interactive web content makes it hard to anticipate what characters are actually going to need to be displayed.

Interactive web content is hardly capable of making things hard. I think you mean something or someone else is screwing up subsetting. Subsetting is how to compress fonts.

JH> I don't know who wrote that.

Me neither, but maybe Lilley's non-existent rubber stamp approved it?

Subsetting is tricky for fonts needing complex layout, say Arabic. I'm pretty sure any subsetting to my current Arabic font will either break it or not provide any significant reduction in size. I don't also see how subsetting will work for any website wit dynamic content, unless you are subsetting on the fly for each page separately on each HTTP request.

>...any subsetting to my current Arabic font will either break it or not provide any significant reduction in size.

Well! if it won't reduce your fonts, no one in the whole wide world should be able to subset any fonts I guess.

Well! if it won't reduce your fonts, no one in the whole wide world should be able to subset any fonts I guess.

No, I mean subsetting is not "how to compress fonts", it is merely a hack to reduce font size that has many shortcomings, two of which are already mentioned.

>subsetting is...merely a hack to reduce font size

Well then let us not worry about it. All web sites should be treated as dynamic, and all fonts as un-subsettable.

If I have a web site thhat is only written in English, then I sure would want subsetting to eliminate the thousands of glyphs I would not be using on that site.

Well then let us not worry about it. All web sites should be treated as dynamic, and all fonts as un-subsettable.

Well then let us not worry about it. All web sites should be treated as static, and all fonts as subsettable.

David: As such, subset or not, the compressed WOFF-bound TTF is smaller than a compressed and wrapped WOFF of the same font 100% of the time. So, an un-WOFF bound compressed TTF has the slightly better benefit over a WOFF, in compression terms.

Uh yeah. But WOFF defines a standard compression model for web served font data, in such a way that a user agent knows what to do with it when it downloads a woff file, unlike, say, you picking some random compression mechanism from the myriad available ones and using it to compress a font.

The single biggest benefit to WOFF is this: it is a web standard, which means that it comes with clearly defined conformance requirements, a test suite for implementations, etc. Unlike, say, the ad hoc naked font support that is, in fact, different on each browser that claims to support it.

If I have a web site that is only written in English, then I sure would want subsetting to eliminate the thousands of glyphs I would not be using on that site.
Until you'll want to cite some word in Greek, for example ;-)

@ DB >>First we blasted through the hogshead of flaming BS surrounding ClearType and the ClearType collection, eventually getting an admission that CT is not the revolution in screen reading users were looking for. It’s just patented to look that way. :o

was always curious as to what -you- would have proposed as ideal rendering?

J> The single biggest benefit to WOFF is this: it is a web standard, which means that it comes with clearly defined conformance requirements, a test suite for implementations, etc.

I want to make sure you’ve got this straight then: the benefit of the WOFF standard is, by defining and implementing compression and wrapper definitions as standards, everyone who embraces that standard can be in lock step; compressing, wrapping, decompressing and unwrapping that standard consistently. (The web is great at solving unskilled problems by itself, but let’s leave that thought for a second. )

J> [WOFF is unlike] the ad hoc naked font support that is, in fact, different on each browser that claims to support it.

This is the left ventricle of the heart of the problem John, the right ventricle being the tool maker(s) pretty clearly insisting that font designers/developers work through Type1 font technology to reach TT for the web. Meanwhile here in the left ventricle of the problem, we are seemingly compelled to do without clearly defined conformance requirements or a test suite for implementations of the format users USE. Thus, if the ad hoc “naked font” support you speak of is unaffected by WOFF, which by specification cannot effect the output appearance of the fonts in any way, WOFF pretty clearly brings is no benefit to users, web developers, or foundries.

Now — I don’t give a hoot for solving unskilled problems first, in order to solve skilled problems later, if that’s the scheme — In typography, this method causes wide area bad-legacy issues, as should be clear? But I have been patient.

So, if someone can explain the benefit to the W3C, OS and browsermakers of this unskilled operation (naked font in to- WOFF -to naked font out), please, step forward. Is there anyone who will speak frankly? If you please of course. This is just a Forum, and so you are not compelled to speak.

I am advocating conformance requirements and a test suite for implementations for TT/OT/OFF compliant fonts, (i.e. so we all can work skillfully on what’s going to be unskillfully compressed and wrapped in your WOFF) & (saving the web from a WOFF standard containing an internet monster). And, I am advocating additional requirements and test suites for implementations for extensions to TT/OT/OFF compliant fonts, to account for the massive and relatively sudden changes to the technology of the “press” on the web.

R> Until you'll want to cite some word in Greek, for example ;-)

Do you advocate font servers and or users being responsible for creating each and every skilled subsetting of a font family themselves?

Or do you advocate no subsetting whatsoever?

Do you advocate...

I don't advocate anything! ;-)
I was just pointing out the impredictability of future needs and the problems that could subsequently arise.
Given this, sure, some sort of server-side smart subsetting would be very useful!

"Until you'll want to cite some word in Greek, for example"

yes, Ricardo, but then only that entry--as you say though, "The greeks had a word for it." ;-)

David, you're right that WOFF specifically and the W3C web fonts working group in general can't affect what a font looks like in terms of rendering. I think the working group is well positioned, however, to influence the decisions that browsers make about what to do with font data, through its mandate to define a web font conformance specification. This is unlikely to affect what fonts look line in terms of rendering, i.e. rasterisation, but it may well affect what they end up looking like when browser makers attempt to ‘sanitize’ fonts. Google Chrome, for instance, currently strips GSUB and GPOS tables from web fonts, because it perceives them as a security risk. That might not be affecting your fonts yet because of lack of support for CSS3 typographic features, but it affects how complex script fonts look, and for some of us is a major concern.

I am advocating conformance requirements and a test suite for implementations for TT/OT/OFF compliant fonts, (i.e. so we all can work skillfully on what’s going to be unskillfully compressed and wrapped in your WOFF) & (saving the web from a WOFF standard containing an internet monster). And, I am advocating additional requirements and test suites for implementations for extensions to TT/OT/OFF compliant fonts, to account for the massive and relatively sudden changes to the technology of the “press” on the web.

Laudable. And who is going to define these conformance requirements? And who is going to agree to recognise them?

I think it is worthwhile to point out problems and keep them on peoples' radar until such time as those people -- browser makers, operating system makers, rendering engine makers, font format specifiers -- might start to behave as if they want to fix the problems. Until they start behaving that way, talk of conformance requirements seems to me more likely to drive them away.

WOFF is happening because a lot of different parties with different agendas decided to try to solve a particular set of problems. They didn't set out to solve all the problems of fonts on the web, and they wouldn't have got very far if they had. Some of the problems that WOFF aims to solve could also have been solved within a naked font serving model, yes, but others could not, which is why a delivery format distinction was put on the table by both font developers and browser makers. I've got it that you disagree, David, but if we'd stuck where you are a year ago we'd still be arguing the toss about exposure of existing fonts that most of your colleagues find unacceptable. They may all be wrong and you may be right, but your being right wouldn't move anything forward.

I've tried to ensure all along that, as you requested, WOFF wouldn't get in the way of the things that you want to do with web fonts, and it doesn't. It's a compressed delivery format for font data with some packaging labels stuck to it. What you put in that font data is up to you.

David: Metadata belongs in the format, not the wrapper.

If you're talking about metadata about the typeface and its use, I entirely agree, which is why the WOFF metadata does not include what I think of as typographic metadata, e.g. your ‘recommendations’. It makes much more sense for that to be included in the font data.

A WOFF file is a package, and the metadata is just some labels on that package and about that package. They are not the instruction manual that tells you how to operate the piece of machinery that the package contains.

My main concern is WOFF as a verb. I'm very wary of this development.

The TTFs got WOFFed. I WOFFed the fonts already. Hey, moron, WOFF the thing, willya!
While I was WOFFing...

This is so embarrassing. I thought I was asking a simple question. When I saw the WOFF benefits list I pointed out above, knowing I have to support this format publicly, as well as deal with the sticky issues Simon raised to start this thread, (and having read Crossland's notes on the CSS briefing), I said to myself: “I too want to know how WOFF is addressing a real problem, and not just blazing ahead with a wrapper.”;)

Mike B. Duggan>... was always curious as to what -you- would have proposed as ideal rendering?

There is no idealizable "web reader", so ideal rendering requires flexibility on readability issues, skilled design work and super care from there to the reader's eyes. That's all I've ever proposed.

>>Mike B. Duggan
what does the B stand for? I can only imagine :_0

DB: Is full browser interoperability not a satisfactory solution? Because the security it so weak (I say it's something -- just not much), interoperability has always been the best reason I've had to support it.

>>Mike B. Duggan
>>>what does the B stand for? I can only imagine :_0

No sorry. A murder of crows was making salsa out of my tomatoes, so I was shopping at "Birds B Gone" for netting, two tiny wires crossed, and the rest is history.

ok thanks David F Berlow :) ditto but was trying to get rid of fireflies.

CS> interoperability has always been the best reason I've had to support it.

Well, you better get a real reason then. ttf is the most interoperable font format on this particular planet. What I was beggin' for, was a person from the OS, Browsers or W3C to stand up like a man or woman and tell us what the use of a wrapper is. They didn't, so now, with the WG relegated to a "what just happened" roll, this putrid ball of opaque W3Cness is in my court.

Not to worry, I've got a big racket.

The wrapper distinguishes, at the file delivery stage, a font licensed for use on the web from all the existing fonts out there not licensed for use on the web, and does so with the option of labels that make it possible for font vendors and their customers to see where a font came from and where it is licensed to be used. The wrapper also comes with conformance requirements that stipulate same origin restriction, hence protecting the customer's investment in the web font license and bandwidth by preventing hot linking.

The first of these benefits would presumably be possible with new metadata in the sfnt font data, although trying to standardise something in the OT/OFF specs looked like taking a lot longer and wouldn't engage the browser makers in the way that a W3C process has. The second of these benefits would not be possible with .ttf because there would be no web standard definition within which to define a same origin restriction.

The support of unwrapped font linking on the web is targeted, as Håkon intended when he implemented it in Opera and as MS confirmed when explicitly linking it to installable fonts, at free and open source fonts.

Well, you better get a real reason then. ttf is the most interoperable font format on this particular planet. What I was beggin' for, was a person from the OS, Browsers or W3C to stand up like a man or woman and tell us what the use of a wrapper is. They didn't, so now, with the WG relegated to a "what just happened" roll, this putrid ball of opaque W3Cness is in my court.

I'm afraid this makes no sense to me.

Wow John, slow down from hudsonic speed, and maybe you'll talk truth! The wrapper distinguishes, at the file deliverable stage, a font converted for use on the web from an existing font not converted for deliverability on the web in some probably distant future, and does so with the option of labels (only on the server) that make it impossible for vendors to see where a font came from and where it is licensed to be used. If a user wants to, they can look at the deliverable format (that would be on the server), but by the time the user has had it unwrapped, delivered and enumerated to their operating system by the browser, it is a ttf, with none of the wrapper. WOFF has nothing to do with determining the licensability of font, and it never will.

There is absolutely no doubt about what I just wrote is true, with the italic words hopefully enlightening you, as no amount of inexperience can do.

Your point about Howcome's intentions are utterly meaningless, considering the same Howcome is vending Prince, with what its use of WOFF as an embeddable pdf format implies.

Wow Chris! Don't stay afraid or this will never make sense to you.

but by the time the user has had it unwrapped, delivered and enumerated to their operating system by the browser, it is a ttf, with none of the wrapper.

AFAIK, non of the current WOFF implementations install the font into user's system, it unwraps it in memory and passes it directly to the underlying libraries. It is not that I'm fond of wrappers or garden fences, but I fail to see what harm they do, as long as non-wrapped fonts are still supported. (Why I need to convert Gentium to some wrapper format if I'm legally allowed to use it as is?)

David, everything makes sense to me except the stuff you're saying!

You keep saying TrueType is the most interoperable format. Interoperable where? All we care about when it comes to fonts on the web is browser interoperability. Right now (a) there is no format that is fully interoperable; (b) there is no expectation that TTF will be fully interoperable; (c) there is an expectation that WOFF will become fully interoperable.

... by the time the user has had it unwrapped, delivered and enumerated to their operating system by the browser, it is a ttf, with none of the wrapper. WOFF has nothing to do with determining the licensability of font, and it never will.

A lot of people want to see the browsers expose WOFF metadata to the users. It will never be required, but we're hoping that browsers will see a user benefit to doing so and add it as a feature. So, the idea is that a font vendor adds licensing information to WOFF metadata and the browser shows it to the end user. It is not certain that the WOFF-specific info (e.g. the metadata) will just disappear.

Having said that, does a user (a viewer) care about the font license? The real value of WOFF metadata is that it is part of the WOFF file. If someone grabs the WOFF off a server or finds it sitting around on someone else's computer, they can (in theory) look to see how it has been licensed, if it's okay to use, whatever. I'm not getting your assertion that WOFF has nothing to do with determining a license. You could argue that WOFF might not end up being as useful as we hope, but that's quite different from the factual certainty you're expressing.

David, the WOFF is delivered to the user agent (browser), which is responsible for unwrapping it, so the metadata label is not only 'on the server': it travels with the WOFF file to the user's browser, and while there is no obligation for the browser to display that metadata or do anything else with it, but as Chris notes, there are plenty of people who want to be able to display that metadata, including those users who simply wonder 'What's that cool font?'

Also, as previously noted numerous times, there is nothing in the WOFF delivery mechanism that prevents you from including other metadata in the sfnt font data, nor from standardising such metadata if you can muster enough agreement and support for how to do so. And there would still be no obligation for any browser or OS do do anything with that metadata, because they've made it perfectly clear that they will not accept such an obligation.

...Howcome is vending Prince, with what its use of WOFF as an embeddable pdf format implies.

It doesn't imply anything at all about WOFF as an embeddable PDF format, because by the time Prince is creating a PDF the font is unwrapped and what matters at that stage is the ol' embedding bits, just like any other PDF creation.

Of course, if you are going to set all your web font embedding bits to 'Installable' so that you can serve unwrapped TTF to IE9 beta, you've lost any possibility of serving a font to a website that cannot be embedded in a PDF by Prince or by any print-to-PDF function.

KH>...non[e] of the current WOFF implementations install the font into user's system, it unwraps it in memory and passes it directly to the underlying libraries.

Know farther then. The WOFF is downloaded, loaded into memory for unwrapping, and if you want to call passing the ttf to the "underlying libraries", go right on ahead. It is enumerated to the user's OS as a ttf, the delivery format, for rendering by the system font software, the only software on the user's computer capable of sizing, scaling, and rendering the web type that shows up on screen.

JH> ...

I'm not talking about meta data... here. We had a wonderful discussion of that with the eula sig at ATypI. This is about the rubber-stamped document, referred to above, that's driving us apart. My point there is, it seems easier to bugger foundries when they've been "brought together", and its especially easy when the "invited experts" are really only invited.

I see no foundry, user or web developer reason for the wrapper, and no one else has brought forth any reason here, other than to serve the legal interests of the non-founders involved. If the non-founders can't explain their needs, preferring to call them our needs, well, that's an important non-answer. So I guess the "quality" and "accuracy' of that document stands as the answer, and the togetherness is over.

I see no foundry, user or web developer reason for the wrapper...

Interoperability. Metadata. Same-origin checking.

The point about WOFF not being installed is that its not made available to anything outside the web page that's calling it. It doesn't appear in a fonts menu elsewhere. It can't be used by web pages on other sites.

Know farther then. The WOFF is downloaded, loaded into memory for unwrapping, and if you want to call passing the ttf to the "underlying libraries", go right on ahead. It is enumerated to the user's OS as a ttf, the delivery format, for rendering by the system font software, the only software on the user's computer capable of sizing, scaling, and rendering the web type that shows up on screen.

I fail to see which part of the "rendering by the system font software" requires enumerating the font in the menus, FreeType, for example, can happily render a font already loaded in the memory (you pass to it a pointer to the loaded font buffer), and I Windows native libraries seem to have such support. Indeed, I've been using WOFF (and unwrapped TTF) for a while now and I don't see any of those fonts anywhere in my font menu, so you'd better stick to your own advice and "Know farther".

KH>
I use the word enumerate, instead of install, to indicate that the font does not show up in menus, and that is not part of the issue I am discussing. So interop., metadata and s.o. restrictions, none of these are inherently woff specific,

So interop., metadata and s.o. restrictions, none of these are inherently woff specific

WOFF has better interoperability potential than other font formats, including unwrapped TTF, because it is being defined through the W3C process by the people who will interoperably implement it in browsers. This means not only that there is a will to make it broadly interoperable, but that there is a formal description of what interoperability mean in terms of conformance requirements and testing. Sure, unwrapped TTF might have been defined as a W3C recommendation with such conformance requirements and testing, but it wasn't, because there was no will to make it broadly interoperable, just as there was no will to make EOT or SVG fonts broadly interoperable or, back in the day, TrueDoc.

WOFF has standard metadata. Sure, one could put whatever metadata one likes in the sfnt font data -- and one still can within a WOFF wrapper --, but after a decade or more of hearing font makers talk about font metadata, and seeing some putting private data tables into fonts, I don't see us being any closer to a standardised metadata structure or even agreement over what should go into such metadata. WOFF sidesteps the issue -- leaving it open for future development -- by putting some standard metadata as labels at the delivery wrapper level.

Single origin restrictions as a conformance requirement are indeed WOFF specific. There is no other web font format in which SOR is an explicit requirement, because there is no other formally defined web font format. Sure, a foundry might put a requirement in its web font license agreement that a web developer must prevent hot linking of the web font to multiple sites, but that is unenforceable without browser-side application of same origin restriction, and there is no SOR conformance requirement for unwrapped TTFs.

JH> This means not only that there is a will to make it broadly interoperable, but that there is a formal description of what interoperability mean in terms of conformance requirements and testing.

John, this conformance is all related to WOFF, the wrapper. Conform into the wrapper, conform out of the wrapper. Who cares?

JH> WOFF sidesteps the issue [of metdata]--

That's just one way of putting it.

JH> unwrapped TTF might have been defined as a W3C recommendation with such conformance requirements and testing, but it wasn't, because there was no will to make it broadly interoperable

It'd be like having laws that only apply when we're dressed, but if we're naked, well, then we are above the law. That works! No One wants to talk about having laws for when they're naked anyway, so forget it. Thing is, like some professionals, when the fonts are naked's when they do all their work.

JH> There is no other web font format in which SOR is an explicit requirement, because there is no other formally defined web font format.

Exactly.

David, it isn't when the fonts are doing their work that is a concern, in web fonts any more than in e.g. embedded PDF or simply in use on a licensed user's system, it is how the fonts are delivered to the place where they will do their work and what protocols exist for ensuring that they go to that place and not to another. To borrow your metaphor, it is about letting the ladies walk the streets naked vs. putting them in a taxi with written instructions for the driver on the destination and standard protocols for the doorman when the ladies get there.

The WOFF wrapper provides a convenient way to compress and identify a web font as a web font and to indicate without needing to touch the font data inside where it comes from and where it belongs. Yes, it isn't the only way it could have been done, but it is the only way on which there was any kind of consensus from the different parties that are necessarily involved. So it is what is happening, is being implemented by all the browser makers, and seems to be widely supported by pretty much everyone except you.

JH: ...is being implemented by all the browser makers, and seems to be widely supported by pretty much everyone except you.

Silence is not equal to support. Type designers are busy designing typefaces and producing fonts; that's what they do for a living.

The reality is, few type designers are able to even follow the discussions in the W3C list, let alone actively participate and defend positions against programmers, who have a totally different point-of-view and entry point to the subject (and who are actually paid to develop and implement standards as part of their jobs).

I for one trust David Berlow's experience and support his criticism, and wish more of his points had been taken into account by the W3C working group.

The few points I have tried to raise – rendering issues and PPEM-specific sizes and standard display of meta information – have been disregarded as unimportant or secondary. The agenda is clearly dictated by browser and tool makers, so why bother?

Finally, the fact that IE9 adds support to raw font linking completely undermines the WOFF effort, in my opinion.

gferreira>Type designers are busy designing typefaces and producing fonts; that's what they do for a living.
Everybody sells for a living, pal, don't kid yourself.

Producing fonts for who, to be displayed where?

I don't think there is any creative community that has been treated by the W3C with as much consideration as type producers. (I don't think there's a precedent, if so, I'd like to know.)

If things didn't work out totally the way you wanted, well them's the breaks.
Yes, browser makers are calling the shots. Live with it and move on.
Don't like WOFF? Ignore it and see where that gets you.

The "actual problems" WOFF solves are legal and psychological ones, not technical.

John, my support of woff is unwavering and complete. We'll get on to the other issues anon. Do you support document on the page I'm pointing at?

I support the idea of WOFF and the effort; I support and highly respect Erik, Tal and all the others involved; but as a type designer who is following the whole webfont story closely for years, and actually designing screen fonts, I still fail to see the benefits of the format. It used to be standard support in all new browsers, but as it turns out TTFs will be just fine for IE9. It could have been standard access and display of meta-information, but this part now is considered to be optional. Meanwhile, the fundamental issues for people designing typefaces for screens — rendering, scaling — remain unadressed.

(To be continued. Or maybe not.)

PS: I don't want to sound pessimistic; the glass is half full. But I wonder how many of the type designers/foundries who rushed to put their names in I-support-WOFF lists actually understand the issues surrounding the design of typefaces for screens, and are actually following the work being done by the W3C. (If they do understand, and are following: why are they silent?)

Finally, the fact that IE9 adds support to raw font linking completely undermines the WOFF effort, in my opinion.

Only if the raw font is set "installable", which is not going to include most commercial fonts. IMO it's not really raw font support -- but I guess that's debatable, depending on where you stand. I would think that the average type designer trying to actually make a living with it is not going to set their fonts installable, and would therefore not benefit from this IE9 feature.

CS >Only if the raw font is set "installable", which is not going to include most commercial fonts.

Most what? Installable is the setting of Many Commercial Type1 fonts — Or at least any that grant the licensee the right to send an editable pdf to the end of the editorial line, which is quite often at the printer.

Chris, do you support document on the page I'm pointing at?

Installable is the setting of Many Commercial Type1 fonts — Or at least any that grant the licensee the right to send an editable pdf to the end of the editorial line, which is quite often at the printer.

Okay. It's not the setting of Adobe fonts and I don't think it's the setting of Monotype fonts. Aren't you describing "editable embedding"? How are Font Bureau fonts set?

do you support document on the page I'm pointing at?

I see you've asked John the same question. What do you mean by that?

> Installable is the setting of Many Commercial Type1 fonts

Off-topic but have to correct this. Type 1 fonts don’t have embedding bits. TrueType fonts (with an OS2 table) and OpenType fonts do. I've not come across commercial TTF or OTF fonts intentionally set to installable. That's not to say they don't exist, but by any definition there are not “Many” of them out there.

Most TTF and OTF fonts are set to “Print & Preview”. Exceptions being Adobe and Microsoft fonts that are often set to “Editable”.

Yes of course, I was a word off and got an immediate minor correction.The facts remain that we have a class of users who use and want fonts that are a simple conversion away from being link able to ie9, and the document I'm referring to, which is more than a few words off, being whole concepts off, is unlikely to need ever minor corrections, being suitable as it is as " WOFF for Dummies, (who want to stay that way)"

Do you support this document Si?

I support all documents.

David, are you referring to the W3C 'FAQ' document? I've already indicated that I think this document has problems, fails to distinguish WOFF-specific benefits from general @font-face benefits, and needs to be improved. Do I support it? I don't think it is a document that asks for or requires support. It's an FAQ, so it should be helpful to understanding, and where it isn't it should be fixed. It's not a position paper, manifesto or technical recommendation.

>I support all documents.

I'm sure you do, as long as they have no effect on your livelihood.

>It's not a position paper, manifesto...

Are there such things for woff? I'd like to see that.

>...or technical recommendation.

Not many people will read that.

This FAQ is the only read for most users and many developers.

It's a surprising contrast when one reads the excruciating details of the WOFF specification, and its discussion single words, like "must" vs "should".

gf>"I don't want to sound pessimistic; the glass is half full... Meanwhile, the fundamental issues for people designing typefaces for screens — rendering, scaling — remain unadressed."

Yup. I was gabbing with one type designer at ATYPI who was quite shocked that it didn't become obvious to me sooner that, despite the WOFF hype and the notion that type design begins now, today, with DirectWrite rendering, in reality Microsoft is leaving everybody twisting slowly in the wind.
(Sigh.)

They are still selling XP for netbooks aren't they? Do they not feel any responsibility for transitioning from one environment to the next?
Guess not.

Anyway, my understanding is that as a wrapper, WOFF works quite well - the fonts stay nice and fresh - and without refrigeration!

This FAQ is the only read for most users and many developers.

I doubt it. At the moment, kinda, and that is why -- as I have said -- it needs to be revised and I'll be recommending this as an action item during tomorrow morning's working group conference call. But as the WOFF technical spec gets finalised, I there will be plenty of documentation available for web authors and developers, including sample code, validation tests, and other things that are par for the course for web standards. And not all of this will come from the W3C, there will be plenty of third party tutorials, new chapters in web design books, advice direct from foundries, etc..

JH> I doubt it.

The "is" in the context I used it, is the only read from the WG's truly stellar efforts. I agree that it's a good idea to move forward to other documents, but if we are to love all things W3C we should love its founding documents on text and fonts the most. I think this document falsely portrays a scenario where readers will think they can go forward with print quality type and typography on the web with html and css, because of WOFF.

So, our first tutorial, I'm afraid is "Simmer down, we've got it handled for you. The browsers and OS had to be "Legally Blindfolded" before we could go on."

One issue, unfortunately, is that web developers and users are not blindfolded, are they? And yet another issue is that great publications are going all-graphics on the iPad, and people love it, don't they? But the biggest issue may be that the W3C thinks they've taken this GIANT step, and are too exhausted to go on? Or maybe that browser makers think they are not going to have to become commonly good enough to display iPad-like pages with the kind of fidelity you see from that tiny media platform/cocktail tray?

I don't know John, I'd watch 'em like a hawk, if actions speak louder than words how loud's a W3C document on the web? They should have at least asked your group, and so I wonder how long this revision will take. ;)

David, while I agree that the FAQ can be improved, I think you are making quite the mountain out of this molehill, and nowhere does that document suggest to me that 'a scenario where readers will think they can go forward with print quality type and typography on the web with html and css, because of WOFF'. The document makes the mistake of equating web font = WOFF (an error, but understandable in that WOFF is the only web font format that is being formally defined as a web standard by the W3C). The words 'print quality' and 'typography' do not even appear in the document.

I understand and agree with your gripes about rendering quality, but that's not a web standards issue. Its a text rendering issue that relates to individual operating systems and only secondarily to browsers. Its not within scope of the web fonts working group charter. If you want to try to get all the operating system and browser makers to come together and define and accept a standard for text rendering on the web with conformance requirements and testing, then you could probably get the W3C to define a 'web type rendering' standard. I think it is unlikely, given that fonts and rendering have been treated as an area of competition and differentiation ever since Apple first announced TTF; I don't think you will be able to persuade all the OS makers to suddenly change to treating rendering as an area of cooperation and standardisation.

John> I think you are making quite the mountain out of this molehill,

One molehill at a time.

John> If you want to try to get all the operating system and browser makers to come together and define and accept a standard for text rendering on the web...

Ohhhh, too late... they already crapped that up , but good.

David: they already crapped that up , but good.

Your link is to the SVG spec. One of the outcomes of the WOFF standardisation -- along with Mozilla and Microsoft's refusal to inplemenet SVG web fonts -- is that the SVG working group is thinking of giving up on SVG fonts as any kind of compliance requirement, in effect acknowledging that SVG is dead-in-the-water as a web font format.

But the biggest issue may be that the W3C thinks they've taken this GIANT step, and are too exhausted to go on?

Working groups are established with specific charters. So it isn't a case of the W3C being 'too exhausted to go on' with web fonts beyond defining the WOFF wrapper format and web font compliance and testing requirements, but that the current charter of the web fonts working group is limited to those items. I presume there is a mechanism for extending the charter of a working group, once it has met its initial goals, but that would involve defining new goals and getting agreement from the members to pursue those and from the W3C to consider formalising the results. What are you suggesting such goals might be? Specifically?

John> Your link is to the SVG spec

Yes it is...

Did you read the documentation of the text-rendering property?

That's what is most interesting, for the format may go away though I doubt it, but can its properties?

And if user agents wanted to, which they did, they can apply this property to any font format, which some do today.

So, svg is the format MS won't support next, is it? ;)

For specific new working group goals, I would list getting the w3c folk to participate again, disbanding the WG and awaiting a group of web and Internet savvy founders and typographers to develop, that can afford to watch all the chimps slamming away at their keyboards and pull out the Shakespeare as it appears.

David, if I thought the OS and browser makers would sit patiently by while the savvy font makers and typographers waited for the combined chimpage of the Internet to produce the ideal solution, I'd be with you on this. But they were not sitting patiently by: they were proceeding to make decisions and implement solutions with which a lot of us were uncomfortable, which were based on fantasies about the number and quality of free fonts, and which sailed under the slogan 'Fuсk the Foundries'. That's where we were a little over a year ago.

The best solutions for web text will ultimately be determined by font makers and typographers, despite all the barriers that other people have thrown up between the us and the goal. WOFF is not one of those barriers.

Yes John, the best solutions will be developed by font makers. And I did not say woff is a barrier, just the documentation. And if the fantasy font crowd thought the reader would be served by free fonts, what will they think of next? Hmmmmm?

JH>"The best solutions for web text will ultimately be determined by font makers and typographers, despite all the barriers that other people have thrown up between the us and the goal."

DB>Yes John, the best solutions will be developed by font makers.

I assume "font makers" means the industry as it has existed up till now.

Some blogger posted this:
You might not be aware, but there is a generation of font designers who have been waiting for this moment for fifteen years.

No way to know for sure yet, it has to play out, but I suspect he's correct.

>there is a generation of font designers who have been waiting for this moment for fifteen years.

I think that "generation" could be defined as the designers responsible for the fonts hosted at dafont.com. Not from a quality perspective, but more as the amateurs and part-timers who think it’s pretty cool to have their creations actually used in the real world.

There's a separate class of professional type designers who have been waiting for this moment too, but with more a sense of apprehension and concern.

Cheers, Si

Sounds like Si is ready for the lyrics:

"But february made me shiver
With every paper I’d deliver.
Bad news on the doorstep;
I couldn’t take one more step.

I can’t remember if I cried
When I read about his widowed bride,
But something touched me deep inside
The day the music died."

Close, more like this one...

Web monkeys try to put us d-down (Talkin' 'bout font generation)
‘Cos we license fonts around (Talkin' 'bout font generation)
Things they say sound awful c-c-cold (Talkin' 'bout font generation)
I hope I die before my fonts get stole’d (Talkin' 'bout font generation)
This is font generation
This is font generation, baby
Why don't you all f-fade away (Talkin' 'bout font generation)
And don't try to dig what we all s-s-say (Talkin' 'bout font generation)
I'm not trying to cause a WOFF s-s-sensation (Talkin' 'bout font generation)
I'm just talkin' 'bout font g-g-g-generation (Talkin' 'bout font generation)

That is still better than "Born Free" :-)

Rich: I assume "font makers" means the industry as it has existed up till now.

No. It means people who make fonts.

John>...fonts and rendering have been treated as an area of competition and differentiation ever since Apple first announced TTF.

I want to point out that this gross generality is false. The web could not have founded without the near-identical input and output of TrueType fonts on the commercial OSs from 1994 to 1999.

As for the "competition" over anti-aliasing, I don't see much. Apple leaped off the specification entirely with the return of Jobs, and MS leaps off the spec. at its very end, when the end user's resolution is x16ed.

>near-identical input and output of TrueType fonts on the commercial OSs from 1994 to 1999.

I would put the start date at 1991, with release of OS7 and Win3.1

Cheers, Si

David: I want to point out that this gross generality is false. The web could not have founded without the near-identical input and output of TrueType fonts on the commercial OSs from 1994 to 1999.

Sorry, David, but the fact that one font and rendering technology was better suited to the web than its competitor and was, for a relatively brief period, near uniformly rendered on two operating systems, does not make the general observation false. TrueType only existed at that critical time because Apple didn't want to pay Adobe's PS licensing fees any longer so produced its own, competing format. They didn't call it the Font Wars because it wasn't competitive. The relationship of TrueType and the web in the 1990s was symbiotic: yes, the web benefited from the better screen legibility of hinted TT, but the TTF format benefited from having a niche in which it was clearly better than the competition; this at a time when many print service bureaux were still refusing to handle TT fonts because of the bad reputation they had gained due to early problems with RIPs. Meanwhile, the competition, i.e. Adobe, was busy rolling its own screen rendering in competition with that available from the OS to other applications. The arrangement of the competitors changes, such that two companies like Apple and MS might temporarily align their efforts on promoting TTF—just as Microsoft and Adobe later temporarily aligned their efforts on OpenType*—, but there was never a time since the introduction of TTF when fonts and rendering were not areas of competition.
___

* And when that temporary arrangement came to an end, MS and Adobe did something smart: they got OT into the MPEG standard, so that there would be a formal process by which the format could develop that was not reliant on good will between two competing companies. Which leads me back to the point I made above: if you think some kind of standardisation of rendering is possible at this stage, then you need to get the various players to sign up to a standardisation process, with all that entails in terms of patent releases, conformance commitments, etc. Simply hoping that they will agree—and agree for long enough not for the whole thing to unravel on the next release—is not enough.

Many good points. But I'm not talking about the needs, or history of the desktop. I think some kind of standardization of rendering is important, on the web, at this stage.

I don't need to get various players to sign up. The magazine/app industry on the iPad is pretty solid proof that having a standardization of rendering allows faithful design and good readability in the same general ppm size range as the desktop-hosted web.

People say "-its all a slide show!" and other various things, but iPad mag apps are sort of a "F-iOS-ck the Standards, People Love It!" statement in itself. That's our competition, not the OS and their old dance.

This is according even to Bill Hill's Blog, where he wants us to go out and find the most mammoth html/css gurus we can, and teach them to do the mark-up that'll get web magazines to the quality and consistency of iPad magazines.

Well, Hill and I want the same dang thing! But he doesn't understand, that without some rendering conformance, them gurus have to go through graded variations of fonts to get iPad-quality mags that work in the marked up web world.

And if you appreciate the distance we've forumed, from quality of this woff documentation, to a web where gurus stand by ready to make web safe magazine publishing via font variations — good woff information is taking too much time for the legal blindfolding it accomplishes.;)

For those who need a link or else

During his talk at RIT, WIRED's Chris Anderson made it a point to mention - about three times - that Condé Nast had it's best year last year.
Now, there could be many reasons for this besides the popularity of magazines but it seemed to me like Anderson was trying to convince - not the audience - but himself that everything is hunky dory. He almost seemed amazed by the continued success.
If you read his books - and there is nothing I would recommend more strongly - you realize he's too smart and too savvy an economist not to realize that THE END is more often than not preceded by boom times. Magazines have not transferred well to the web and there are dark clouds on the horizon.
When I talked with him afterwards, I asked him if the 80,000 or so downloads of WIRED's premier iPad app - which he also made a point of mentioning - could just be people in the publishing industry wanting to have a look and hoping against hope that WIRED will, indeed, pave a way to salvation - as CN is hoping it might. He said, "It could be."

(Ain't gonna succeed, if you ask me. And if Chris Anderson was a free-lance economist instead of the editor of WIRED, betcha he'd say the same thing.)

Yesterday, Ray Kurzweil's Blio book software debuted. Yet another debacle based on the idea that what we need is book simulation software for the screen.
We do not need magazine simulation software, either. And the sooner everybody gets that idea in their heads, the better. IMHO, of course.
Whatever form a "magazine" takes on the web, it won't look like a printed magazine. And if it's available only within a walled garden like the iPad, all that will do is limit readership. And then the question becomes, "Will the number of people willing to pay make the effort worthwhile?"
So far, I doubt it. But that's conjecture. Don't know if WIRED's talkin'.

David, here's an update on the W3C FAQ. Chris Lilley just got back from two weeks of business trips followed by two weeks of vacation. During today's working group conference call he confirmed that the existing FAQ was something he put together quickly following the WOFF press release that came out during TypeCon, so that journalists would have something to which to refer if unable to contact him during his travels (which further explains the nature of the questions and answers, reflecting the sort of exchanges Chris was having with journalists). We opened an action item today for the FAQ to be revised, and Chris, Vlad and I will be working on this, and then having the working group review and provide feedback before a new version is posted on the W3C site.

As I envisage it, the FAQ will relate to both WOFF specifically and web served typography more generally, within the context of W3C specifications (CSS2, CSS3, use of @font-face, and WOFF), but will better distinguish the particular benefits of WOFF and the general benefits of web fonts. Sound all right?

R.Fink>...it's available only within a walled garden like the iPad

The thing that I don't get is why more people don't defend embedding the design and fonts in the document as graphics, or whatever, as opposed to the mess of the web's delivery and display. Besides the obvious tools and skills re-use in the authoring of iPad magazines for the internet, the IP issues for the software and text is solved, and the user's device stays cooler, fighting global warming and battery use. I nearly burned my hand that first week browsing Webtype on my phone.

Besides, if not having to deal with Windows or the W3C means success of e-publishing for your organization, and if e-reading clearly benefits, then let that be a lesson to yous.

J.Hudson> Sound all right?

In the short term, whatever you say. I look forward optimistically to the next drafts! In the long term it sounds like a thin thread at the W3C for what I view from a bird's eye as extraordinary circumstances. 95% of the content of the web's up for what appears to be unfathomably complex treatment by a combination of user agents and user agent hosts, just to start. As I've said before, the W3C has opened the biggest school of typographic education in history, and we should love them for their documents.

As I've said before, the W3C has opened the biggest school of typographic education in history, and we should love them for their documents.

Yes, I agree.

The thing that I don't get is why more people don't defend embedding the design and fonts in the document as graphics, or whatever, as opposed to the mess of the web's delivery and display.

I was thinking about exactly this last night - because I'm addicted to "Project Runway" (having spent so many years in the Fashion Biz), and I really, really can't see the average woman clamoring for selectable HTML text when all they want to do is browse the ads in an electronically simulated version of Marie Claire or Vogue or whatever.
These mags don't get read, they get looked at.
I think that deriding these apps as mere "slideshows" sells them short. Timely and mightily expensive slideshows, that's for sure.
What's wrong with an attractive slideshow? It lends itself to certain kinds of content - I agree.

>clamoring for selectable HTML

I'll let the "average" women respond to what they clamor for, but indexing and searching are relatively important scenarios even in static content like PDFs.

Will commercial font licenses that allow for user conversion of desktop fonts into WOFF fonts add to web font licensing confusion?

Is this customer confusion problem a real thing or just something meant to scare those of us who allow format conversions to get in line?

Are customers confused by movies? Movies free in jets but late. Movies are expensive in a theater but cheap to rent. You can buy the movie but it looks no better than the rented version. Sometimes movies are on TV for free and you can tape them. You can pay to download a movie. You can get a friend to rent it and watch it at their place. The prices for these vary from store to store.

"I wish I wasn't allowed to tape this movie that's showing on TV because it makes me kind of . . . you know . . . confused or something. Must kill everyone." (actual movie customer quote)

Open source fonts allow format conversion and have no pageview limit. You can buy a multi format web fonts kit complete with style sheet, improved hinting and proper customer service. You can rent (sort of) hosted web fonts - easy to install and reliable. Sometimes a license agreement will allow you to convert your own web fonts from a desktop font. Sometimes you pay a flat rate. Sometimes you're limited to a certain number of hits. Prices vary. A reliable vendor may cost more but to some people it's worth it. Some people need to pinch pennies or just like doing things themselves . . . or dislike restrictions on things they buy.

Is offering less choice a service for customers or for vendors?

The thing that I don't get is why more people don't defend embedding the design and fonts in the document as graphics, or whatever, as opposed to the mess of the web's delivery and display.

Because graphics don’t scale well and they can lead to nasty bandwidth bills for big sites. Remember how much bandwidth popular sites like ESPN saved when they switched to CSS instead of loads of inline formatting? Just think about what they’ll save when a font smaller than a decent graphic gets downloaded one time and all the graphics are generated client-side. And it’s not just a big deal for content providers; the ATT/iPhone debacle has shown that bandwidth consumption may become very important on oversold wireless data networks.

Me > Will commercial font licenses that allow for user conversion of desktop fonts into WOFF fonts add to web font licensing confusion?

Ray > Is this customer confusion problem a real thing

The question was actually prompted by an audience question at TypeCon. For my customers web font licensing confusion is real. I get questions all the time. Are you finding the opposite? Do your customers get it?

Ray > meant to scare those of us who allow format conversions to get in line?

Adobe allows conversion, but they don't allow redistribution of the converted fonts. WOFF conversion implies redistribution. Not trying to scare anyone, just interested in what can be done to help educate people around the issue.

J.Hudson> Yes, I agree.

Well, I think you need to think some pretty basic things different then. E.G. from the W3C list: “Moving forward, as browsers implement CSS3 font feature support, demo web pages with sample CSS code seems the obvious way to proceed, and I don't think foundries will need to be told this.”

Agreed, and done on the hand of today, but on the other hand this is the web... not medieval Europe. Your obvious and ancient way, (foundry, as most knowing composer, educating/composing for the client), is fatally incomplete as the only answer for the web of tomorrow being decided today. The right way for the web is for the font to be the most knowing composer, educating the client and software.

Sii> Not trying to scare anyone, just interested in what can be done to help educate people around the issue.

Well, the future of education on permissions lies not in the obvious and ancient way, (foundry, as most knowing permitter, educating/permitting the client, and for the client). This is fatally incomplete as the only answer for the web of tomorrow being decided today. The right way for the web is for the font to be the most knowing permitter, educating the client and software.

For my customers web font licensing confusion is real. I get questions all the time. Are you finding the opposite? Do your customers get it?

Get what? You never say what it is they're supposed to "get".
I've challenged you, I believe, on this before: explain font licensing simply and comprehensively in one paragraph.
Go on, I double dare ya.

Moving on... since the following snappy retort was to my posting on the W3C list:

Moving forward, as browsers implement CSS3 font feature support, demo web pages with sample CSS code seems the obvious way to proceed, and I don't think foundries will need to be told this.

I think different. I think it's the obvious that must be stated. It's the obvious that's most inclined to be overlooked.
In Medieval Europe or today.

@sii
"WOFF conversion implies redistribution."

How in hell do you figure that? Is using a font on a web page redistribution?
Please explain.

>Is using a font on a web page redistribution?

Yes

Ray >> Is this customer confusion problem a real thing

Sii > The question was actually prompted by an audience question at TypeCon. For my customers web font licensing confusion is real. I get questions all the time. Are you finding the opposite? Do your customers get it?

I think my customers get it now. I haven't had many questions about embedding since I simplified my EULA and added a page on my site about embedding. Maybe the diagram alleviates some non-English-speakers' confusion too. You're not limited to using text to explain what customers are allowed to do. Nowadays you can post a sock puppet show on YouTube explaining the embedding situation if you want to. Diagrams, comics . . . whatever gets the point across more clearly. Shoehorning that information into a heavy EULA is the ideal way to ensure that it's less understood.

It seems the only method I have to measure customer confusion is the number of questions I get. I think having the embedding explanation out in the open rather than buried in the EULA is just common sense. A year ago, the most common embedding question was "can I convert this font myself using Font Squirrel?" I've had many positive comments about my decision to allow all types of web embedding with the standard license.

>Is using a font on a web page redistribution?

Yes

Of course it is - the font is distributed to each visitor to the website.

Dave: Of course it is - the font is distributed to each visitor to the website.

While I agree that using a font on a web page constitutes a kind of distribution, it isn't what I would consider the primary meaning of ‘redistribution’ in terms of a EULA, which would be intentional selling or giving away copies of a font for use by other parties. A font on a website is displayed to each visitor to the site, and only as a by-product is it sent to that local machine in some format and possibly cached. It is convenient that existing font licenses that prohibit redistribution also prohibit web serving on the grounds that this technically involves distributing the font, but moving forward I don't think it is in anyone's interest to continue to lump web font serving with redistribution, any more than it has been to lump PDF embedding with redistribution. These are specialised uses of fonts, which should be clearly and independently covered by appropriate license terms. As new technologies make new things possible, updated license agreements should explicitly clarify whether these things are permitted or not.

Spoke sii:

RF>>Is using a font on a web page redistribution?
sii>Yes

My answer is: see John Hudson's answer.

BTW - to underscore the incredible legal complexity involved in licensing issues - it seems Canonical, the sponsors of the Ubuntu font, can't even find a way to license the fracking thing in a suitable way. (To anybody who's done any serious reading about licensing and copyright this is no surprise.)
They are looking to sponsor legal research. Their travails chronicled here.

Meanwhile, in the news, the Russian government uses bogus "Intellectual Property" issues - specifically Windows licenses - to shut down political dissidents while Microsoft stands mute. (This, too, was no surprise. It was inevitable.)
I guess open source - among its other advantages - can now help keep you out of jail! The Brazilian government has the right idea, perhaps.

You mute on that, too, sii? Yes?
(Just playin' widya, mister monosyllable.)

Later,
rich

> Meanwhile, in the news, the Russian government uses bogus "Intellectual Property" issues - specifically Windows licenses - to shut down political dissidents while Microsoft stands mute. (This, too, was no surprise. It was inevitable.)

http://www.nytimes.com/2010/09/14/world/europe/14raid.html?_r=2&hp

>You mute on that, too, sii? Yes?

The Geico caveman said it best… "next time do a little research"

I agree with Dave, if the font is posted to a server by a licensee then that equals redistribution plain and simple, as does posting a PDF that includes it embedded in the traditional way.

>the sponsors of the Ubuntu font, can't even find a way to license the fracking thing in a suitable way.

Perhaps they secretly want to keep it to themselves.

Perhaps they secretly want to keep it to themselves.

The Geico caveman said it best… "next time do a little research"

True :-)

@kevlar

Thanks for the link. Unfortunately, MSFT can't eat the IP cake and rein it in, too. The distress may be genuinely felt by MSFT employees, but it's Window dressing, really.
You reap what you sow in the Halls of Congress.

@sii

Like I said, I was just playin' widya.

From the Times article cited:
"The company was responding to criticism that it had supported tactics to clamp down on dissent."
"Microsoft would make sure that it was no longer offering legal support to politically motivated piracy inquiries by providing a blanket software license to advocacy groups and media outlets. They would be automatically covered by it, without having to apply."
Huh? And how, pray tell, do you define and identify "advocacy groups" and "media outlets"?
Look, there is really nothing MSFT can do about this that isn't limp. It's a consequence of other policies, that's all.

More enlightening is MSFT lawyer Brad Smith's statement.
Brad Smith is not mute.

Next time, do a little work and take a representative quote from the article. That's what fair use is all about. ;)

rich

Rich, there are very few laws that are not open to abuse by repressive states.

Rich, there are very few laws that are not open to abuse by repressive states.

And even when there isn’t a law to abuse it does nothing to stop the Russian government. That government is more than happy to just send a goon out of shoot someone in the head, feed people radioactive toxins, etc.. By focusing on the Microsoft angle you’re just letting the Russian government distract you from what matters.

Is there a law against burning 2/3 of the appendices in the woff spec?
If not... Is there a CSS property that will set text on fire when the browser is finished displaying it?
If not, is there anyone else who thinks subletting an unwrapped sfnt does not result in an "original" work?

I don't think it is in anyone's interest to continue to lump web font serving with redistribution

;)

Dave, when you start making smileys in response to something I've said, I immediately wonder how I might have been misunderstood. :)

To be completely clear: I am not saying that web font serving is not redistribution, I am saying that the fact that the question is raised and needs to be answered is a good indication that everyone will benefit from future EULAs making explicit statements regarding web serving of fonts, rather than presuming that it is understood that prohibition of redistribution also covers web serving (and conversely, that permission to serve on the web does not imply permission to redistribute).

Permissions should be specific, explicit and unambiguous. This is impossible in fonts today, isn't it. ;)

It should be possible today. Unfortunately licenses were written yesterday (five computers connected to one output device!?) and need to address the issues of tomorrow.

lol, Sii, but it seems the font format of tomorrow is just a wrapper containing the font format of yesterday badly in need of becoming the format of tomorrow in what will, by then, be yesterday's wrapper.

It is horrifying to read about the scope waffle,(October), and I hope Crossland recovers from the procedural tank that ran over him, but right now, it's bad taste to think about licensing issues for just a wrapper, IMHO, when casualties are coming in.