I think the bold italic has been waiting for this day.
Congratulations.

So far my hope to have WOFFs accepted by the end of the year is coming true! Compressed, protected font files... good for the web and for typeface designers!

Brilliant. This is all very exciting! Big congrats to Jonathan Kew, Erik van Blokland, Tal Lemming and everyone else for their work to get the format prepared.

And yes, the bold caps are definitely appropriate.

Huzzah!

@colinmford - I guess you could argue they are safe from casual theft, but WOFF files aren't exactly protected. Fontforge and woff2sfnt can both convert a WOFF back to a "normal" font. Just sayin.

@johnhudson

Thanks for the news flash. This raises many questions in my mind about IE9, but I guess I'll have answers soon enough.

@colinmford and all:
Compressed, protected font files
Compressed, yes. Protected, no. Yes, it's a good thing to have a standardized, compressed wrapper for sfnt fonts. But don't look to them for protection, they won't give you any. If anything, the quick adoption of WOFF presents a dilemma. You got what you asked for, now what? Where's the product? What's the price?

Outside of a few simple things that can be done to make fonts less usable to someone who's downloaded a font from a web site using @font-face - there is and always has been only two options: 1) avoid the web like the plague 2) take your chances like everybody else who sells resources for web sites.
If the browser can "see" it, I can take it, shake it, bake it, and, if I so choose - install it. WOFF, EOT, TTF, OTF - all the same. Easy.
But this does not necessarily mean you have lost a sale or that you won't make money from your efforts. And new, unimagined opportunities might emerge.
IMHO the type design community is in a far better position than most others to profit from the web.
And then again, maybe I'm wrong and your income will plummet. There are worse things in the world than having to change careers. You can move to New Orleans and help them rebuild. Or Detroit, maybe.
Two last things:
WOFF is certainly an ego stroke to the font design community so by all means take a victory lap and enjoy it. Being accomodated should feel good. And an unexpected show of support from the mother ship (MSFT) an added bonus.
Contrary to what you might think, there is a tremendous amount of good will towards font designers in the web design community. There really is. And in the long term, without common consent, you are screwed. It's a fragile thing, but my hope is that it remains intact.

>This raises many questions in my mind about IE9

The IE team are woking on a blog post.

@sii

Thanks.
If it can be passed along...

1) IE9 preview works with EOT’s in IE9 standards mode so can I safely assume that EOT will be supported in IE9 standards mode?
2) Will EOT be “tweaked” to support OTF CFF files?
3) Will linking to "raw" TTF or OTF fonts be supported with with the caveat that the embedding bits are zero?
4) Will WOFF be supported in IE9? And, if so, will the embedding bits in the decompressed/reassembled font be enforced in any way?

Them the questions.

Rich

Thanks, I'll pass these questions along. Now to fix my "r" key.

Cheers, Si

Rich, with regard to embedding bits and WOFF, I think it would be precipitous for any browser maker to make a statement about this at this stage, because that is certain to be a question the working group looks at. As discussed on Typophile earlier, between Microsoft's original EOT spec, which linked embedding bits to web font linking permissions, and the present circumstances, those bits developed a much broader use in terms of PDF embedding, and as such don't represent any EULA I am aware of with regard to web font linking. The situation is such that for both CWT (EOT-Lite) and WOFF some of us have considered expressly disassociating web font linking from embedding permissions.

See also:
http://lists.w3.org/Archives/Public/www-font/2009OctDec/0027.html
http://lists.w3.org/Archives/Public/www-font/2009OctDec/0032.html

Removing ambiguity about the relevance of embedding bits to web font linking seems to me desirable for everyone involved, and the cleanest way to do that is to say that they are not relevant, at least for WOFF. They would, of course, become relevant again the moment someone took a WOFF font and embedded it in something. :)

