New to Typophile? Accounts are free, and easy to set up.
Create an account
Typophile RSS | More Feeds
For those following issues related to rendering type in Windows browsers...
Based on comments at ATypI, Firefox seems to be going down the DirectWrite path too.
Using the graphics card to render type, rather than the CPU: is that how Apple's Quartz rendering works?
In the text sample "96 point Gabriola on a Lenovo X61 ThinkPad at 100% Zoom: Direct2D (without jaggies):" on the page, sub-pixel rendering is no longer used. Is that the way it's is going to be?
>on the page, sub-pixel rendering is no longer used
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.
"In addition to better performance, this technology shift also increases font quality and readability with 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'm very glad to hear this.
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.
"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.
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?
Unfortunately, I can't give you build of IE using DWrite to play with right now. FireFox is experimenting with DWrite to, although I did not see any, even experimental, build available publicly. You can check out few FireFox screenshots at http://blog.mozilla.com/nattokirai/2009/10/22/better-postscript-cff-font....
If you look at the Firefox example http://blog.mozilla.com/nattokirai/files/2009/10/waterfallcomparison.png neither the Windows XP GDI nor the Windows 7 GDI Cleartype is using sub-pixel rendering. Is that normal?
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.)
> really wouldn’t want a web author to mess with my rasterization ...
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.
"...note that DirectWrite does pretty much just as nice a job with OpenType CFF as it does with TrueType outlines, even applying ClearType. "
This is very excellent news. Thanks, Si.
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.
And, of course, DirectWrite provides full OpenType Layout capabilities.
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.
>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.
If only things were this simple. There's screen resolution, gamma and orientation, viewing distance, ambient lighting etc., etc., things the browser and Web designer know little, if anything, about.
>Maybe we just need ability to embed rasterizer into web page.
A Sizer, Scaler and Rasterizer must be supplied for Windows users.
>This way, web designer will be sure it is working as he intended it to.
It's much easier to make stuff up about fairy resolution, write fake sci-fi patents and study people's reactions to flash cards.
>...things the browser and Web designer know little, if anything, about.
...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.
That's not true at all. All versions of Windows from Windows XP on fully support subpixel rendering of TrueType fonts via native GDI.
Here's the relevant MSDN documentation page for the GDI function CreateFont. Note the CLEARTYPE_QUALITY parameter, which was introduced with Windows XP.
If ClearType weren't supported by GDI, almost nothing on your screen would be able to use it.
The person who invents a software interpreter that can mimic resolution enhancement and optical sizing will become a wealthy soul.
I don't know about a software interpreter, but the human interpreter could increase font size and sit further away from his screen. :)
Neither my monitor nor my house is big enough, John :-)
>GDI is not capable doing sub-pixel in any Windows version.
>That’s not true at all. All versions of Windows from Windows XP on fully support subpixel rendering of TrueType fonts via native GDI.
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.
I wrote: really wouldn’t want a web author to mess with my rasterization ...
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.
First, someone alert the media: "Berlow And Fink In Substantial Agreement"
(Or, at least, our concerns and suspicions are the same, I think.)
Sergey and Sii,
Yes, it's going to be very difficult to analyze this without an Alpha to play around with.
1) When do you think an Alpha will be available. (If you can share that publicly, here.) Much salivating as you can see.
2) What's the minimum hardware or will any Win 7 capable box be up to the task?
Make sure to view the channel9 video - link listed on the IE Blog - for a screen demo and some chatter from the IE devs about this. Worth a look, absolutely.
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.
end part I
It was too long.
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.
Two things there:
@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.
John -- Which do you consider to be the most "accurate" rendition of your design intent, in this case?
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.
This is interesting though I wish they were unlabeled.
And why do we care about CFF cross-platform/browser rendering?
What did you use to get the WPF/DirectWrite sample?
I'm doing an article in which I want to show essentially all the above, plus a similar variety of TrueType rendering as well, for comparison. I imagine I'll start with a different typeface....
For the WPF sample, I used a test tool from MS. You could also do this with XAML in e.g. Kaxaml.
Thanks, that's helpful.
"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.
if 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?
Egads, I see.
>Fonts MIME type
TT hints are information one does not know about but ones system does, and it's a possible attack vector.
There is no end to the entertainment of font standards wrestling. :)
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.
Eagerly awaiting the screen shots.
Eagerly awaiting the screen shots.
Me to :).
As soon as I find some time, I'll do that.
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.
That's what "your rasterization" means.
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.
>I’m hoping it’s just a matter of time.