Worth noting that IE9pp3 also added support for TTF and OTF raw fonts via @font-face.

I've already noticed some oddness with IE9 downloading multiple resources when it doesn't need to and filed it on their site...

but all in all, this preview of IE9 is hugely impressive. Well done!

Worth noting that IE9pp3 also added support for TTF and OTF raw fonts via @font-face.

That's right. OpenType fonts are allowed when embedding bits are set to installable. And we implement same-origin restrictions as defined in current CSS3 Font specification, I guess this was not mentioned in release notes of this preview build.

I've already noticed some oddness with IE9 downloading multiple resources when it doesn't need to and filed it on their site...

Are you talking about fonts? And what do it mean by not needed?

Thanks,
Sergey

Are you talking about fonts? And what do it mean by not needed?

https://connect.microsoft.com/IE/feedback/details/570191/font-face-decla...

That should describe the issue at hand.

My bug report didnt mention the case of font fallback when glyphs are missing in the available character set... but that may be an interesting area to look at simultaneously.

Font-stretch? Why would you do that?

@steven acres

>Font-stretch? Why would you do that?
After a day of sitting around in one place, fonts need to get up and stretch, just like people do, silly.

(Actually, it provides a CSS mechanism for distinguishing between a condensed, normal, or expanded version of a face. Haven't tested yet. Don't ask me.)

@paul irish

Be thankful for bugs, without them what would little boys like you and me do? One of these days you need to send me your list of bug-report links so we can gang up on all the user-agent folks.
OK. So now IE supports EOT, WOFF and TTF/OTF (with the latter being restricted to fonts with embedding bits set to installable.)
Now we're going to need a Much Mo' Bulletproofer Bulletproof syntax. (Or a javascript switcher.)
More work to do....

@sergey
IE9 really, really turns a corner. SVG, Canvas and a whole lot more. Congrats. You got your mojo workin', fella.

Rich

That should describe the issue at hand.

There are three pages in your report on Connect.

First page you mentioned on connect, with single line of text on it, is not downloading anything because this @font-face is not referenced in any element. This is what we fixed comparing to IE8. But if you change the page to reference this rule, you will see that fonts from both ‘src’ declarations are downloaded. We should ignore first one, but we do download it. This is simple bug, thanks for finding it. Overall effect is kind of merged list of fonts from all src declarations on the same rule, instead of using just last one.

Second one, your blog page, only downloads single font from Google. This is what I see in network monitor and under debugger. Let me know if you see something different. Cool mouse effect on canvas, btw.

I guess, main complaint of your bug is about spec compliance on page demoing Deutsch Gothic. Test page contains two fonts on the same ‘src’ list and IE downloads both even first one will sufficient to display the page. Although this may save bandwidth, I do not see this as violation of the spec. ‘Activate’ is not exact word, and it does not define moment when I should or should not start downloading the font, there is no way to prohibit speculative downloads. Said that, I agree that it may be possible to figure out better tuning for cases when we should start downloading particular font. This is not RTM yet, so there is time to work this out.

Font-stretch? Why would you do that?

Because it is in CSS3 Fonts spec ;).

IE9 really, really turns a corner. SVG, Canvas and a whole lot more. Congrats. You got your mojo workin', fella.

Thanks, Rich. It was great pleasure working on all this stuff, I’ll tell you. Even more exciting to seeing it out.

Thanks,
Sergey

Sergey: OpenType fonts are allowed when embedding bits are set to installable.

And so the notion that document font embedding and web served typography are somehow the same thing is perpetuated. I wish you hadn’t done this. The practical implications are limited, since so few fonts have the document embedding bits set to installable, but it is a misleading confusion of categories. Worse, by arbitrarily limiting the support to fonts with the installable setting, you are equating web served fonts with locally installable fonts, which is exactly the opposite of the impression that the web font standard (WOFF) is designed to promote.

@sergey

Although this may save bandwidth, I do not see this as violation of the spec. ‘Activate’ is not exact word, and it does not define moment when I should or should not start downloading the font, there is no way to prohibit speculative downloads.

As far as "speculative" downloading of fonts versus "on demand" loading - by way of a solution, perhaps something that acts like the "defer" attribute of the script element would be helpful.
I see three situations:
1) Totally speculative - the font declared is immediately requested
2) Browser waits to determine if the font is actually used on the page and then requests.
3) Font is "lazy loaded" after the page is rendered - as some resources are so as to cache them or "defer" them. One example would be a font that's only used in a print stylesheet but has no bearing on screen display. Deferred loading would also be useful with italic and bold fonts that, when absent, are simulated by the browser and can thus be more subtly updated when the font arrives than can the "normal" text.

None of this is being discussed in the Fonts WG, but there would be no violation of the spec that I can see, either. In fact, providing these options would enhance interop with Firefox, for one.
This might be worth running by the members of the WG.
Ease of implementation for such a thing? I'd be interested to hear.

rich

>Font-stretch? Why would you do that?

>>Because it is in CSS3 Fonts spec ;).

So is font-size-adjust and a dozen of other properties, heretofore ignored exclusively be IE...
but if font-size-adjust is supported by IE9 that would be a minor coup on the way to functioning @FF.

>...it provides a CSS mechanism for distinguishing between a condensed,...

It does not. And I love your meaningless quote about DW.

Cheers, and faux pax to all!

RF>...it provides a CSS mechanism for distinguishing between a condensed,...