Regarding protection, it's certainly the case that WOFF does not provide any technical measures to protect font IP, i.e. no DRM-like features. What WOFF does for font developers is to draw a line between existing TTF/OTF fonts not licensed for use in web served typography and a new, compressed format that is licensed for use in web served typography. I see this as a kind of protection against casual or unconscious misuse of TTF/OTF fonts, which is what we were seeking in our objections to naked font linking. At the same time, a new format gives us the opportunity to build delivery systems that incorporate font copy serialisation, embedded EULA abstracts, permissions and recommendations, and other metadata. There's no obligation in the format on browsers to do anything with such metadata in terms of policing licensing, but it makes it easier for font developers and their clients to manage license use and protect their investment.

.

Will EOT be “tweaked” to support OTF CFF files?

EOT doesn't really need to be tweaked to support CFF. In fact, CFF-in-EOT works in IE8 (but not earlier versions of IE). The problem is getting that EOT built -- Microsoft's WEFT doesn't work with anything but TTF, so that's what needs the tweaking.

>Removing ambiguity about the relevance of embedding bits to web font linking seems to me desirable for everyone involved...

Anything that helps disambiguate embedding bits from web font linking is welcome, but not at any price. But instilling certainty just by format is uncertainty veiled.

>What WOFF does for font developers is to draw a line between existing TTF/OTF fonts not licensed for use in web served typography and a new, compressed format that is licensed for use in web served typography.

It draws quite a different 'line' for font envelopers in a new "Web Font Management Business", as you see.

Cheers!

.

David: Anything that helps disambiguate embedding bits from web font linking is welcome, but not at any price.

I agree, on the general principle that nothing should be done ‘at any price’, but I'd like to know what you would consider acceptable/unacceptable means of disambiguating embedding bits from web font linking.

As I see it, formally disambiguating them in the text of the WOFF standard makes sense, and this rightly puts the focus for permissions on the WOFF metadata and on whatever other license data the font maker puts in the font, e.g. in an epar table.

Would it also be nice to see this disambiquated in the OT/OFF spec and in the EOT spec? Yes, I think so, but that would be a different battle on a different battlefield. The new W3C working group has a specific remit, and I'm interested in figuring out what might be done and what should be done within that context. So the question for today is what, if anything, the WOFF standard should have to say about embedding bits?

Personally I think the embedding permissions should be treated like the other metadata in the WOFF. Purely informational, optionally presented via a font information panel.

"The presence (or absence) and content of the metadata block MUST NOT affect font loading or rendering behavior of user agents; it is intended to be purely informative. However, if user agents provide a means for users to view information about fonts (such as a "Font Information" panel) then they SHOULD treat the metadata block as the primary source, falling back on the font's name table entries when relevant extended metadata elements are not present."

Si, the question is not whether the embedding bits should be treated informationally (if relevant at all, then that is surely how they will be treated), but what information those bits present -- if any -- relating to font linking. The issue for font makers is that, thanks to Acrobat, most fonts made over the past decade have embedding permissions set to permit embedding (most often print/preview, sometimes editable, only occasionally installable), but that these settings do not relate in any way to licensing for web font linking. Hence, it becomes important to clarify the relationship of the embedding bits to font linking to avoid confusion over their meaning.

In EOT, the embedding bits were explicitly associated with web font linking, in terms of embedding fonts within an EOT, both in the spec and as implemented in the WEFT tool. That is one approach to clarification, but obviously one that some font makers find problematic for the reasons stated: a font might have the embedding bits set appropriately for Acrobat embedding, but should not be embedded in an EOT. Simply stated, the embedding bits provide insufficient information, and so are ambiguous in their meaning related to different embedding/linking technologies. Hence the need for other metadata, but rather than having multiple permissions information in different locations, with the attendant risk of conflicting or ambiguous information, it seems to me a good idea to remove this particular set of permissions (that do not directly and solely relate to web font linking) from the equation for web fonts.

Sorry, I was commenting on WOFF (subject of this thread) not EOT, PDF or other forms of embedding that conform to the OpenType Spec's definition of document embedding.

