WOFF the Font!?

Si_Daniels's picture

Here's a question, prompted by the TypeCon web fonts "monster" panel (expertly moderated by Bryan Mason).

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

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

Thanks, Si

k.l.'s picture

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. :)

hrant's picture

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

Richard Fink's picture

>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.

Si_Daniels's picture

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.

Ivo's picture

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?

Si_Daniels's picture

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.

dberlow's picture

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!

John Hudson's picture

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.

Chris Dean's picture

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

Corey Holms's picture

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.

Ray Larabie's picture

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!

gaultney's picture

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.

dberlow's picture

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.

dezcom's picture

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

Si_Daniels's picture

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. ;-)

Christopher Slye's picture

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.

Si_Daniels's picture

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.

Christopher Slye's picture

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?

dberlow's picture

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).

Khaled Hosny's picture

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

John Hudson's picture

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.

dberlow's picture

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?

Khaled Hosny's picture

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.

dberlow's picture

>...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.

Khaled Hosny's picture

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.

dberlow's picture

>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.

dezcom's picture

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.

Khaled Hosny's picture

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.

John Hudson's picture

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.

riccard0's picture

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 ;-)

mike_duggan's picture

@ 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?

dberlow's picture

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?

riccard0's picture

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!

dezcom's picture

"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." ;-)

John Hudson's picture

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.

John Hudson's picture

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.

Richard Fink's picture

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...

dberlow's picture

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_duggan's picture

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

Christopher Slye's picture

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.

dberlow's picture

>>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.

mike_duggan's picture

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

dberlow's picture

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.

John Hudson's picture

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.

Christopher Slye's picture

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.

dberlow's picture

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.

Khaled Hosny's picture

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?)

Christopher Slye's picture

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.

Syndicate content Syndicate content