DB>It does not.

Of course, your knowing what a thing isn't doesn't prove you know what it is. So, what does font-stretch do?

DB>And I love your meaningless quote about DW.

I love it too. You know, after reading your comment I felt like Oscar Madison in the original "The Odd Couple" who took hours to figure out that the "FU" in the note Felix left him was short for "Felix Unger".
It took me about ten minutes to figure out DW stood for "DirectWrite".
Your criticism is meaningless by any font-stretch. Especially without quoting the quote.

cheerz, rich

>So, what does font-stretch do?

Nothing until a large number of IE9's exist. ;)

>Your criticism is meaningless...

That's definitely true.

Cheers!

@paul irish

I discussed this with Sylvain G and Ethan Dunham (not you too?) some months ago.

In IE9, as long as tagesschrift.ttf has the embedding bits set to installable, my understanding is that IE9 won't and should not "double back" and grab the EOT.
That not what's happening here?

@font-face {
font-family: tagesschrift;
src: url('http://paulirish.com/tagesschrift.eot');
src: local('☺'), url('http://paulirish.com/tagesschrift.ttf') format("truetype");
}

Anyway, to prevent such scenario, I was assuming the following would work for both IE9 and IE6-8, too.
@font-face {
font-family: tagesschrift;
src: url('http://paulirish.com/tagesschrift.eot');
src: local('☺'), url('http://paulirish.com/tagesschrift.eot'),url('http://paulirish.com/tagesschrift.ttf') format("truetype");
}

IE9 should pass by the first src descriptor and parse the second, stopping when it finds the first file it can use - the EOT.

Haven't tested nothin' yet. But I saw this "uninstallable TTF causing double download" problem coming. IE9 can't know if the TTF is eligible until it downloads and inpects. Then - if you read the spec carefully - it's kind of/sort of OK for it to double back and take the eot in the first descriptor. (It's a little ambiguous but it can be interpreted to allow it. And Sylvain says it was drafted with this scenario in mind.)
Hence, the redundancy in the second version which should produce a single download in all versions of IE.
If not, something's buggy in Denmark. Redmond, too.

rich

> So is font-size-adjust and a dozen of other properties, heretofore ignored exclusively be IE...

Who tells you they are ignored? And why exclusively by IE? AFAIK, font-size-adjust is only suppored by FireFox so far. Of course, we decide what to implement and in what order. But it does not mean we "ignore" them. In IE8 and even just 7 months ago in IE9, we ignored SVG, Canvas, ECMAScript 5, @font-face rules, WOFF, jscript performance, backgrounds and borders, you get the idea. Anyway, I guess you just missed the wink at the end of my reply.

>Anyway, to prevent such scenario, I was assuming the following would work for both IE9 and IE6-8, too.

> @font-face {
> font-family: tagesschrift;
> src: url('http://paulirish.com/tagesschrift.eot');
> src: local('☺'), url('http://paulirish.com/tagesschrift.eot'),url('http://paulirish.com/tagesschrift.ttf') format("truetype");
> }


Yes, minus the bug that Paul found. I guess syntax that will work with current IE9 and IE8 and Firefox will be to have three src declarations:


@font-face {
font-family: tagesschrift;
src: local('☺'), ,url('http://paulirish.com/tagesschrift.ttf') format("truetype");
src: url('http://paulirish.com/tagesschrift.eot');
src: local('☺'), url('http://paulirish.com/tagesschrift.ttf') format("truetype");
}


This way, IE8 will pick middle one, IE9 Preview 3 will use first, and FireFox+"IE9Fixed" will use the last. When IE9 Preview 3 is history, you can just remove first one.

> Then - if you read the spec carefully - it's kind of/sort of OK for it to double back and take the eot in the first descriptor.

I assumed that last 'src' is used, and all previous should be ignored. I did not see in the spec anything special said about src, so it should work as other CSS properties. It is a bug in IE9 preview that we request eot from first declaration.

> But I saw this "uninstallable TTF causing double download" problem coming. IE9 can't know if the TTF is eligible until it downloads and inpects.

Same will happen for any non-compliant, corrupted files, or EOTs with root strings not allowing its use on particular site. I would say browser should be optimistic and expect page author to only reference fonts that can actually be used.

I think we are moving to spec issues that belong more to www-font than typography forum. Lets move further discussions there.

Thanks,
Sergey

>Who tells you they are ignored?

... oh, just a hunch. ;)
(http://msdn.microsoft.com/en-us/library/cc351024(VS.85).aspx)

So, based on this document, I said what I said.
I see IE is moving faster, and I am truly delighted!
But if IE9 is not going support font-size-adjust, fine, will IE10?

Cheers!

> ... oh, just a hunch. ;)
You were actually looking at two year old Microsoft compatibilty chart. First, it is not saying anything about future plans. Second, more important, if you check last draft of CSS3 Fonts spec only font-size-adjust and font-stretch are still there. And one of them is already working in current preview.

Sergey> You were actually looking at two year old Microsoft compatibility chart.

Yes I actually am. What's changed to antiquate my view?

Sergey> First, it is not saying anything about future plans.

No it doesn't, but I asked if f-s-a was supported by 9, and the answer is no?
And I asked if it'd be supported in IE10, and you didn't answer yet.
And I asked Greg and Mike and they didn't answer.