In those cases my personal opinion (which hasn’t changed in the past ten years) is that the embedding permissions should be considered alongside any additional restrictions in the written EULA. I do not think the OT spec’s wording should be changed.

Si: ...conform to the OpenType Spec's definition of document embedding.

Does the OpenType spec have a definition of document embedding? I've looked and failed to find anything that looks to me like such a definition. The closest thing is the statement ‘Embeddable fonts may be stored in a document’, but this is very vague and not what I would consider a definition. There is no statement of what constitutes 'storing in' or of what constitutes a document for this purpose.

Let's ask the question as plainly as possible: Does linking to a served font in a CSS file constitute embedding of a font in a document?

It is because I expect positive and negative responses to this question from different people that I think the issue needs to be clarified.

>Does linking to a served font in a CSS file constitute embedding of a font in a document?

IMHO No. Unless a mechanism like URL binding is in place.

Also I know there are gray areas... definition of "document" and definition of "in", but EULAs and licensing FAQs can and do address these questions, as well as deal with issues of distribution (eg. workflow PDFs vs public PDFs). But plain linking (with no access control) certainly falls outside the OT spec definition.

Thanks, Si. This is the kind of clarification I'm hoping to move toward, preferably with consensus.

>So the question for today is what, if anything, the WOFF standard should have to say about embedding bits?

I know it’s tomorrow, but the WOFF wrapper should have to say everything the OT font says about embedding, and more, as in EPAR. There are documents with embedding, there are applications with embedding, and devices and OS embedding font, fonts fonts. There are all kinds of linkings desired, and though WOFF is not the place to define new ones, (I mean our OT fonts need to have all the informative metadata our WOFF fonts have), first, or how would anyone know our OT are not licensed for web linking of any kind?, go right ahead.;)

Sii on Scope>"The presence (or absence) and content of the metadata block MUST NOT affect font loading or rendering behavior of user agents; it is intended to be purely informative."

What kind of publishing system is it... doesn't allow people the freedom to publish to whom they want? But that’s my problem, we’ll leave w3c out of it until it’s clearer.

Also I think the scope of this WG is primarily to slay formats, so let’s close this epic for Ash?

Cheers!

.

Thanks, David.

"It appears that we have decided to implement WOFF in Chromium"

...and then there was one.

via http://news.cnet.com/8301-30685_3-20003277-264.html

Also IE Blog - http://blogs.msdn.com/ie/archive/2010/04/23/meet-woff-the-standard-web-f...

Sorry Richard, this doesn't cover the questions you raised. It's more of an announcement.

@christopher slye

>EOT doesn't really need to be tweaked to support CFF.

Thanks. So I was informed some days ago. But I was told it was platform specific, not browser specific.
Will seek clarifications. This sounds like a new job for the cheetah.

@db
>I know it’s tomorrow, but the WOFF wrapper should have to say everything
>the OT font says about embedding.
The wrapper or the font contained within?
Sequence:
Pack up the font with WOFF, font has, within it, the embedding bits. Send WOFF to browser. Browser unpacks WOFF, looks at font, sees bits, does what it does whatever that may be.
Firefox does nothing one way or the other.
Are you expecting something different?

>The wrapper or the font contained within?

Assuming a correct font format UAs do and will do nothing based on either the WOFF wrapper or the wrapped content. That's why I'm confused at this WG's discussion of what this next accepted format is supposed to do/contain other than what the OT format can contain. I thought WOFF was designed and accepted, and now the WG are supposed to slay the rest of the litter. If not, I think little will have been gained.

>Sequence:

>Pack up the font in a WOFF, font has, within it, the embedding bits.
The current OT font format is converted to WOFF. Within it, there is no explicit and standard information about font linking. Embedding information, as hacked into the standard, is not relevant to web use.

>Send WOFF to browser.
The browser calls and the server sends and existing WOFF or creates one on the fly.
This WOFF is downloaded to the CPU of the user

>Browser unpacks WOFF,
Browser uses the CPU of the user to convert the WOFF to OT and 'enumerate' it to the OS.

