To me that screen grab seems to be primarily demonstrating the y-direction antialiasing rather than sub-pixel positioning. However this suggests that IE will be exploiting DWrite's sub-pixel positioning.

Claus, I confused sub-pixel "positioning" with "rendering" in your question. So ignore my answer above. I know that DWrite has various modes - not sure if the screen grab represents the future IE rendering. I’ll see if I can find out.

Haven't had a chance to follow the links yet but, Si, do you know if this kind of rendering is something that's going to be triggered by the developer via CSS or some other mechanism or is it just going to happen?
Or is it going to be a part of the user-settings either in the OS or IE?
And will it be applied to all text at any size or will there be breakpoints?

Lastly, Hallelujah. About time. Flash or VML-like but without the hassles. No accessibility issues. Wonderful.

I'll just note that DirectWrite does pretty much just as nice a job with OpenType CFF as it does with TrueType outlines, even applying ClearType. It uses what is essentially the OpenType CFF rendering Adobe and Microsoft developed for WPF (technically something immediately descended from it).

I can confirm that build demonstrated at PDC is doing sub-pixel layout and positioning. If you look at the video, you can see smooth scaling and tracking which would not be possible otherwise.

IE8 used high-resolution layout, but it did not affect text where glyphs always had integral pixel width. Using Dwrite for rendering only in this case would remove jagginess, but would not improve spacing. It requires real sub-pixel text layout to make it work.

Regarding ways to switch rendering modes, this is not determined yet. There are different factors to take into account: technology available on client machine, user preferences, backward compatibility of page layout. At least my opinion is that rendering mode should not be exposed to web designer to control.

@sergeym"At least my opinion is that rendering mode should not be exposed to web designer to control."

Sergey, I'm fearful of just letting the OS make all the decisions. It hasn't worked out all that perfectly with ClearType.
How does the Dwrite rendering look at smaller text sizes?
I know it's early on, I hope the team will be keeping interested parties in the loop with more detailed examples.
Thanks.

It is not the OS making all decisions. Users already tuned ClearType to their eyes, DWrite applied its rasterization algorithms, IE chooses to use different layout parameters depending on font/size/scenario, font designer expressed his intent in hinting.

What kind of control page author do you think should have? Will this control available for every page be better than user settings applied to whole Web inside your browser?

Sergey: What kind of control page author do you think should have? (over rasterization methods)

I think none. I really wouldn't want a web author to mess with my rasterization settings ;) For users who don't care about customizing their settings, sensible system defaults should be applied (as it is now).

Claus: neither the Windows XP GDI nor the Windows 7 GDI Cleartype is using sub-pixel rendering. Is that normal?

They used an OT-CFF font for the comparison, insofar it is misleading to speak of "ClearType there. (Because OT-CFF could not use ClearType at all prior to DirectWrite.)

Also, "sensible system defaults" seems sensible, but it is how we got to a web where sizing, scaling and rendering of type are so diverse web design is constricted and type design is nearly impossible.

This morning I met with my clients in Leiden and among other things showed them comparisons of their new CFF fonts in a variety of rendering environments. They were unanimous that the WPF/DirectWrite rendering was by far the best, so I'm very happy to be able to report back to them now that IE -- and probably Windows Firefox -- will be taking this path.

If you look at the Firefox example ... neither the Windows XP GDI nor the Windows 7 GDI Cleartype is using sub-pixel rendering. Is that normal?

GDI is not capable doing sub-pixel in any Windows version. You need WPF or Avalon to render sub-pixel.

I’m curious as to what you consider “your rasterization” to be?

Also, “sensible system defaults” seems sensible, but it is how we got to a web where sizing, scaling and rendering of type are so diverse web design is constricted and type design is nearly impossible.

Maybe we just need ability to embed rasterizer into web page. This way, web designer will be sure it is working as he intended it to.

...but should know. Maybe it'd be easier to bring the info to the font. WOW, a font media query.

Except for distance which can either be solved by the user moving the user, or by the user scaling the type.
Except, oh I forgot, no one wants the user to even do font sizing correctly-ish.

Welcome to the "if it ain't as robust as Verdana, make it so" generation of type design.. ;) How long will it last? That's the new lottery. I'm nearly certain that it'll go away as soon as I finish making a dozen families of 5 pt designs. Place your bets!

"...it’ll go away as soon as I finish making a dozen families of 5 pt designs."

Would they be rendered useless with the next technology to follow? :-)

My guess is that something new needs to come along that reinterprets outlines for screen use on the fly but is not part of the typeface. The easy answer to envision is higher screen resolution but this comes at a high price. The person who invents a software interpreter that can mimic resolution enhancement and optical sizing will become a wealthy soul.

David wrote: I’m curious as to what you consider “your rasterization” to be?