>Second, more important, if you check last draft of CSS3 Fonts spec only font-size-adjust and font-stretch are still there.

It better be still there, if the W3C's precious @ff is ever going to make a dent in the size of the web.

Sergey, Microsoft let loose the optical sizing of fonts without giving users a clue.
MS invented CT and essentially disqualified the 12 point masters of the world as text on screens.
MS made the CT collection as 14, 16 and 20 point masters and won't fix it, or let others do so.
MS supports @ff, I think, but then again support is incomplete.

Yes, the chart is old. Yes the future exists. Yes, font-size-adjust and font-stretch are still in CSS.

Any questions?

JC> And so the notion that document font embedding and web served typography are somehow the same thing is perpetuated.

I greatly appreciate all you and some of the WG are doing to try to help Windows users... but I decided yesterday I just have to "stop" and "wait" for more "help". I'm not holding my or any else's breath on this, so don't worry;)

Cheers!

David: It better be still there, if the W3C's precious @ff is ever going to make a dent in the size of the web.

As I understand it, the font-size-adjust property is designed to adjust relative sizing of fallback fonts so that they match the x-height of the missing specified font, i.e. it is a way of specifying the aspect ratio of the desired font in the CSS so that when that font is not available at least some information about it is available and can be used to calculate adjusted size of substitute fonts. Since one point of @font-face and web served fonts is to reduce the instances of specified fonts not being available, and hence reduce the instances of font fallback -- in an @font-face web, only browsers that don't support @font-face and the served web font format will need font fallback --, I don't see how font-size-adjust is critical to the success of @font-face. Indeed, I wonder if browser makers are looking at font-size-adjust as a fix for a problem that they expect to largely go away with @font-face web served typography, and hence something that they're not prioritising.

Don't get me wrong: I think font-size-adjust is a clever idea and one that the web would have benefited from since CSS first came along. Now, though, it looks like a barn-door-closing mechanism, and the horse is running free in a totally different field.

What we really need is a robust mechanism for auto-selection of ppem-specific fonts relative to the varieties of ways in which CSS allows web authors to specify type size (including, now, the 4/3 point virtual pixel!). Yes?

@JohnH: "including, now, the 4/3 point virtual pixel"\

I think you mean the 4/3 pixel virtual point. (Or maybe the 3/4 point virtual pixel?)

Cheers,

T

Agree with Phinney:

Virtual point. 3 points = 4 pixels. 3:4 ratio.
12pt (normal browser default text size for paragraph text) = font-size: 16px
Optical, schmoptical. Been that way in IE for years.

@john hudson
What we really need is a robust mechanism for auto-selection of ppem-specific fonts relative to the varieties of ways in which CSS allows web authors to specify type size (including, now, the 4/3 point virtual pixel!). Yes?

I would like to see something like this. (To the extent that I *think* I understand what you mean.)
Page Zoom is really a crude resizing mechanism but it's the kind of thing computers do so effortlessly. Recalculate and viola!
I don't think this kind of fine-tuned feature is high on the radar screen for browser makers at this time.
High pixel density screens might provide an impetus. And if those devices actually start giving the OS information about their physical size and the relationship of that size to the device's pixel count, maybe it'll even be implementable.
Right now, I wouldn't even know how to go about constructing a convincing proof of concept.

What we really need is a robust mechanism for auto-selection of ppem-specific fonts relative to the varieties of ways in which CSS allows web authors to specify type size (including, now, the 4/3 point virtual pixel!). Yes?

No. That solution will only work for businesses with the money to pay for ppem-specific fonts and it would also require experienced screen type designers to create said fonts. As nice as it would be for all of us to spend a few weeks on an island learning to create these great screen fonts from masters like you and David, it’s not a realistic option. We would run into the same problem we have with TrueType hinting: the resources to deploy it widely will not exist before the technology is obsolete.

Apple has already solved this problem: develop the best rasterizer possible without worrying about hinting or size-specific designs and get the engineers busy on better LCDs. What we really need is for Microsoft and PC hardware makers to get busy doing what they always do: admit that Apple was right and get to work on a knockoff.

James, I'm not suggesting a mechanism for size-specific fonts is a sole solution for web typography: the majority of web typography will continue to rely on rasterisation of scaled outlines, with or without some amount of hinting. The problem that I seek to address is optimised readability on screen within the context of the variety of rasterisation models now in use and emerging. The dominant rasterisation models, using sub-pixel rendering, decouple outline scaling and size-specific device-dependent outline and spacing adjustments (hinting), either partially, completely or in non-linear fashion. This means that the only way to optimise type for screen is to produce size-specific designs. Let me say that again, in case anyone missed the key word: the ONLY way to optimise type for screen is to produce size-specific designs.

Sub-pixel rasterisation and/or positioning, especially when combined with y-direction greyscale antialiasing, makes the majority of type look better on screen. But looking better is not the same as optimised for readability.

You mention Apple's rendering, but miss the point that by decoupling font scaling from size-specific outline and spacing adjustment, Apple oblige designers seeking to optimise for screen readability to do so at the outline design level, because there isn't any longer any other level. Sure, type on screen under Apple's full-fuzz rendering looks a heck of a lot better than unhinted type used to look, but it can only be optimal at, at most, one size. The only way to increase the range of sizes at which type is optimised for readability is to provide individual fonts for those sizes. That is the only mechanism available by which the designer can control the outline-to-raster-grid relationships, maintain stroke density and affect spacing.