>looks at font, sees bits, does what it does whatever that may be.
Not as far as I know. There are no seeing-bit browsers, only format-seeing ones.

Cheers!

David: I thought WOFF was designed and accepted, and now the WG are supposed to slay the rest of the litter.

Slaying the rest of the litter is what happened before the working groups was established.

If you're confused about what the working group is doing, read the charter. It includes delivery of a conformance specification for dead cats.

Embedding information, as hacked into the standard, is not relevant to web use.

This is exactly what the WG is seeking to formally clarify, since David Berlow and John Hudson saying it repeatedly does not a standard make. There seems general agreement about two things:

1. All but fsType bit 1 (restricted license embedding) are not relevant to WOFF and this should be clearly stated;

2. User agents, e.g. browsers, will ignore all fsType embedding bits including bit 1.

What isn't agreed yet is whether that bit 1 — regarding which the OT spec says

Fonts that have only this bit set must not be modified, embedded or exchanged in any manner without first obtaining permission of the legal owner.

— should be interpreted as meaning that WOFF creation tools must not convert such fonts to WOFF format.

I suspect the outcome will be that this bit too will be deemed irrelevant to WOFF, but the language of the OT spec -- ‘modified, embedded or exchanged in any manner’ -- is such that its worth looking at carefully.
___

Another possibility is that a new fsType table version could be defined in the OT spec with a specific 'Don't convert to WOFF' bit added. I like this idea, because it has no impact on existing fonts, but would provide a means to restrict new desktop fonts from being converted to WOFF by end users, if that were a font maker's desire.

>Slaying the rest of the litter is what happened before the working groups was established.

Intellifont? TrueDoc? Gone but not unremembered?

And if EOT is dead, John Hudson repeatedly saying 'twas fatally flawed in its handling of embedding bits, does a standard help. This format had "overwhelming" support from The Foundries, and it was my pleasure to lend my voice to yours.

>Another possibility is that a new fsType table version could be defined in the OT spec >with a specific 'Don't convert to WOFF' bit added.

A new fsType. Wow. Is that really in the scope? Can it have a "do not convert to SVG" too? How about "don't convert from WOFF"? ...from SVG?

...then there's the intermediate problem of OT being used by some browsers: Assuming that all browsers use only WOFF by 2012, we still all have to express our rights in OT for all exchanges in any manner, including those that are not expressed, being forbidden — because OT is being used by browsers and format converters, and will be used by WOFF converters. Or do people think the WOFF conversion tools are the right place to add permissions? Do You think the WOFF conversion tools are the right place to add permissions? Do The Foundries think the WOFF conversion tools are the right place to add permissions? Were the EOT conversion tools are the right place to add permissions?

Somewhere along this line, it's going to occur to enough of The Foundries that 500,000-per-style 1992 s made Verdana. Maybe this group should add "OFF for Web" to its title, add another scope, and binoculate this super-extraordinary situation to resolution. Or should we all just wait for more resolution?;)

Cheers!

>A new fsType. Wow. Is that really in the scope?

I don't think so, given the history in this area. But OpenType is an open standard, so you could give it a try.

>Assuming that all browsers use only WOFF by 2012

I think browser makers have declared that they will not deprecate raw font support. Microsoft is not planning to deprecate EOT.

>and will be used by WOFF converters.

I have a feeling most vendors will provide WOFF fonts alongside other formats or via a service model. They’ll likely prohibit end-user conversion (as most EULAs currently do) and police any misuse. However, now would probably be a good time to talk to the people producing conversion tools if you want to influence the landscape.

Sii>...to talk to the people producing conversion tools if you want to influence the landscape.

Whatever you say! Ohhhh too late. Now we have to wait until October, and intersection with some lunar phase of ISO appearing in Andromeda to get one more bit, no.... wait, Phinney wants TWO Bits! Let’s all mob together ‘nd get an SVG bit or two! I bid FOUR bits, and a bit for one format and then the other — and bit by bit we’ll figure out the landscape is a lot of bits without my help?