"My rasterization" would be the one I chose, be it thoughtfully or by chance, through my choice of operating system, anti-aliasing settings and maybe more display tuning (e.g. ClearType tuner ...).

I'm comfortable working both on Windows and Mac OS. The different text displays don't bother me, perhaps they are even helpful to remind me inside which system "frame" I am right now. I guess if somebody (e.g. a web author) could break this consistency, it would irritate me.

It’s much easier to make stuff up about fairy resolution, write fake sci-fi patents and study people’s reactions to flash cards.

My question was very simple: what control web developer should have over rasterization parameters. And I said none, because I think web browser should be just transport mechanism, delivering font to OS rednering system. Whatever information is needed to produce best type on screen should be inculded into font, system parameters and user settings. What this information should include is critical, but completely different, question, independent from whether you use local or embedded fonts.

I think Sergey is talking about sup-pixel “positioning”, not sub-pixel “rendering”. Although i don’t know if sub-pixel positioning can’t be done by GDI.

Yes, I should have been more clear. I mean sub-pixel positioning of glyphs, which is not available in GDI.

Sergey: I think web browser should be just transport mechanism, delivering font to OS rendering system.

But is that what is currently happening? IE8 rendering of CFF fonts is completely different from Firefox rendering of the same fonts, so it seems clear that different rendering systems are being used. And of course the OS itself may employ more than one rendering system. I don't mind the multiplicity so much as I mind the lack of documentation.

sergeym >what control [should the] web developer have over rasterization parameters. And I said none,

I guess, this is what is at the heart of my request for the quest for a typographic media query in CSS.

If a web developer could: either have control via query over the OS's rasterization parameters and only in the browser set them to the web publisher's desires, or use a media query to deliver font software sensitive to the apparent preferences of the user, or some combination of each — some web design would flourish.

Then "all we'd have to deal with" are the multitude of web developer's size and style habits for type, and the fact that the users defaults should never be confused with their true preferences.;)

But I grant that just saying "No", is easier on everyone but the user.

JH>I don’t mind the multiplicity so much as I mind the lack of documentation.

And even if you have "documentation", well, see MS white paper on CT. We're perfectly free to do anything we want except the right thing. Give it time, you'll mind the multiplicity. Perhaps even enough to someday want variation technology on the client side.

From Sii's link:
>In addition to better performance, this technology shift also increases font quality and readability with sub-pixel positioning:

So, sub-pixel positioning used on text means the the image of the glyph changes from position to position among the text, for "better spacing". Adobe does this in text rendering and it works 'perfectly well" for print preview on screens in zoomable apps.

sergeym >I mean sub-pixel positioning of glyphs, which is not available in GDI.

Good. The only sub-pixel position I'm interested in, for text type in these resolutions, is under the control of glyph subsitution.

Jens>The different text displays don’t bother me, perhaps they are even helpful to remind me inside which system “frame” I am right now.

Thanks for the complete answer. Your rasterization, which I'll call "cross-platform/differential-required" in a very small minority I believe, who can I believe set their preferences to maintain said requirement. So, I believe, your requirement is quite well met today and for the long term future. . . But the counter irritated majority, I believe, is immense including those who don't think their lap should have to change size to be at the right distance from their type, depending on the OS frame.

In any case, it looks to me like DirectWrite continues the long running disunification of type handling on Windows?

We have one more issue to deal with, and one more query to make a quest for.

In any case, it looks to me like DirectWrite continues the long running disunification of type handling on Windows?

I would like to suggest that if Microsoft is going to continue using this confusing jumble of type handling methods it produce a book about designing and hinting for Windows rendering—with designers and not programmers in mind—and publish it through Microsoft press. There’s not much point throwing millions of dollars at text rendering every year if only foundries with large budgets can afford to pay experts to figure out how to make fonts look good on your OS.

@DaveB: DirectWrite is continuing to use WPF rendering. Microsoft can't just take GDI away, but they can encourage people to use something better, which is what they're doing. Of course, they could also improve GDI, which they seem to be less interested in, beyond turning (an earlier version of) ClearType on by default.

@James: I think Microsoft believes that most fonts look better under DirectWrite than under GDI. For OpenType CFF, that's certainly true. I don't think anybody needs to pay experts to make fonts look good under DirectWrite... only if the foundry wants to really maximize the potential rendering quality. But that has always required expert help.

.I think Microsoft believes that most fonts look better under DirectWrite than under GDI. For OpenType CFF, that’s certainly true.