Sure, a mechanism for auto-selection of ppem-specific fonts is something that presumes customers with money to spend on the development of such fonts, and isn't something that is going to replace rasterisation of scaled outlines. But such customers do exist, and it isn't intended to replace anything, only to make possible what is currently impossible: dynamic optimisation of type for reading on screen.

For what it's worth, the Font Squirrel Generator and the Fontspring webfonts already set the fsType bit to installable. Glad to see the same-origin restrictions enforced as well, though that is stumbling quite a few developers who don't understand why fonts aren't loading on their subdomains in Firefox.

Font Squirrel Generator ... already sets the fsType bit to installable

You mean that if the Generator is processing a font that has an fsType bit set to something other than installable you are changing the bit?

>the font-size-adjust property is designed to adjust relative sizing of fallback fonts so that they match the x-height of the missing specified font, i.e. ...

Wow. To adjust the sizing of fallback fonts to the user's preference for text, as 1em, is what I understand it to do...

>...it looks like a barn-door-closing mechanism, and the horse is running free in a totally different field.

What, in this analogy does the horse, barn, barn door and field represent?

>the ONLY way to optimise type for screen is to produce size-specific designs.

You can prove this?;)

>by decoupling font scaling from size-specific outline and spacing adjustment, Apple oblige designers seeking to optimise...

But being coupled to a specific set of h-ware, makes a big difference. And, decoupling x font scaling from y font scaling does the same thing as yo u say, but in an open hardware environment, it's... different, don't chya know?

Cheers!

RF>Right now, I wouldn't even know how to go about constructing a convincing proof of concept.

You mean you've never used a computer to create a print document?

Cheers!

JH>You mean that if the Generator is processing a font that has an fsType bit set to something other than installable you are changing the bit?

Related to this: IMHO, MSFT's enforcement of the bits will have exactly the opposite effect that I am assuming they think it will have. I just don't get their reasoning.
Because of the potential for causing either a "double download" or, if there is no EOT as a fallback, no font download at all, I've been asking myself the question: "Well, Rich, what would you advise webdevs to do?"
The prudent, rational thing is to change the bits to installable as a matter of best practice.
How can you ask someone who's trying to get fonts to work on their web page to add to their problems? Especially a problem that's difficult to identify?
If helping to enforce licenses is MSFT's goal, they will get exactly the opposite.
Just my expectation - that's all.

Puckett>Apple has already solved this problem: develop the best rasterizer possible without worrying about hinting or size-specific designs and get the engineers busy on better LCDs

Fink>High pixel density screens might provide an impetus.

Puckett's right, I'm wrong. I changed my mind yesterday when I saw Apple's new iPhone display. Stunning.

After seeing it, I came away thinking that a precise matchup between screen and print:

DB>You mean you've never used a computer to create a print document?

will seem like great effort for little in the way of result by most people's lights. Me included, I'm pretty sure, based on what I saw yesterday.
I'm now wondering how long it will be before larger screens of that quality make it to market.

(My right eye is highly disabled due to wet macular degeneration and I have always been astygmatic in both eyes. The screen on the new iPhone is so superior, I've decided to sell my current model on Ebay and get the new one. These little smart phone screens drive me crazy, this is the first one that's close to tolerable. About as close to the sharpness of print as I can imagine. Better, really. In addition to being sharp, the text pops right out at you.)

I'm now wondering how long it will be before larger screens of that quality make it to market.

As I’ve noted before it will be sooner than anyone thinks. What else is left for display vendors to market? Size, contrast, color depth, and energy efficiency have all become mostly irrelevant relative to cost. And now that LCDs have been selling with long-life lamps for a few years vendors can’t just wait for people to upgrade dead hardware. Hi-resolution screens are coming. The downside is that for the next ten years web designers will have to target screens ranging from 72 to 300+ DPI. Have fun testing that!

David, re. font-size-adjust:

To adjust the sizing of fallback fonts to the user's preference for text, as 1em, is what I understand it to do...

Who do you mean by ‘user’ in this context? The web author or the reader?

The CSS3 spec succinctly defines the role of font-size-adjust like this:

This property allows authors to specify an aspect value for an element that will effectively preserve the x-height of the first choice font, whether it is substituted or not.

In any case, even if your understanding were correct, this would still be something that relates specifically to fallback font mechanisms, not to web served typography.
___

What, in this analogy does the horse, barn, barn door and field represent?

horse = type on the web
barn = locally stored fonts (requiring fallback font mechanisms)
barn door = font.size.adjust
field = web served fonts (no fallback font mechanism required except where web served fonts not supported)
___

You can prove this?

I thought you had. :)

It follows logically that if the instruction set no longer does what it used to do, i.e. make size-specific outline adjustments relative to the grid, then such adjustments need to be made at the outline creation level, with size-specific fonts. Or, if you want a more precise analysis, with size-specific outline sets, which with present font format technology implies separate fonts. It is possible that the outline sets for different sizes could be incorporated in the same font, but there are drawbacks to this approach: a) outlines fit best to grid if the UPM varies to a multiple of the design grid for each size and b) it won't work for fonts with really big character sets, e.g. Chinese, because you'll hit the 64k glyph limit.
___

But being coupled to a specific set of h-ware, makes a big difference. And, decoupling x font scaling from y font scaling does the same thing as yo u say, but in an open hardware environment, it's... different, don't chya know?