Then, if we’re lucky, we’ll see how serious is the intent to define and protect font IP, not by mechanism or garden fence format, but by a table of stated, legally unambiguous permissions. One other interesting way to look at the landscape is to track the desires of parties in the “web font business” with absolutely none-to-little font IP of their own. What landscape do they want? is a pretty cool spectator sport.

Cheers!

>Ohhhh too late.

Yep, you're probably right. You're about two years too late.

Haha. The train has left the station fellas.

Oh nuts!

David: Then, if we’re lucky, we’ll see how serious is the intent to define and protect font IP, not by mechanism or garden fence format, but by a table of stated, legally unambiguous permissions.

That's the thought that crossed my mind as I typed out the suggestion re. WOFF-specific fsType bit. But a table of 'legally unambiguous permissions' is by definition an abstract of the EULA, and is itself dependent on the EULA to give it any legal weight. Since browser makers are already adamant that the EULA constitutes the source of permissions or prohibitions and that they will not be responsible for any policing of these through technical methods, I'm left with my old question: What is such a table supposed to do that the EULA doesn't already do? How does it work?

fsType embedding bits, on the other hand, are a conventionally established technical mechanism for restricting certain kinds of use of fonts. If one is interested in a technical mechanism for preventing use of fonts as WOFF files, they're the obvious place to look first.

Or do people think the WOFF conversion tools are the right place to add permissions?

A very valid question: one that I'd like to see answered. The makers of WEFT apparently thought that an EOT conversion tool was the right place to add permissions. Someone thought they would be interested in a technical mechanism (using existing embedding bits) to prevent a font from being converted to an EOT file, so I'm inquring whether a parallel in WOFF creation would make sense. I'm not wedded to the idea, but I'd like to know whether font makers are interested in a technical mechanism to prevent a font from being converted to a WOFF file?

>Yep, you're probably right. You're about two years too late.

No... I started this more than 2 years ago. What's not too late is that the courts are still gonna be around when this is done.

>The train has left the station fellas.

But do Your tracks end in paradise or a James Cameron finale?

>If one is interested in a technical mechanism for preventing use of fonts as WOFF files[...]

But we are not interested in a technical mechanism for preventing use. That's decided.

>What is such a table supposed to do that the EULA doesn't already do? How does it work?

1. Be readable in a standard sort of way.

2. and writable, in a standard sort of way.

3. be expandable in a standard sort of way.

Go ahead, I dare the entire industry to try and write EULAs. You first John, then we'll see how Adobe and MS fare, if ever. Then you can go through the whole WG and see what they have in mind for EULAs, if any web fonts ever come to their minds.

>...whether font makers are interested in a technical mechanism to prevent a font from being converted to a WOFF file?

Not interested. I am only interested in making plain in our fonts, that if a user or software developer wants to move their exposed little asses across the line from a simple licensing issue, to a much more complex copyright/trademark issue, we will be there with the proper 'paperwork'.

Cheers!

@David - Depends who you ask. A fair number of font designers I'm working with agree that the old Garden Fence Train #9 leads right to paradise.

ED>A fair number of font designers I'm working with...

That's fair, and think broadly of what you support.

ED>...agree that the old Garden Fence Train #9 leads right to paradise.

Your train is still to prove itself when the full load of customers hits the fair number of font designers. Unrecommended, unserved, unpermitted, autohinted libraries with limited linquistic coverage are going to take more than a little love to get their makers to paradise. But what's your definition of paradise?

Try this...http://www.fontspring.com/search?q=text, is a search for "text". 120 families are returned, (a feat unto itself, IMHO). Then poke on the "2" to get to the second page.

I see "Search on '50'"... and two questionable text faces... what do you see?

JH>...browser makers are already adamant that the EULA constitutes the source of permissions or prohibitions and that they will not be responsible

So I'm not sure why you're asking about woff restrictions at all. I think, it would be best to say something like:

