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?
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!
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.)
Ahhh, vaporware! Thanks, Cool Hand. Thanks Ralf.
I think the hoax angle would have been more fun, though!
>...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;)