No argument from me there. Apple, Microsoft, Adobe, and anyone else using sub-pixel rendering/positioning and/or ignoring some or all of the instruction set are pushing optimisation of on screen type onto the outline. James was suggesting that Apple's rendering somehow solves the issue of readable text on screen. Leaving aside the fact that I think ClearType does a better job of maintaining stroke density consistency and, as you say, Apple has the advantage of (mostly) not operating in an open hardware environment (Safari on Windows is a wild rendering ride), I'd say, rather, that by providing the lowest common denominator of instruction support Apple defines how size-specific outline creation needs to be done to optimise a design for a given size across the majority of rendering environments. In other words, if all sub-pixel rendering worked like ClearType, we'd only need to optimise outlines horizontally relative to the grid, and could hint in the other direction. But Apple's rendering obliges us to optimise outlines in both directions.

Rich: Puckett's right, I'm wrong. I changed my mind yesterday when I saw Apple's new iPhone display. Stunning.

James: Size, contrast, color depth, and energy efficiency have all become mostly irrelevant relative to cost

Making small high resolution screens for mobile devices is relatively easy and cost effective. But the larger a screen gets the greater the chance of a manufacturing error resulting in a dead pixel. Since such an error means that the whole screen needs to be junked, the attrition costs of manufacturing larger high resolution screens has been considered prohibitive.

I saw my first 200ppi screen twelve years ago. For much of the intervening period I worked daily on first 133ppi and then 144ppi laptop screens. I've been waiting a long time for widespread adoption of higher resolution computer monitors, and it hasn't happened. Only when screen size came down did resolution start going up. But meanwhile, I've gone in the opposite direction: my desktop screen is only 96ppi, but is it huge (30") and I sit further back than I used to.

Want high pixel density? Move your chair.

At ATypI I raised the question regarding IE’s possible support for raw fonts, and the approach of using the installable embedding bit as an “opt-in” for web site designers using open source, freeware and custom fonts. Even though that concept hasn't been documented yet, I don’t see how it confuses things - Type Squirrel seems to get it. I don’t think anyone could claim ignorance in switching the bits in commercial fonts.

Although naturally type designers and foundries preference is that IE not support raw fonts at all, acting as a roadblock to raw font deployment, that wasn’t an option for the team. I mentioned Acid 3’s inclusion of raw font support in my talk, indicating non-support would be a standards “hole” competitors would exploit.

Certainly ignoring document embedding bits completely would be easier for all concerned. Happy to field type designer and foundry feedback on this question, here or off-list.

Seems as if the thread has taken a bit of a tangent. I for one would love to understand how web designers and users feel about the quality of the commercial fonts used in the demos, compared to the freeware alternatives. Do people consider the quality as something they’d be willing to pay for? Also feelings on DWrite vs other rendering environments.

@Richard F:

I agree that the "Retina display" on the new iPhone is truly stunning. I will certainly upgrade. I am however wondering how long it will be before we see 300+ ppi on larger screens, and at what price. I'm sure it will happen, but I'm not so sure it will be next week. (Not that I claim any inside knowledge on this point, just skepticism.) I was surprised and disheartened when the iPad came out with only 1024x768... not much better ppi on that than on my 18.4" HP laptop with 1920x1080, and noticeably worse than the original iPhone.

Embedding bits: You and Ethan may not care much, but I'm sure that many font vendors will view modifying embedding bits as a violation of their EULA. I expect this is true even of some that otherwise allow modifications to their fonts. Then again, many of those same folks wouldn't permit their fonts to be self-hosted by customers on public web sites, either.

Cheers,

T

Si: I mentioned Acid 3’s inclusion of raw font support in my talk, indicating non-support would be a standards “hole” competitors would exploit.

Except Acid 3 is not a standard and was not created by a standards body. It was created by WaSP, which is an industry advocacy group, and represents a cherry-picked selection of features that best apply the pressure members of that group wish to apply (apparently successfully in the case of IE9's raw font support).

I find little to disagree with in Eric Meyer's critique of Acid 3.
___

Rich: The prudent, rational thing is to change the bits to installable as a matter of best practice.
How can you ask someone who's trying to get fonts to work on their web page to add to their problems? Especially a problem that's difficult to identify?
If helping to enforce licenses is MSFT's goal, they will get exactly the opposite.

And so it goes, Si.

You could have defined a new fsType bit for raw font web serving permission, which would have precisely targeted the needs of open source, freeware and custom font makers and users, without confusing document embedding with web font serving. Remember, one of the principle reasons for developing a dedicated web font format is to draw a line between existing desktop fonts and web fonts. You could have done the same thing for raw font serving permissions, and avoided the implication that any existing font with an installable document embedding bit setting is licensed for web serving. If you feel Acid 3 compels you to support raw font linking in some way, you have rather more say in just what way than most other browser makers. You do, after all, own the OT font specification. :)

John please stop twisting my words. I said failing Acid 3 on this point was an indicator, not that Acid 3 is a standard. I also didn't say that Acid 3 compelled us. We were compelled by the same reasons as our competitors were, and we did so only after publically seeking community input.

Re an alternative opt-in, if we thought for one nano-second that Apple, Mozilla, Opera and Google would have respected such a setting I would have pushed for it harder. If you can point me to any evidence to the contrary I’d love to see it.