Web authors are expected to make adequate efforts to ensure that the font license corresponds to the intended web use. It SHOULD NOT be assumed that embedding permissions in the font’s OS/2 table, fsType field, (generally for PDF document embedding permissions), correspond to permission for use of the font on the web. A font’s fsType, which may be contained in a WOFF file, will not affect load behavior in user agents and will not affect whether tools produce a WOFF file from an OpenType font.

That seems clear to me, and from a journalistic point of view, puts the main point first.

Cheers!

David- Thank you... you just found a bug in my search code. Appreciate the poking.

You are welcome. Now how much do your fonts cost? ;)

Cheers!

@dberlow
> A new fsType. Wow. Is that really in the scope? Can it have a "do not convert to SVG" too? How about "don't convert from WOFF"? ...from SVG?

The charter is explicit that modifications to OFF/OT/TT are not in scope. The WebFonts WG cannot and will not modify those specifications.

As Chris points out, modifications to the OT/OFF spec are not within the scope of the WOFF working group charter. On the other hand, they're within scope of people who make fonts.

CL> The WebFonts WG cannot and will not modify those [OFF/OT/TT] specifications.

Thus if as John says is done, the other formats are slain, what's left for the WG?

After all, if the WOFF has meta data added to it, the WebFonts WG will either be; modifying those specifications by edict, or demanding that WOFF conversion tools do it.

JH>...they're within scope of people who make fonts.

That's not very encouraging. Most people who make fonts for the web are not on the WG.

Sii>You're about two years too late

Lol... You think!

This I wrote in September of 2008 to a W3C member who queried "What Do You Want!?":

I want a well-thought-out plan from where we are to where we need to be, executed in stages of advancement that make sense for the user community. As a repurposed piece of ignored technology made originally to compete with PDF, EOT is not a stage of advancement...

I want LINKING bits in the Open Font Format, before web font linking goes any further. I can't believe people are just trying to repurpose embedding bits, which, from a licensing and end user licensing point of view, is a big deal, I think. [this evolved shortly after Sept 08 into EPAR]

I want to be able to license url-to-site, pointing to fonts by their trademarked or custom names, with web linking permissions specially for the purpose. I want to be able to establish a cascade of licensing possibilities from a link of a single font to a single page on a single computer, to a blanket license for a series of web-proofed families for all-time use in all-web space. [this evolved shortly after Sept 08 into EPAR]