This is a test of different Windows rendering environments that I made to show clients a few days ago. This is a CFF font with PS autohinting using the AFDKO script within FontLab (the final version will be manually hinted, because I'm not happy with all the autohinting results; see top of q for example). This is a typeface that was designed primarily for print use in book publishing, not optimised for screen reading.

PS. The Safari rendering in that comparison is using the ‘medium’ subpixel rendering setting that Apple recommend for LCD screens. It looks like crap, and the Safari rendering is better in ‘light’ mode or even in greyscale mode as recommended for CRT screens.

Of course, user preference of Safari rendering mode is likely to be both display and gamma specific and also typeface specific. In other words, it is possible for a webpage to contain two fonts that each look better in different rendering settings.

The WPF rendering is closest to the typeface design, in terms of both letter representation and spacing. PDF is second best.

[One thing I note is that the WPF rendering doesn't look nearly as good when I look at it on a different screen from the one on which I made the screenshot. When I met with my clients last week, I took the same laptop on which I had made the screenshots, so they were able to judge the comparison properly.]

Sergey, can you explain how IE8 is rendering CFF fonts? Obviously it isn't using the same Windows PS rasteriser as Firefox, but nor is it using the WPF renderer. It appears to be applying subpixel rendering (CT?) in the x-direction, but no y-direction antialiasing.

@johnhudson"In other words, it is possible for a webpage to contain two fonts that each look better in different rendering settings."

This cracked me up. So chaotic. And no cross-browser, cross-platform answer in sight.
(Sounds like we should get some of them outside standards agitators agitatin' about this. What we have heah, is a failyuh to specificate.)
But that's way premature. What is/are going to be the digital equivalents of paper and ink?
Ah, well. Implementations first. Thanks for a peek at the test shots.

@thomasphinneyif the foundry wants to really maximize the potential rendering quality. But that has always required expert help.
Must we be resigned to the "expert help" part. (I mean, there are ordinary experts, and then there are the "where the frack do I find somebody, anybody who knows how to do this?" kind of expert.)
Or, in your opinion, can the tools be vastly improved with effort and the learning curve significantly lowered?

@sergey and sii,

Based on the video presentation on Channel 9, I'm led to believe that DirectWrite will respect the current behavior of fonts - such as line breaks, word spacing, etc...
True? Not counting the inevitable edge cases - will it be essentially backwards compatible? Dare I say "seamlessly" so?

Sergey, can you explain how IE8 is rendering CFF fonts? Obviously it isn’t using the same Windows PS rasteriser as Firefox, but nor is it using the WPF renderer. It appears to be applying subpixel rendering (CT?) in the x-direction, but no y-direction antialiasing.

Interesting. IE8 is using only GDI for text rendering. I have to look at this closer to understand what the differences are between us and FireFox. And I’ll prepare few screenshots showing DWrite in IE9, to show sub-pixel rendering of TrueType and CFF fonts.

Based on the video presentation on Channel 9, I’m led to believe that DirectWrite will respect the current behavior of fonts - such as line breaks, word spacing, etc...
True? Not counting the inevitable edge cases - will it be essentially backwards compatible? Dare I say “seamlessly” so?

I am not ready now to talk about compatibility story in relation to DWrite. The best answer I can give you is that we are aware of this issue and looking at it. At least there is an ability in Dwrite to use glyph metrics compatible with GDI. There are other aspects other than compatibility, e.g. transforms, animations, SVG, that make using subpixel positioning the best option.

It makes sense to me that depending on how powerful my computer and graphics card were, I might like to turn off such amenities as ClearType, and if the web designer might prefer his page to look prettier on my computer, that should be just too bad.

The need for expert help to do high end TT hinting isn't going away any time soon. With some investment, TT autohinting could be significantly improved, raising the baseline and reducing the relative advantage of manual high-end hinting (with tools like VTT). The other thing that can be done is to develop auto-hint assistance that feeds into the manual tools, reducing the amount of expert work required to get to the best results. I've heard of multiple folks investigating or doing both approaches, but so far it's all proprietary (in the stricter sense of tools not being available to the public, not just that they're not open source).

Thanks for the info.With some investment, TT autohinting could be significantly improved, raising the baseline and reducing the relative advantage of manual high-end hinting (with tools like VTT).

No push for open-source. Open, proprietary, whatever. I'm just concerned about "available".
When Adobe tells me that they don't use Fontlab, they use "in-house" tools - well, why are they being kept in-house?
They have every right to do so, of course. Just as MSFT has every right to keep VTT's learning curve high - as long as, I presume, they have access to people who've climbed that curve and can do the work. But that helps them, not me or anybody else.
And it leaves fonts in general looking that much worse.

But I'm glad to hear your opinion that a substantial improvement can be achieved. I'm hoping it's just a matter of time.

Rich, Adobe make their OpenType FDK code available for free as both a stand alone tool set and for use by FontLab, DTL FontMaster, and anyone else who wants it.

I don't understand what you mean by 'keeping VTT's learning curve high'. The learning curve seems to me to be as high as the software demands, and isn't some kind of artificial construct. Also note that VTT represents a significant investment by MS in reducing the difficulty of TT hinting, which previously was done by writing code.