Also we don't own the OpenType specification, just the trademark, we can't just make stuff up and stick it in. Other stakeholders (the people who produce apps that have to enforce them) have consistently voiced opposition to defining additional embedding bits.

SII>Seems as if the thread has taken a bit of a tangent.

That's okay, right? Otherwise I can call in an expert on tangentential mediation and we can each get a mantra, or womentra as the case may be.

JH>horse = type on the web
...less than 1% today is @ff

>barn = locally stored fonts (requiring fallback font mechanisms)
...which means 99% are still in the barn.

>barn door = font.size.adjust
that's a funny door.

>field = web served fonts (no fallback font mechanism required except where web served fonts not supported)

I’ll get you a gift certificate for the iAnalogy store.

Look John, at the history of Panose; killed by the confluence of reliability, fidelity, and the fact that it failed as meta data because it only told the user what it was, and not what it was for. I want the web font format and css to know, from the bottom of my heart, reliability, fidelity, and meta data are all changed on the web. I can see it, wish you were here. :)

JH>>But Apple's rendering obliges us to optimise outlines in both directions.

Oblige? No one has optimized anything about fonts on the Mac since 1999, and no problems have come up that I’m aware of...

JH>if all sub-pixel rendering worked like ClearType, we'd only need to optimise outlines horizontally relative to the grid,

But hinting is the barrier (not letterdrawing), optimizing vertically is a given on both platforms, and optimizing horizontally is impossible on both platforms, (except for my gathering cloud-o-types), because of sub-point size specification, (before even leaving for China;)

SII>Do people consider the quality as something they’d be willing to pay for?

I don't know who would pay for anything that just works in windows next year.

>Also feelings on DWrite vs other rendering environments.

Is it worth spending $5,000 per style to do something Apple does for us for free. hmmmm.

SII>Also we don't own the OpenType specification, just the trademark, we can't just make stuff up and stick it in.

Well, no one else can make stuff up and stick it in. So, in a court of law, you own it. :)

SII>Other stakeholders (the people who produce apps that have to enforce them) have consistently voiced opposition to defining additional embedding bits.

No one here has ever suggested "the people who produce apps" have to enforce embedding bits. Only MS has ever made a format that requires the embedding bits be used for web serving of fonts. Only MS, no one here, no one else. Right?

Cheers!

(sflp)

I agree that the "Retina display" on the new iPhone is truly stunning. I will certainly upgrade. I am however wondering how long it will be before we see 300+ ppi on larger screens, and at what price. I'm sure it will happen, but I'm not so sure it will be next week

It’s really going to come down to patents. If Apple developed something really amazing in-house to make Retina Displays we might have to wait for the lawyers to work everything out (and right now Apple can afford a lot of litigation). Hopefully this is licensed tech like multi-touch and Dell, HP, HTC, etc. can start going bonkers with it next year.

>No one here has ever suggested "the people who produce apps" have to enforce embedding bits.

Wrong. Monotype and Adobe had a legal dispute over the issue.

>Well, no one else can make stuff up and stick it in. So, in a court of law, you own it. :)

Since the moment format was standardized the version of the spec posted on my site follows the ISO version. As an example the current ISO amendment changes won't be reflected on my site until the changes are ratified by ISO. So we can't just make stuff up and stick it in without breaking that synchronization, and obviously we can't just make stuff up and stick it in the ISO version.

Cheers, Si

Si, sorry, I didn't mean to twist your words: I didn't understand the point you were making about Acid 3 as an indicator. To be honest, I still don't really. Acid 3 is ostensibly a test produced by a group promoting web standards, but there is no web standard that says raw font serving needs to be supported as an @font-face implementation. So what is Acid 3 an indicator of, other than that WaSP is doing something other than promoting web standards?

David, you said, if you recall: [font-size-adjust] better be still there, if the W3C's precious @ff is ever going to make a dent in the size of the web.

Which suggests that you believe that font-size-adjust has some crucial role in @font-face. My point is that font-size-adjust is targeted at font fallback mechanisms that will be of diminished importance as use of web served typography increases. I'm not saying that font-size-adjust isn't important, I'm saying that it doesn't seem to be important in the way you suggested it is important. It's a way of improving the current situation of locally stored fonts and fallback, and would only be relevant to @font-face where the latter fails due to lack of web font support.

David: optimizing vertically is a given on both platforms, and optimizing horizontally is impossible on both platforms, (except for my gathering cloud-o-types)...

Your gathering cloud-o-types is exactly the sort of optimised screen type about which I'm talking. When are you going to stop arguing and realise that I'm agreeing with you, that I think you're right about how to optimise type for contemporary screen rendering?

In what sense is optimising vertically a given on the Mac? What I see on the Mac is horizontal strokes in varying shades of grey, and so far as I can tell the only way to optimise the appearance of those strokes would be the same way you are optimising in the other direction: creating size-specific outline sets closely aligned to pixel grids.
___

PS. Got a Palm Pre this week. Nice type.

Si: Re an alternative opt-in, if we thought for one nano-second that Apple, Mozilla, Opera and Google would have respected such a setting I would have pushed for it harder. If you can point me to any evidence to the contrary I’d love to see it.