I want the web designer to be able to query the user's device and OS environment as part of CSS, like Media Query, but including the rendering method. This, 'Chase Query' would provide detailed enough information so that letters, coming from fonts, linked by url, could get back to being things (optimized for a user's environment if possible and desired), and not pictures of things, (one digital outline font for all and any user's linking to said 'font'...

I want browsers to concentrate on user agent-ing, (cookies, bookmarks, avatars, font preferences and passwords), and leave network agent-ing, (like font technology filtering) alone, and leave typography up to the user in a consistent way from browser-to-browser. We users, do not need browser wars over font linking/use, I think.

...not all of this is W3C territory, I know.

(End Quote)

I've learned a lot more about the web since then, but not much has changed.

And Simon, I recognized then that deprecation of OT and EOT support was not going to happen soon, which also supports the need for meta data in the OT font format, as OT is a web standard until everyone says otherwise, and must contain WOFF of EOT-containable permission data.

But instead of fixing this before rushing OFF off to ISO for the web, MS clearly showed it wanted otherwise. So now, the W3C is trying to change the OT specification.

I don't think it should be entirely unclear to everyone by now, that there is a problem with not enough change to the input and too much change to the output from 1994 to now.

Cheers!

David, the W3C is *not* trying to change the OT specification. As Chris Lilley and I have both pointed out, changing the OT or OFF specs is outside the scope of the W3C webfonts working group.

My point about it being within the scope of the people who make fonts is that the OT/OFF specs can be changed independently of the W3C webfonts standard. They can be changed to add new embedding bits; they can be changed to add an epar table. Or they can be left just as they are. The standardisation of WOFF provides a new point of reference that needs to be taken into account when considering such changes in future.

What the webfonts working group is doing is formalising the WOFF spec -- a process that involves Erik and Tal and Jonathan K. --, and writing a conformance specification. In other words, making a formal standard out of this file format. Part of the function of the conformance specification is to state how WOFF implementations may, should or must relate to other standards, including OFF. It is within this context that I've argued that clarification needs to be made that the existing fsType embedding bits do not constitute permission to use a font on the web. I've argued this because of you, David: because you made a good case that EOT's repurposing of the embedding bits was a bad idea that muddied the distinction between document embedding and web serving. I agree with you.

I threw out the idea of a new, WOFF creation bit after Vlad suggested that existing embedding bit 1 might relate to WOFF creation, and would hence provide a means for a font maker to signal that a given font should not be converted to WOFF. I only suggested that a new bit would be better because there would be issues with using the existing bit at the intersection of a web served font and document embedding, i.e. when someone prints a web page to a PDF. If there isn't any interest from font makers in having a technical mechanism to prevent creation of a WOFF file from a given font, that's fine. The WOFF conformance clarification can simply state that all the existing fsType embedding bits are irrelevant to WOFF.

How's the epar table spec coming along?

>How's the epar table spec coming along?

It needs more input at least.

Cheers!

From http://www.w3.org/Submission/WOFF/

"Any TrueType/OpenType/Open Font Format file can be losslessly converted to WOFF for Web use (subject to licensing of the font data);..."

Understood.

"...once decoded by a user agent, the WOFF font will display identically to the original desktop font from which it was created."

Not understood. What is trying to be conveyed here?

Cheers!

"...once decoded by a user agent, the WOFF font will display identically to the original desktop font from which it was created."

Not understood. What is trying to be conveyed here?

That converting a font to WOFF format does alter the underlying font data, so the font reconstituted by browsers will render the same way the initial font would.

Argh. Typing at strange hours:

That converting a font to WOFF format does not alter the underlying font data...

So the way it's written should reflect that. There is no single "display" to be associated with a "desktop font", except perhaps arguably where a 1:1 correspondence of pixels-to-units per em is reached. This will rarely if ever be reached in web use, so it's quite misleading to suggest that the two fonts will display identically. In addition, this assumes that unlike EOT and Cufon toolers, WOFF toolers will be constrained from scaling fonts during conversion.

Perhaps..."once decoded by a user agent, the WOFF font will behave identically to the input font from which it was created" might be clearer?

Cheers!

Perhaps..."once decoded by a user agent, the WOFF font will behave identically to the input font from which it was created" might be clearer?

Yes, that's an improvement. I think you could just as adequately say, "... will display identically to the input font from which it was created," since I think the point is that it will look the same.

David: ...so it's quite misleading to suggest that the two fonts will display identically. In addition, this assumes that unlike EOT and Cufon toolers, WOFF toolers will be constrained from scaling fonts during conversion.

A WOFF file is a container for a font, so in terms of WOFF we're talking about identical display between the font that goes into the container and the font that comes out of the container. If a tool is performing some scaling or other conversion on a font before putting that font into the container, then that's independent of the WOFF standard, which only cares about the container and what is in it, not what happened to the contents before they were put into the container.

I agree that using the term 'input font' would be make this clearer and avoid confusion over the possible relationship of a modified input font to some upstream 'original desktop font'.

PS. I'm really enjoying the Tangier headlines.

A fascinating read 8 months later.MS and Apple beat WOFF senseless with their decisions, and I got blamed last week? Beginning next week, we'll all be able to write font stacks with but 2 formats, ttf and eot! The epar is waaaaay more useful than a WOFF. And despite the fact that the fonts WG has no charter to chage OT, never did, the WOFF FAQ is approximately 87% dependent of OT for it's reasons for being, and there's movement afoot to push that to 90%? .

P.S. I'll pass the Tangiers compliment on John, bet you can't wait for Tangiers RE!

Say-Whutt?
What-you talkin' 'bout, David?

>Beginning next week, we'll all be able to write font stacks with but 2 formats, ttf and eot!

Like Chris, I'm not sure what else you're referring to but the above is true. WOFF is just a kind of sanctioned substitute for EOT. It's useful for it's native compression - if you don't have gzip as an option - but nothing else that I'm aware of.
TTF is more universally supported.

I think that David believes that web designers only need to link to TTF (for all recent browsers) and EOT (for the only old ones that matters) so there's no point to WOFF?

Fascinating read, this thread, 8 hours later...

Sii, the "David believes" stuff, has gotten really old.

The truth is out there...

:-)

