David, WOFF is going to be the web font standard in the only sense that anything on the web is standard: formally defined as a standard by the W3C consortium. WOFF is going to be the only web font standard; all other formats are, according to that standard, optional. WOFF is a container for an OT font. Both the OT font and the container may contain metadata. Metadata may be formally defined in terms of standard fields in the WOFF spec or formal additions to the OT spec, or it may be private and extensible (and some of your colleagues worked hard against considerable resistance to make sure that a structure for extensible metadata made it into the WOFF spec). Both the WOFF spec and the CSS3 spec are in process, which means that they are open to revision and subject to change, so dismissing either of these standards as ‘not well enough informed to meet the challenges of real typography on the web’ is premature. They will ultimately be as well informed as we strive to make them, which means engaging in the process. I suppose it's heck of a lot less work to criticise something as inadequate from the start, not engage with other people on improving it, and then say ‘See, I told you so’, but there's a well known analogy about a pot and what you should do or get off it.
Sorry. Part of me would love for the whole web typography bag to be put under your diktat, with everyone from system and browser makers to your fellow font designers simply saying ‘David’s right, and we should just implement whatever he says.’ But that isn't going to happen and if you want to influence what does happen then you either need to be engaged in the standards process or communicate your ideas clearly to someone who is. I volunteer. Seriously, I think you are substantially right about a lot of things, and I try to communicate what I understand you to mean and make sure that it is heard where it matters, but then you keep saying things that make me think I must have misunderstood you last time.
Rich: (Yeah, yeah, they can make a WOFF, an EOT, whatever. That's IF they know what their options are.)
If IE didn't support any raw font linking, the options would be more obvious: WOFF for up-to-date browsers and EOT(-Lite) for backwards compatibility in IE6-8. The idea that a desktop installable font might be legitimately served to the web is the primary source of confusion over web font licensing, and this is why a distinct web font format greatly simplifies the situation for users: WOFF = made for web, TTF/OTF = not made for web.
David: There is no OT format, it’s just a name used by MS and Adobe referring to an ISO spec. That spec. contains the ClearType that’s mangling readability, and does not provide to users the results of hinting ISO sought when they started OFF.
Microsoft deliberately retained control of the OT specification, which is maintained independently of the ISO OFF specification. There is, to my knowledge, no formal agreement between Microsoft and ISO that says these specifications must remain in sync -- i.e. in the formal, legal way that Unicode and ISO 10646 must remain in sync --, only the will of the parties that being in sync is a good idea.
[Adobe? I'm not sure anyone who wasn't party to the original Microsoft/Adobe OT agreement actually knows what Adobe's stake in all this is any more.]
Neither the Microsoft OT spec nor the ISO OFF spec ‘contains ... ClearType’. ClearType is a Microsoft rendering technology (variously implemented in different MS products). It isn't mentioned anywhere in the OT/OFF spec, any more than Adobe's CoolType or Apple's Quartz are mentioned.
You surely know all this, so why are you making these bizarre and nonsensical statements?
JH>But the larger a screen gets the greater the chance of a manufacturing error resulting in a dead pixel.
Oh, you're such a pessimist. Again with the dead pixels!
Due to industry secrecy it's very hard to get info on upcoming advances in display technology.
Maybe sii, considering his vantage point, might be able to shed some light on when we might see some Retina-like displays at larger sizes.
One thing I found, too, with the Retina display, is that not only was I able to rely much less on Zoom to get to a readable text size but also, since I was able to read the type within the overall visual context of the page, it also helped in comprehension and navigation. I didn't feel like the fly that's landed on the portrait painting, like I sometimes do. (Wasn't there a game show that had a segment with that as the basis?)
I've always found having to pan and scan the page within a moving window of magnification to be very disorienting.
Much less of that with the higher res. An added bonus.
With regards to the technical issues you've raised: you're absolutely right, of course. To the practiced eye, fidelity to the letter form IS compromised.
The question is how many people are going to really give much of a hoot about it.
The answer for those bothered by it might simply be the one DB mentioned. If you want that kind of resolution and fidelity: Print it! It's never been easier or cheaper to turn to print.
Everything Rich said about the embedding bits and web designers is spot on and I agree completely. The discourse here seems to be on two separate planes. One appears to be mostly academic thinking and the other is grounded in the reality of designers wanting to use fonts NOW. In the interest of serving designers and getting those brave foundries into new markets, I say do whatever it takes. IE wants embedding bits turned on? Turn em on. Foundries worried about fonts being stolen? Make them uninstallable.
Web developers know nothing about the technical aspects of fonts. Nor should they have to in my opinion. Those who demand technical expertise from end-users is going to lose.
>Why put web developers in a position where they have to choose like this?
..they didn't have this choice for the last 16 years. I see no guns to heads now.
>Why force a situation where many will unknowingly break the fine print in the contract?
Rich, they may or may not be breaking the fine print of the contract. I mean, if they are unknowing, as I readily agree most are, they don't know there is a contract, or if they do know that's possible, whether the fonts they are about to diddle is covered by one.
They are however, going to a tool and modifying a software product, knowingly...agreed?
>What's the point of this? I'm missing it.
One browser developer thought the embedding bit should relate to web font serve-ability.
>the reality of designers wanting to use fonts NOW.
isn't this actually; the reality of designers wanting to use exactly and precisely the style they want to use, NOW? I mean most designers have not much clue about exactly which actual font 'file' to use NOW... do they? Even if they are free?
>Those who demand technical expertise from end-users is going to lose.
And I compleeetly agree with you. Some of them end-users can't even change the battery. And, I'd add that we who expect technical and typographic expertise from web developers are going to win some, loose some. But those who don't expect technical and typographic expertise from web developers are going to find one hungry market with no pay out.
But those who don't expect technical and typographic expertise from web developers are going to find one hungry market with no pay out.
I beg to differ. My four kids are eating better than ever ;-)
I agree with Messrs. Hudson and Berlow re: promiscuous font "diddling," perpetrator unawares or otherwise.
Orthogonal to all this, I would point out that after installing the IE9 preview on my Win7 box, the difference between the Meta Web WOFF demo page in IE9 and Firefox 3.6 is night and day. IE9 is the best rendering I've seen yet. FF3.6 is cross-eyed by comparison.
Compare this in IE9 and FF:http://www.edenspiekermann.com/woff/
DB>They are however, going to a tool and modifying a software product, knowingly...agreed?
Sure. Absolutely. Happily. Creatively. But in a lot of cases they may not know what changes are being made. All they know or care about is that the "software product" they have modified now works, and before the modification it didn't. Broken versus not broken.
And in most cases they have an unquestionable right to do such modifications.
If you or anybody or the "one browser developer" are looking for the embedding bits to provide some kind of lightweight DRM, that will only work if the embedding bits are preserved as is. The Catch-22 is that by breaking the font for IE9 unless it has the bits set to installable this helps ensure that the bits won't be preserved as is. A vicious cycle. Helps nothing. It will inconveniences many, though.
A great way to build a market for fonts.
Shall we move on to Sii's questions?
Not so quickly.
Since you come up with this again and again, some quick notes on licensing fonts, EULAs, and "necessity" to violate EULA and modify fonts:
1) Whenever you license a font, or any other software, an online shop will present you the EULA -- and you cannot proceed with the order process unless you have (actively) clicked a checkbox to express your consent. If you haven't read the EULA, you haven't read it deliberatedly. There is no "Ups, I didn't know." There only is a "Hehe, I didn't want to know."
2) You don't buy a font, or any other software, you pay a fee for the right to use it as specified in the EULA. If you don't like the latter, just don't license this font.
3) Since agreeing to the EULA is part of the licensing process, and since fsType expresses in bits what the EULA expresses in words, it is not an option that the designer/user is surprised about the font unexpectedly not doing some things.
4) If "the font doesn't work interoperably across browsers" as you try to argue for your right to modify fonts (changing fsType), then most likely the font was never meant to be used as a web font in the first place. No "interoperability" issue. Nothing "broken". Obviously you decided to ignore the EULA.
5) In the rather unlikely case that fsType has been set wrongly -- if a font is advertised as web font but fsType settings prevent a browser from showing it -- contact the foundry so they can correct this by themselves, probably library-wide. Foundries do communicate, provide service, etc.
In short, the "problem" which you are trying to construct doesn't exist. No need for a designer/user to modify or convert fonts which, again, is not and will not not be permitted by most EULAs. If you don't like that, avoid such fonts. Moreover, you are trying to reduce it to a mere technical problem (some bits set "wrongly", font being "broken") which it isn't. It is an agreement problem.
It's pretty Janus-faced of you 1) that you refer to "them" (designers/users) as people who just don't know about EULAs kind of as a cheap excuse while 2) that it's actually you, on multiple channels (blog posts, articles, EOTFast manual), who tells "them" that fonts need to be fixed -- and how to do it. It is not "them" who think fonts are "broken", it's you who tells "them" so.
Yeah KL, but Rich is in a different place that goes like this:
Before, they could not reach someone else's berries.
After they can reach the berries.
Fence Broken versus Fence not broken.
Policy vs. Practice
Karsten, re. your point no.3:
fsType expresses in bits what the EULA expresses in words
Part of the issue with fsType embedding bits is that they do not, in fact, express the EULA. Obviously a font maker should try to set the embedding bits so that they are not in conflict with the EULA, but there isn't necessarily a clean relationship between the relatively crude options in the embedding bits and the much more precise legal permissions of the license agreement. And the relationship only gets messier if, as in this case, Microsoft defines a novel software behaviour relative to the embedding bits. It is perfectly possible that a font might be installable from an embedded document, both in terms of fsType setting and EULA terms, and not licensed for web use. Similarly, a font might be licensed for web use and, for IE9 compatibility, have its embedding bit set to installable, but not be licensed to be installed on a recipient's system.
@johnbutlerOrthogonal to all this, I would point out that after installing the IE9 preview on my Win7 box, the difference between the Meta Web WOFF demo page in IE9 and Firefox 3.6 is night and day. IE9 is the best rendering I've seen yet. FF3.6 is cross-eyed by comparison.
You're comparing underlying font rendering API's here. IE8/Chrome/FF3.6 render text via GDI, the developer release of IE9 is using the Win7/Vista-only DirectWrite API which includes better font rasterization. Support for DirectWrite rendering is already supported in nightly builds of Firefox and hopefully will ship enabled by default in the next version of Firefox. XP users (60% worldwide OS share) will see the same font rendering as before.
As for Safari on Windows, it uses GDI rendering by default but switching a pref enables the use of a ported version of Apple's font rasterizer. Although WebKit is open source, the font rasterizer is closed source so it's Safari-only. In general, it does a far better job of rendering unhinted ttf fonts.
KL>If you don't like that, avoid such fonts.
I will or I won't but I'd like to make the decision in full knowledge of all the facts that might impact my work.
Are you actually arguing for secrecy about it? A "don't tell" policy? Or what?
You also seem to think I'm arguing for you to change your license. I'm not. That's your business. Do it smart, do it stupid, do it any way you want.
The topic was IE9 enforcing the embedding bits when linking to an OTF or TTF file.
My take can be summed up by: Be careful what you wish for, because you just might get it.
MSFT will ultimately do what it sees as being in its own best interest, I suppose. I don't know what other motivation they would have. We'll see.
KL>it's actually you, on multiple channels (blog posts, articles, EOTManual), who tells "them" that fonts need to be fixed -- and how to do it.
Yup. I'm one of them outside agitators from up North who wants web designers to know how to get fonts looking as good as possible, whatever the browser, whatever the platform. Thanks for describing me as too informative, I like that a lot.
outside agitators from up North
You should defend your campaign if you feel it's being misunderstood, but likening it to the Civil Rights Movement seems pretty unseemly to me.
I doubt Richard is likening his game to the Civil Rights Movement, Civil War perhaps. And... I'd love to see some "before and after" of Richard making a single font look better, as good as possible, or anything of the sort. I'm not sure you are legally or occupationally qualified to do anything but bit twiddling, are ya?
E-Squirrel> I beg to differ. My four kids are eating better than ever ;-)
I am so happy to hear that, Really! And how long have you been in the web font business? a month 'r two? do you think the early adopters are, as I said, technical and typographic expert, or inexpert web developers, at this early stage?
JH>‘David’s right, and we should just implement whatever he says.’
Agreed. but if the "cats out of the bag", "water's under the bridge", and "barn-door open" analogies are true, why bother? If on the other hand, this is a continuing evolution of technology and market, and if you think freezing it all right here is a good idea, fine!
I've tried to help the windows users (the only ones here who need us past the letter drawing), and I'm gone back to work for Mac-elites. I have gotten enough from both sides to know who pays and who doesn't pay, (or steals), and who listens as a result, as opposed to who doesn't listen (or does the opposite, every friggin' time):).
David, letter drawing is where it's at. So who needs help at this point? Anyone who wants to get a letter displayed at the size for which it is drawn in a situation in which the person coding the web content has no way to know at what ppem the text will be displayed to the reader. That seems to me the critical issue for optimised web typography, because no amount of font use ‘recommendations’ and no amount of size-specific outline designs will do any good if there is no standard and predictable mechanism by which those designs are selected and displayed for the appropriate sizes regardless of which of half a dozen or more different font size units are coded in the CSS. And bearing in mind that even a pixel is, apparently, no longer a pixel.
>regardless of which of half a dozen or more different font size units are coded in the CSS.
"Actual" size, (more or less actual size) is needed. "Relative" is fine. There no other request besides that "absolute" be based on a reasonable register of sizes (with a 1.1 factor between sizes ala Firefox). This is a problem, but as you say nothing maeks any difference is capricious decisions are made at Redmond, where one month there is no way they'll support OT on the web, and next month they can't see any other choice, and next month.. and so on.
>So who needs help at this point?
You'll see, just give it time.
David, what do you mean by actual size? I would take that to mean measurable size of displayed type, but perhaps you means something else?
The problem as I see it is that if one is drawing outlines sets optimised to specific pixel grids then ppem is the selection criterion for the desired outline set. That means one needs to know the ppem size of font to be displayed at a nominal/actual size*, which is of course resolution dependent. It's the familiar triangulation of nominal size, device resolution and ppem size. Knowing any two of these things allows you to calculate the third.
Now, what normally happens with scalable outline fonts is that the calculation to determine what ppem size to render occurs locally, at the point at which the text is rendered on the reader's device. That is the point at which the rendering engine knows the two parts of information it needs -- the nominal type size and the local device resolution -- to be able to calculate the ppem size to display.
Okay, so if we're envisaging a system in which a rendering engine, instead of scaling a single outline set to a particular ppem size, calls a size-specific outline set, then either the font delivery mechanism needs to be informed what the appropriate ppem will be and deliver the correct outline set, or the rendering engine needs to be able to select the appropriate outline set from available sets for the locally determined ppem size. Within this basic split of approaches, I can imagine numerous practical implementations involving various ways of packaging and delivering the different outline sets. A single font containing multiple outline sets, for example, obviously fits into the second model -- post-delivery selection from available sets rather than requested delivery of s specific set --, but I can think of at least three reasons why this is a less than optimal model (and hence why I don't think GSUB is a good solution to size-specific type): TTF/OTF fonts have a built in limit to glyph set size; to truly optimise outlines to the pixel grid, different sets benefit from different UPMs; downloading all possible sizes for web fonts before making a selection for a particular size is a bandwidth issue.
*For the purpose of this discussion, we might as well consider nominal and actual to be the same thing, taking into account your ‘more or less’. In other words, we'll presume that if a web designer has specified type in e.g. points in the CSS then the actual size will be something reasonably close to the nominal size, taking into account rounding of the scaled UPM to the ppem height.
RF>outside agitators from up North
Ah... don't read into it. Whenever I hear talk about "them vs us" I reflexively burst into a bad impression of George Kennedy in "Cool Hand Luke". (Or maybe it's Rod Steiger in "In The Heat Of The Night".) Or maybe, in this case, it's "Cool Hand Luecke" - he's a good ol' boy, he is.
It's a bad habit. Online you don't get facial expression and tone of voice.
RF -- Are you actually arguing for secrecy about it? A "don't tell" policy?
What "secrecy" and "don't tell" policy? I described how font licensing works. Which licensing process is the opposite of "don't tell". It is "full disclosure" since you are shown what you asked to agree to. Second, I didn't argue for or against anything. I gave a description how things are.
RF -- The topic was IE9 enforcing the embedding bits
Topic of this thread is the announcement of IE9 PP3. Your topic is embedding bits. My topic is that your topic is a non-issue at best and misrepresentation at worst. Summary: Bits express EULA. Font not working indicates violation of EULA. Not technical problem but licensing problem. If in doubt, contact foundry.
RF -- Thanks for describing me as too informative
I didn't. I described you as avid agitator. Big difference. Presenting well-known stuff as long-hidden now-unveiled secret knowledge is cheap rhetorics and an insult to Typophile. Here, information have been exchanged freely long before RF started pretending to finally uncover how things really are.
Given how you distorted what I wrote you seem to have serious troubles comprehending even simple texts. My compliments though for the nonchalance with which you go over that fact.
And unless you want to embed a bit more of a rhetorical shoe up my rear end – my compliments to you, as well!
JH> David, what do you mean by actual size?
ppm = dev.res./points per inch. the holy grid.
Just to reiterate, font size adjustment is just something peculiarly useful on the web vs. print. In print, when a designer executes a font style change to a document (of fixed-size), they recompose.
Here’s what’d happen, e.g., if Youtube wanted to just use Comic Sans as a Custom Web Font. . .
Comic Relief I, perhaps.
Some designs and some fonts, need not worry about a font style change requiring recomposition, but then again, lots of sites can’t afford to rewrite their css unless there is that little bit of leverage in the recomposition software to account for @ff's diversification of type metrics.
And the lack of this command is not just one thing, it's also another. ;)
Comic Relief II
Now of course the type designer is at fault for not doing all the glyphs, but how's the user ever going to know that. I mean, it's Microsoft's fault as far as the user can tell, (even if this is on a Mac in Firefox. ;)
JH >For the purpose of this discussion, we might as well consider nominal and actual to be the same thing, taking into account your ‘more or less’.
“More or less”, was in the context of the difference between the PS, TeX and Linotype versions of 72.xxx points per inch. We had this discussion a while ago — I said it’s pretty funny that one can select “smaller” in a browser, and if they already selected “smallest”, then their type will get bigger? The chorus said points are a dead measurment.
JH >...the point at which the rendering engine knows the two parts of information it needs --
It never does ever know exactly, if one part is really distance of use, and the other part is actual size of type. The first is guessed at by the various developers, sometimes in concert, like in Apple environments, sometimes... not so concerted. The actual size, as we know, is unknown until the user sees it.
JH >Okay, so if we're envisaging a system... to be able to select the appropriate outline set from available sets for the locally determined ppem size.
You can envisage this, but you cannot execute it, except forever. ;)
The bottom lines for me on IE9 is that it closes one loop-hole in the founder's need to worry about jumping through the hinting -hoop "just so", and IP-wise, it's the end of any sort of pretext of helping founders much.
Given that there are the traditional web-safe fonts, and web font subscription services (including—shameless plug—our own WebINK at Extensis), all of which avoid these issues and the "need" to modify fonts, an argument of "necessity" to illegally modify font software holds not even a ml of water. Neither legal nor moral necessity applies.
(I recognize that there are fonts for which it would not be illegal to make a modification to the embedding bits; the question at hand was that if such modification were forbidden by the EULA, could it be justified by "necessity"?)
P.S. The only plausible exception I could see would be a case where the text could not be displayed without a custom font (say, some really obscure language), *and* the display of that text on a web page was somehow vital to life and limb or at least general welfare. Then you might make a case of "necessity," but it seems like a pretty improbable corner case. But sure, I'll recognize the theoretical possibility.
(edited to fix a punctuation error)
Congrats on the WebINK Beta. Gonna check it out. Bought a Mac, too, so maybe I'll invest in Suitcase for it.
TP>an argument of "necessity" to illegally modify font software holds not even a ml of water.
OK. But I'm beginning to think I miswrote or wrote unclearly somewhere along the line on this thread.
Allow me a "do over". Maybe I got too lofty for my own good.
All I am trying to say - and this is not overreach - is that word will get around that if you try to use fonts, because of IE9, there is a hidden "gotcha".
Not TTF or OTF, JUST FONTS, PERIOD!
That's not good for font vendors who ask money for their product, not good for the "free" font people, not good for web designers and site owners, not good for frackin' anybody.
JUST ANOTHER BARRIER, JUST ANOTHER STUPID PROBLEM. JUST ANOTHER MISCONCEPTION TO EVERCOME.
And what a great marketing strategy for everybody concerned: LET'S MAKE FONTS HARDER TO USE!!
Fonts for self-hosting are being sold now, today. How the heck do you know that you won't be totally on board with that a few years from now?
You don't and you can't because if people ain't buyin' subscriptions to the fonts umbilically connected to your servers and the guys selling fonts for self-hosting are making money, you (or the folks who are your suppliers right now) are danged well going to do it. (One, I know of, already is.)
At that point, there are always going to be some customers who will host the fonts raw right along with EOT and WOFF no matter what your license says. (Are we going to live in the real world or not?) They'll convert to SVG without permission, too. They paid their money and F-CK YOU will be their attitude. Do you think IE10 won't have the SVG fonts module in it and this whole installability thing will become a joke?
Do you expect that customers will come back eager to pay for an expanded license?
As far as I can see, absolutely nothing is being deterred THAT'S WORTH THE OVERALL COST.
Maybe I'm missing it, what is being deterred that's worth the hassle to everybody?
You don't see me complaining about same-origin restrictions, do you? Well, there are some people who *are* bothered by it. And they are as entitled as me to their opinion. It's their web, too, but I don't see it as an issue of principal.
But when you're talking about one browser breaking interop because of a hidden "bit" within the "font software" when the font software can't know what the heck my rights to the font are or aren't, well, screw that.
On the web, the free and the paid swim in the same pond and they all catch the same diseases.
It's stupid from a PR perspective for Microsoft to do it. Just another proprietary piece of bullsh-t from the folks that brought us IE6 - that's what will be said.
IT'S NOT WORTH THE COST.
IE9 buys into the whole standards-based developer wish-list.
Why nickle and dime over this when it won't do a damned thing?
That's it. I'm taking my bat, my balls, and I'm goin' home now.
I actually agree that it would be simpler and better if IE 9 just skipped raw TTF/OTF support altogether, that than to do it, but do it differently than everybody else. This is aside from any questions about whether the approach used by IE is "reasonable" or any such debates, just as a matter of practicality.
I don't necessarily see people taking existing TTF/OTF fonts and twiddling the embedding bits to make them work with IE 9, however. Why wouldn't they just use EOT (which they'll need to have for IE 8 and earlier)? Only after old versions of IE fade away could this become an issue.
curious as to what folks think about the typographic rendering quality?
RF> All I am trying to say[...]is that word will get around that if you try to use fonts, because of IE9, there is a hidden "gotcha". Not TTF or OTF, JUST FONTS, PERIOD! That's not good [...] not good [...] not good [...] not good for frackin' anybody. JUST ANOTHER BARRIER, JUST ANOTHER STUPID PROBLEM. JUST ANOTHER MISCONCEPTION TO EVERCOME.
There are hidden got yous, barriers, incompletenesses, traps and hindrances all over one place, agreed. But we're all professionals here and there is no need to capitalize, if I may be so bold.
MD> ...about the typographic rendering quality
Well, I think it's the best default Windows IE rendering so far.
What I still don't quite understand is why it's not possible to create a font rasterizer that does a better job with unhinted TrueType fonts. For example, unhinted Japanese TrueType fonts at default browser text sizes are still relatively unreadable, even with DirectWrite. Apple's font rasterizer, which ignores hinting, does a much better job with these fonts. Sure, it gives “fuzzy” results compared to a properly hinted version of the same font but hinting is a huge cost in the case of Japanese given the large number of glyphs that need hinting for a basic web font (at a minimum 3000-6000 glyphs) and the relative complexity of the glyphs involved.
John D: Of course it's possible; you've just said that Apple has done so. Still, I'm thinking that there's a chicken and egg problem here as well. Unhinted fonts are pretty rare, so there isn't a lot of incentive for MS to invest a bunch in optimizing their rendering. Apple optimizes their rendering because they ignore all the hints anyway, so hinted fonts are treated the same as unhinted....
Has anyone looked at CFF based WOFFs in IE9?
Unhinted fonts are pretty rare
And all the years I thought it is the opposite!
Unhinted fonts are pretty rare…
Only if one counts fonts that were shot through an autohinter. That's hardly the target font for Microsoft's text rendering.
TP>Unhinted fonts are pretty rare
Yes but fonts designed and hinted for the screen are even rarer, Thomas. ;)
JD>...possible to create a font rasterizer that does a better job with unhinted TrueType fonts[?]
What you are getting at is the two models; don't change the input — it just works (Apple), and don't change the input — it doesn't work anyway, (MS), are entering the global spotlight.
@all, and especially Cool Hand:
Relevant to this discussion:Fixing Web Fonts, A Case Study
From the Ars Technica review of the IE9 preview 4:
The browser's standards conformance has been improved, too. It now earns a score of 95/100 in the Acid3 test. The five failing tests are all in areas of the SVG specification that are in transition; SVG fonts and SVG SMIL animation. The SVG working group is considering making SVG fonts optional, as WOFF fonts—which Internet Explorer 9 will support—appear to be the standard that has gained momentum. In a world with widespread WOFF support, SVG fonts are unnecessary. The Mozilla project is taking a similar stance.
In the penultimate sentence ‘SVG fonts’ can be replaced by ‘naked TTF/OTF fonts’ and the statement is just as valid. More valid, in fact, because unlike SVG fonts the use of naked font linking was never part of a W3C standard in the first place.
"In a world with widespread WOFF support, TTF/OTF fonts are unnecessary."
...is a joke right?
I mean you would have to make no type products, have no type expertise, probably be working on some delusional agenda at a single-generation-at-most "foundry" to believe the installable format all web browsers recreate, the desktop and mobile computers use, the only source of WOFF, and a main source of fonts in pdfs... is unnecessary.
Does not sound "Bright" to me. It's good we don't have such uninformed and peculiarly blind-to-the-facts de-visions around here. ;)
I'll go read the whole Ars T piece but from the quote, it seems like the writer doesn't know WTF he's writing about. He's a parrot. Polly want a cracker?
>In a world with widespread WOFF support, SVG fonts are unnecessary.
Clueless statement. Apples and oranges.
We can call it something else if Microsoft and Mozilla would prefer - IE supports a functional equivalent called "Vector Markup Language" (VML) right now and it's how Cufon generates fonts in IE.
It's been supported in IE for a very long time. I guess they feel the whole idea was a mistake to begin with. The "Word Art" feature in MS Publisher should be dropped, too, under the same principle.
Microsoft WOFFles On SVG Web Fonts In IE9
Now, how about font data delivered as base 64 data URIs? IE9 doing anything with that?
(Start the countdown, I give it two IE Blog posts before we hear about it.)
Ahhhh, the heart has its reasons that reason knows not of. Browser developers, too.
David, 'unnecessary' as a web font format in browsers that support WOFF, as is perfectly obvious from both the general context of the discussion and the specific context of the parallel to SVG fonts.
Rich, it's the W3C SVG working group that is considering making SVG fonts optional to support of that standard. It's a decision that reflects two realities: the lack of interest from IE and Mozilla in implementing SVG fonts -- IE's VML is similar, but similar doesn't count in standards compliance, which is the point of the Ars Technica comment --, and the standardisation of WOFF by the W3C. It's an acknowledgement that SVG fonts are unnecessary to a web fonts environment if there is a W3C web font standard that a) defines a better format (remembering that SVG fonts have no hinting) and b) has an explicit conformance specification that states that all web font formats other than WOFF are optional, which is the case.
I can think of some other reasons why MS would not want to support SVG fonts in IE (though I also think John's comments above are quite true). I think I'll do a blog post about it....
I see John, yes you are absolutely correct in the context of an ivory tower perspective. But necessity in your world seems to be based purely on theoretical knowledge gained while not working the problem yourself.
We who do work the problem, all know there is a huge difference between SVG and TTF/OT. Or can you recommend an SVG to WOFF converter?
David, it's a simple enough and purely practical point: if a browser supports WOFF, there is no technical need for it to support any other delivery format for web served typography. The W3C sensibly recognised this when they made support for only one web font format necessary for standards conformance: you only need one to make it work. For backwards compatibility with existing browsers, web authors and web font services are going to need to continue to serve multiple formats targeting various browsers. But the browser itself only needs to support one. The browser doesn't gain anything by supporting more than one. Ergo, for any new browser that supports WOFF, any other format, whether it is SVG or naked TTF/OTF or EOT is unnecessary.
The differences between these formats are irrelevant to the question of whether any of them is necessary in a browser that already supports WOFF.
JH>...a simple enough and purely practical point: if a browser supports WOFF, there is no technical need for it to support any other delivery format...
Well, there's graphics, and SVG and ttf/otf being served. And that, I believe creates a technical need to support them all. Simple enough from a practical point, that point being, people serve what they serve and you can't change it with browsers, can you... technically? I'm not sure wht practical point you stand at where you see otherwise.
> For backwards compatibility with existing browsers, web authors and web font services are going to need to continue to serve multiple formats targeting various browsers.
And new browsers will be forced to comply with the public's dirty old serving habits forever (with no path from those servings to WOFF).
>The browser doesn't gain anything by supporting more than one.
Just plain silly John, browsers must have something to gain by supporting beyond the 1 Technically Required format, ttf/otf, or we wouldn't be having a party.
The fact that all browsers are, to date, picking and choosing which of the non-standard web font formats to support is evidence enough that no browser maker thinks it necessary to suppport whatever format a web publisher happens to serve. You have it entirely backwards, David: web publishers serve the formats that the browsers support, and they target specific formats to specific browsers. If this were not the case, if things were as you say, then Google et al would be supporting EOT; it is after all still the most widely supported web font format in terms of installed browser base. But obviously the fact that people are serving dirty old EOTs in order to target IE6-8 means nothing to Chrome and Firefox and Safari. The browsers don't need to comply with what the public serve, the public needs to comply with what the browsers support. It is in the interests of both the browsers and the public to agree on a standard, so that moving forward the requirements become fewer rather than more numerous and the cross-browser behaviour more predictable.
John: "...obviously the fact that people are serving dirty old EOTs in order to target IE6-8 means nothing to Chrome and Firefox and Safari."
Lol, obviously, as there are legal reasons they don't and won't and never will support EOT. Is it dead yet?
But, technically (as if I were using that term literally, and not in some goofy context such as yours), the only font format browsers and founders really need to support is ttf/ot. WOFF is a "trade" that slows things down for browsers, users, and most of all, developers.
Let's hope that trade is worth it, eh (nod-nod-wink-wink)!? I'll get to that much later.
"...browsers don't need to comply with what the public serve..."
Really John, I don't think "the public" wants to hear this yet, so I have to give you a "D" in Explanations 101.