But those other browser makers are not respecting any fsType embedding bits with regard to web served fonts. As David points out, Microsoft is the only company that has produced an @font-face implementation that associates a document embedding bit with web served fonts. As you know, I'd prefer MS not to support any sushi in Internet Explorer, and I disagree with all the reasons put forward for doing so, and I think browser makers and font makers alike should tell WaSP where to stick their Acid 3 test, but if you're going to support some raw fonts while at the same time self-imposing a limit on your support related to embedding bits, why not define a bit that clearly means 'web serving for Internet Explorer allowed', rather than assuming that a font that is technically able to be installed from a document embedded status is also allowed to be served on the web?

So now, people like Rich are going to change embedding bits to installable in order to make raw fonts work in IE, those raw fonts are going to end up in user caches, and, oh look, they're ‘installable’. Sure any number of licenses will be broken along the way, with the possibility of font makers pursuing legal action in response, but we have better things to do with our time and our limited resources. As I've said for a year now: there is no way to support raw fonts on the web that does not expose all existing desktop fonts to casual unlicensed installation and use on recipient's computers and to unlicensed use as web fonts through circumvention of embedding bits or other limitations within the TTF/OTF. So just don't do it.

SII> Wrong. Monotype and Adobe had a legal dispute over the issue.

Okay... in all the discussions about web fonts, no one has suggested "the people who produce [web] apps" and in particularly browsers, have to enforce embedding bits. How's that?

And, Simon, nothing whatsoever about the relationship between MS (or Apple) and standards, is "obvious", obviously. But is it better to change the spec or change the definition of what's already there!? as you have done. WOFF trap sprung, I think. Jokes on us.

JH> My point is that font-size-adjust is targeted at font fallback mechanisms that will be of diminished importance as use of web served typography increases.

And my point is that the vanishing point for fall back fonts is distant, and never quite disappeared.
In the transition, e.g. how do you see Bold Condensed @ffaces fallen back from with said distant vanishing point?

>...only be relevant to @font-face where the latter fails due to lack of web font support.

...or server, web author difficulties, or user choice. And, how about when an @ff doesn't have all the required glyphs the user demands?

>When are you going to stop arguing and realise that I'm agreeing with you

Right now...

>PS. Got a Palm Pre this week. Nice type.

...you're always right:)

And, as nice as it is, it wasn't nice enough for the web. Sad isn't it? But soon, you'll be able to get the web version on all your other devices and publications.

Cheers!

David, good points about relevance of fallback mechanisms to @font-face, especially with regard to character substitution (glyph substitution is an in-font fallback, e.g. if the CSS specifies a stylistic set that is not supported by the active font, I would expect the fallback to be to the default glyph for that character in that font, not a font substitution).

Agreed on OT fallback, but there is too much going on with fall back in general not to have f-s-a and f-s-a-like properties in a number of places with the staggering in of @ff use. The process of adding typographic capabilities to the web is just not well planned if f-s-a is not working everywhere yet.

More thinking sooner, I say.

Cheers!

David: The process of adding typographic capabilities to the web is just not well planned if f-s-a is not working everywhere yet.

Is it planned at all?

John H:

I think I disagree with you, if I understand what you're arguing.

Richard Fink is suggesting that web font processing tools should process existing fonts to change their fsType bits to "installable." You take that as evidence that using the absence of the "installable" setting to mean the fonts are not OK as raw-TTF web fonts is a bad idea, and a new embedding bit should have been invented instead.

I have two problems with your line of argument.

First, if a new embedding bit had been invented, don't you think that Richard would be saying web-font-processing tools should be setting that bit? How on earth would that help?

Second, I don't see the use of the installable setting the same way you do. I see it as "if the bits are NOT set to installable, then we're not giong to process the font. if the bits ARE set to installable, then we'll process the font... but that doesn't trump the EULA."

That's exactly the way I understand the existing uses of embedding bits advising apps on what to do with fonts for actual document embedding, as well. A font may be set to preview and print embedding, but that doesn't mean it's okay for that under all circumstances. There may be additional strictures, and you still need to read the EULA. Maybe it has commercial PDF restrictions, or it requires extra money if you use the PDF anywhere outside the organization that licensed the font in the first place, or it only allows you to embed fonts in documents if they are never viewed on Thursdays.

All that being said, I actually do agree that inventing a new bit would have been preferable to overloading the meaning of "installable" in this way (even though MS originally intended for these bits to apply to web fonts). I just don't think it's a huge deal, either.

The stakeholders in the Open Font Format (OpenType) spec could still rally 'round and try to get some such change through. I think it would be a fine thing. We'd need to have a firm proposal: is the new bit a positive or negative one, do we need two bits just to get around the issue of existing fonts not having a setting, or do we rev the OS/2 table version?

Cheers,

T

JH>Is it planned at all?

well, let me put it another way: size of type and color of type are not things publishers want to have this unplanned forever. ;)

TP> I actually do agree that inventing a new bit would have been preferable to overloading the meaning of "installable"

Well you've all had several years to support this suggestion made long-ago. But instead, you've used the same old excuses to create a techno-legal nightmare for publishers and placed a huge bleep of trouble into your own, Fink-ish, and user's hands.

Same thing with actual point size vs. goofiness, and WOFF's "yellow snow" meta data vs. useful m-d to foundry and user alike... huge bleep of trouble.

Cheers!

Tom, I think you've missed the train of my argument and have associated two distinct objections.