Wow! Corporate enthusiasm of the fourth kind, part 5,423.

What DB wants to believe next, is that MS does not want CSS font stacks to explode in complexity. Can you even think that far?

David: Beginning next week, we'll all be able to write font stacks with but 2 formats, ttf and eot

And -- IE backwards compatibility aside -- in the not too distant future you will be able to write font stacks with only one format, WOFF, which is the only format on which the TTF and EOT browser camps were able to agree and, hence, the only available basis for interoperability. That WOFF also provides in-format compression, is the preferred licensing format for most of your colleagues, and in no way interferes with EPAR or any other custom font table (indeed, EPAR content could also be included in the WOFF private metadata), is either icing or cake depending on one's priorities. Either way, it's the right thing to do and a tasty way to do it.

This is neither here nor there, but Opera announced that the most recent release supports WOFF. What's confusing me is that on Win7, XP, and on Mac, I cannot get it to work. I've built the WOFF using three different tools. And they all work fine on other user agents.

I'm beginning to suspect it's a hoax - an in-joke, and that they're waiting to see who notices! (This part is pertinent to the discussion.) Because unless you're specifically testing for it, nobody would even notice that the WOFF file is not the file being displayed in the browser. In the font stack, it's almost always alongside a TTF of the same typeface. (In my tests, Opera skips the WOFF and takes the TTF or SVG. And it will not take the WOFF, even if it's the only font in the stack.)

From the point of view of some implementers and authors, WOFF is seen as nothing more than a pain in the butt and an intrusion: things are complicated enough and EOT and TTF cover all the bases.

I don't know what effect this will have over the long haul, but once web authors get used to something - in this case, serving TTF files, it's a very long time before practices change - if ever.

Apple sure hasn't rushed to get on the bandwagon.

> indeed, EPAR content could also be included in the WOFF private metadata), is either icing or cake depending on one's priorities. Either way, it's the right thing to do and a tasty way to do it.

John, it sounds good, but with the spread and permanence of ttf, it was never a great idea to add md anywhere but there. Never was, never will be.

Regarding Opera: WOFF is said to be supported by Presto 2.7 Milestone 81. The current Opera 11.01 is using the older "Presto/2.7.62". (Thanks to Ralf Herrmann.)

@kl

Ahhh, vaporware! Thanks, Cool Hand. Thanks Ralf.
I think the hoax angle would have been more fun, though!

Rich

>...WOFF is seen as nothing more than a pain in the butt and an intrusion...

Good point, but not quite a 'pain'! It's much more like "baby windows made a doo doo in it's pants trying to render text?" don't worry we will fix it. Then, "baby windows made a doo doo in it's pants on a font format?" don't worry, we will have a nice long WG and baby windows will be happy. Then "baby windows made a doo doo in it's pants trying to do companion styles consistently?" we can fix it in the CSS. Soon "baby windows will make a doo doo in it's pants trying to do kernig?" Then "baby windows makes a doo doo in it's pants trying to do small caps?" how hairy should one build web sites just to dam the doo doo, is becoming less interesting with each passing iPad app. but still we try;)

Windows is trying to make doo doo on our gasps now so I have to go find out, no more play with baby windows, it's changing time;)