My first objection is to any support of raw fonts in web served typography. I believe it is both undesirable and unnecessary, and that the arguments made in favour of it are weak in light of the vulnerabilities -- vis à vis existing desktop fonts and casual piracy -- that it inevitably introduces. What Rich suggests is simply evidence of the vulnerability and the quickness with which it will be exploited. That he would, as you point out, presumably make the same suggestion re. any new embedding bit is simply further evidence of the inherent vulnerability in all raw font linking.

My second objection is that if Microsoft is going to implement support for raw font linking but with a self-imposed limitation, that limitation should not be based on associating an existing document embedding bit with web served typography. It perpetuates the confusion of document embedding and web font linking, introduced by EOT and now simply made more confusing by implying that web linkable = installable.

The first objection overrides the second one: the best thing is simply not to offer any support for raw font linking. It isn't necessary, especially not in a browser that already supports a legacy EOT format and a soon-to-be-W3C-standard WOFF format.

SII>...acting as a roadblock to raw font deployment, [] wasn’t an option for the [IE9] team.

Could it be something Eve gave to Adam a bite of? But my suggestion is that IE9, before it’s released, should go back to what IE8 did for font linking. IE8 is still being advertised during "That FIFA Show", so it’ll be a while before IE9 can go anywhere anyway.

Speaking of which, what if all the players on one team, except the goalie, swarmed the referee so the referee couldn’t see whether the other team was scoring or not, because the goalie just kept scooping the ball out of the net?

Back on track, the IE9 team have time to delete stuff, right?

Cheers!

JH>the best thing is simply not to offer any support for raw font linking.

And here is where we basically disagree(d). Any new format is an inviting gateway to copyright and trademark violation, as you see, as opposed to a simple licensing issue that’s solved more “naturally”. Any new format makes the browsers, (which employ the end user's device(s) to make derivative software), into agents of violation. Any new format spawns conversion programs to that format, and these can do "whatever" to “whatever” as you see. And, a new format splintered the effort to get one good format.

JC> The first objection overrides the second one:

Objections overruled. 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. WOFF can’t gather meta-data alone (if ever), and whatever surprises were to be in the “Private Data”, WOFF is not “the web standard”, so no one will make conversion software that retains it, would you? And the CSS type spec. is not well enough informed to meet the challenges of real typography on the web, anyway.

I’d say this is actually better than watching baseball played with a butterfly and nets instead of a ball and gloves. It's just sad when young readers get in the way.

Cheers!

(There's lots of good questions and points on this thread. I chose to focus on the following for now.)

Sprach Thomas Phinney:

Embedding bits: You and Ethan may not care much, but I'm sure that many font vendors will view modifying embedding bits as a violation of their EULA.

I can't speak for Ethan but I actually "care" a lot. Contrary to popular belief, I'm a stare decisis kind of guy and not naturally inclined to throw out a system that the industry has relied on for a number of years. Not without a good reason. Not without thinking things through.
But I think everybody on this thread realizes that the system as it stands isn't going to work on the web. Yet, in IE9, MSFT has decided to break with the pack, stick with the bits, and load only "raw" fonts set to installable embedding.

A couple of points:

Yesterday I found myself reading a short piece in the Harvard Journal of Law & Public policy about the concept of "necessity" as a legitimate defense to all kinds of otherwise illegal activity. (The article was about "necessity" in regards to the seizure of private property for public purpose under Eminent Domain.)
The question it raised for me was: Under what circumstances might "necessity" be reasonably viewed as a valid rationale for infringement and/or the breaking of a EULA contract? Even in just a moral, if not strictly legal, sense?
IE9 puts web devs in a position where, if the embedding bits aren't a certain way, the font doesn't work interoperably across browsers. And it won't work in what will become the world's most popular browser: IE9. And, presumably, IE10, 11, and 12, too.
(Yeah, yeah, they can make a WOFF, an EOT, whatever. That's IF they know what their options are.)
At FontCONF in St. Paul last week, I led a session of about, I think, 40 or so designers. People who - even if they aren't web designers per se - are at least font minded or else they wouldn't have been at the conference. At one point I asked the entire group if they knew that there was such a thing as an embedding bit. Except for a small group of type designers and a few cogniscenti, all I got was a bunch of blank stares. Embedding bits? They had no idea what I was talking about.

 *Before the web, enforcement of the bits was built into software. Why would anybody know about it - the software took care of it. But on the web it's different, and we've moved to an honor system of sorts. Except that nobody understands there's even a system, let alone what "honorable" behavior is expected. This is the reality, folks. And in any rational strategy, it must be taken into account *

Once having purchased a license, which may or may not be refundable, what should a web developer do to get that font to work interoperably? How many hours should they spend? How many EULAs should they try to decipher? Everybody's got families to feed and bosses to satisfy and there is very much a "necessity" involved in getting the font to work right and load as efficiently as possible.
If there were no legal considerations at all, changing the bits to installable for every font would be considered a best practice. Period. And since the average web customer will probably be unaware that there are special restrictions expected of them beyond the payment of the initial license fee and the download of the font file, what do you think they are going to do?
They are going to serve their own self-interests, their own necessity and change the bits.

(I do think, however, that most web buyers will realize that redistribution is generally verbotten. But that's about it as far as prohibitions.)

Why put web developers in a position where they have to choose like this? Why force a situation where many will unknowingly break the fine print in the contract?
What's the point of this? I'm missing it.

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

Cheers!

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

T

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?

Cheers!

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.

Cheers!

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.

Cheers!