WPF 4.0 Text Stack Improvements

Please note that the screenshots in this post are not displaying correctly. To view them in their full fidelity, right click on them and save them as a .PNGs. Then use your image viewing program of choice.

Text Formatting API

The attached property TextOptions.TextFormattingMode has been introduced to switch the text metrics used by WPF while formatting text. There are two settings for this property, and the value of this property is inherited by an element’s children.

·Ideal – Ideal text metrics are the metrics which have been used to format text since the introduction of WPF. These metrics result in glyphs’ shapes maintaining high fidelity with their outlines from the font file. The glyphs’ final placement is not taken into account when creating glyph bitmaps or positioning the glyphs relative to each other.

·Display – In this new formatting mode, WPF uses GDI compatible text metrics. This ensures that every glyph has a width of multiple whole pixels and is positioned on whole pixels. The use of GDI compatible text metrics also means that glyph sizes and line breaking is similar to GDI based frameworks. That said, glyph sizes are not the only input into the line breaking algorithm used by WPF. Even though we use the same metrics as GDI, our line breaking will not be exactly the same.

Here is a small code snipit of this property in action…

<StackPanel>

<TextBlock>

Hello World ...Ideal text formatting

</TextBlock>

<TextBlock TextOptions.TextFormattingMode="Display">

Hello World ... Display text formatting

</TextBlock>

</StackPanel>

Screenshot of the code snipit above. It is a comparison of ideal vs. display mode text

The above screenshot makes it hard to really get a sense for how much text quilty has been improved. Below is an excerp from the Magna carta rendered with ideal mode (top) and display mode (bottom). Notice that the display mode text looks much better. In specific, the stems of letters are more crisp, the text appears to be darker, and there is no color fringing around glyphs.

TextFormattingMode Usage

Both text formatting modes have their advantages and drawbacks. Ideal mode text offers optimally shaped and spaced text. This translates to less reading fatigue for end users; however at small text sizes, these benefits are negated by blurry rendering. On the other hand, display mode text provides the clarity of pixel snapped text at the expense of glyph shape and placement.

Many times, the difference between ideal and display mode rendering can be very small; however there are some scenarios that lend themselves to specific formatting methods. These scenarios are called out below. If none of these scenarios are pertainent to your app, try out both formatting modes to see which provides the best results.

Ideal Mode

·Large Text – As the size of text increases, the clarity issues with ideal mode text dissapate. After about 15pt, ideal mode text is just as clear, and better spaced, than display mode text.

·Transformed Text – Ideal mode text is designed to be drawn anywhere as opposed to display mode text which only looks good if it is rendered on pixel boundaries. Applying transforms to display mode text can easily skew pixel alignment that the WPF text stack has applied to the text. This causes the display mode text to become blurry. If a transform is applied to text, we recommend that ideal mode be used.

·Zoomed Text – Zooming text is a special case of transforming text. This is the worst of all 2D transforms for display mode text. For display mode text, the text metrics no longer scale linearly with a linear size scale. While in ideal mode the bounding box of text rendered at a 2.0 X and Y scale (using a WPF RenderTransform) is exactly twice the size of the same text rendered at a 1.0 scale. This is no longer true for display mode text. In order to maintain correct hit testing and rendering for display mode text in a RenderTransform, we must scale up the text bitmap from the original 1.0 scale. This results in blurriness and artifacts at any significant scale change. If an app requires that text be zoomed, we suggest that this be implemented by increasing the text size.

·Design Scenarios – When the shape of glyphs are very impartant, ideal mode should be used. This is most common in designer scenarios.

Display Mode

·Small Text – Depending on many factors (eg. monitor type, screen resolution, text antialiasing algorithm, etc…), small WPF text can appear more blurry than text rendered using a GDI based technology. In these scenarios, switching to display mode should solve these problems.

Text Rendering API

The attached property TextOptions.TextRenderingMode has been introduced to control the antialiasing algorithm used by WPF when rendering text. There are four values for this property, and it is respected by all children of an element

·Auto – This mode will use ClearType unless system settings have been set to specifically disable ClearType on the machine.

·Aliased – No antialiasing will be used to draw text.

·Grayscale – Grayscale antialiasing will be used to draw text.

·ClearType – ClearType antialising will be used to draw text.

Here is a small code snipit of this property in action…

<StackPanel TextOptions.TextFormattingMode="Display">

<TextBlock>

Hello World ... ClearType

</TextBlock>

<TextBlock TextOptions.TextRenderingMode="Grayscale">

Hello World ... Grayscale

</TextBlock>

<TextBlock TextOptions.TextRenderingMode="Aliased">

Hello World ... Aliased

</TextBlock>

</StackPanel>

Comparison of ClearType vs Grayscale vs Aliased text. All text in this screenshot is using display mode.

TextRenderingMode Usage

In general, Default is the best setting for TextRenderingMode. In a world where LCD monitors are becoming ubiquitous, ClearType often produces the crispest text. In scenarios not conducive to ClearType (eg. CRT monitors, users who have abnormally high color sensitivity, etc…), users sometimes disable this technology via system settings. When TextRenderingMode is not set or specifically set to Default, WPF will use ClearType unless the framework determines that the user has disabled it.

East Asian Text

The new WPF 4.0 text stack also contains improvements to East Asian text rendering. In specific, our text stack can now take advantage of embedded bitmaps. Some East Asian fonts contain bitmaps for certain characters at small sizes. Using these bitmaps can produce clearer text than letting the text stack create bitmaps from the font’s geometric data. Embedded bitmaps will not be necessary once displays have high enough resolutions to clearly render the intricacies of small East Asian text. Until that point, these embedded bitmaps provide a decent alternative. Below is an example of the improvements provided by embedded bitmaps.

String of East Asian text produced via font file data and rendered with ClearType

Same string of East Asian text (above) rendered via embedded bitmaps

Using this feature only requires that an app use a font which contains embedded bitmaps. Here is a list of the East Asian fonts that have this support.

This will go a long way towards making menu and small UI text more readable!

Has there been improvement to the blurry-text-that-animates-towards-sharpness story yet? I remember reading that when text animates, it has pixel snapping turned off. Once it reaches its target location, pixel snapping is turned back on but it alpha blends between unsnapped and snapped renders over a period of 1 second. This has wreaked total havoc on my eyes, since they see blurry text and try to focus on it only to have it appear sharp again at which point they have to refocus. Not fun. This affects many places where text isn’t really "animating" — scrolling and resizing, for instance.

WPF text is usually quite blurry. IE8 with ClearType looks razor sharp after working in Blend for a while on 3.5 SP1. Still a long way to go… hopefully the new Display mode will match non WPF text better… until we get high DPI, super high res screens: I’m sure the Ideal placement looks stunningly good at 250dpi, but were is the display hardware?

Besides that – just curious – what’s with the "save PNGs as" thing? A PNG rendered in IE looks exactly the same as the same PNG rendered in any image viewer?!?

All of these changes are definitely NOT device independent. WPF is based on device independence, and that is why originally WPF only offered ideal mode text formatting. Unfortunately monitors do not have high enough resolutions to display clear ideal mode text at small text sizes. This has forced us to include display mode text formatting.

Printers have far higher resolutions than monitors. WPF makes sure to do any DPI conversions for you so that your content prints the same on different printers at different resolutions.

Rick –

The couple properties mentioned in this blog post are not targeted at text animations. There will be a new property that should help with some of the issues that you raise. I will cover this in the future.

Axel –

Haha, I would also love it if high DPI hardware were ubiquitous. That would have saved our customers, my team, and I a lot of headaches.

Yea, one would think a PNG is a PNG. Unfortunately, somewhere between my computer, the blogging software, where the PNG is hosted, and your browser some image distortion is occurring. If you save the PNGs to your local machine and then open it from there, you can see a noticeable difference in image quality.

For example, if you look at the screenshot of ClearType vs Grayscale vs Aliased text, it is obvious that edges of the “aliased” text are fuzzy. True aliased text should not have fuzzy edges. The image that is getting displayed through the browser is an altered version of the one that I uploaded. Hopefully this is not occuring for everyone, but if it is, downloading the pic and opening it locally allows you to see the real thing.

Glad that this is finally getting sorted out, although it would be nice if Display mode was the default seen as it is better for most situations but oh well, I suppose you have to think of compatability with previous versions.

As for the problem with text animating from blurry to being sharp – I thought it was just me! I thought there must have been something wrong with my eyes, I really hope this is fixed as well..

I second the question about availability of TextFormattingMode on Silverlight 4. Current text rendering (even on SL3) is still unacceptable, especially in comparison with Flash. Are there plans to add Display mode text rendering to SL4? Thanks

Out of interest, does anyone know what level of DPI we would actually need on a monitor in order for pixel smoothing to be completely unnecessary?

Are there any manufacturers acutally producing high DPI displays at the moment (at reasonable prices)? If I was MSFT, I’d be slowly ramping up the DPI specs in the Windows Logo requirements in order to drive the industry forward.

No, embedded bitmaps do not render with ClearType. The text stack uses the glyph bitmaps which are provided in the font. These bitmaps are aliased, and the text stack does not try to modify them to use ClearType.

Josh/Martin –

I spoke with the Silverlight text team and they said that they are continually working to improve the text experience. Even though their text is not pixel aligned, ClearType is a big win for them.

Daniel –

From what I have read, most people seem to think that 200+ dpi will produce very good text clarity, and 300+ dpi will eliminate this problem (even for East Asian text).

Are manufacturers producing high DPI displays? Yes, back at Brown University the graphics lab had 3 or 4 monitors that had super high DPI (I don’t remember the actual specs). Are these monitors reasonably priced? I doubt it, and they may not be publically available. I’ve only seen these monitors in our lab, and they were used for research.

If I have forced my system to no text antialiasing, then is there a difference between Ideal and Display mode? If so, then I am still subject to the whim of developers who don’t care how blurry things look to me and how it melts my brain after 5 seconds.

I find it funny that the font rendering that was perceived as one of the worst features of WPF is now called "Ideal" 🙂 I love the changes though and am looking forward to the upcoming posts on this blog.

Gavinm – At the moment it does not appear that RenderTargetBitmap respects these settings. I’ll work with the graphics team to see if anything can be done about this.

Leonardo – Thanks for brining this to our attention. I have filed a bug and we will investigate this issue.

Z – Yes there is a difference. Since there ideal mode formatting involves subpixel positioning, there is no concept of aliased ideal mode text. In the scenario you mentioned, ideal mode text will use ideal mode formatting and ClearType text rendering. Display mode text will use display mode formatting and aliased text rendering.

Just downloaded Visual Studio Beta 2 for a second time.. I already had it installed but wanted to be sure having heard the WPF problem with text was fixed in Beta 2. So reinstalled expecting to see a nice sharp clean 2010 IDE. No chance… everything is blurred bar the Solution Explorer and a couple of other bits..

I won’t be leaving 2008 until this is sorted… end of. Some changes aren’t always for the better…

I’m going to 2nd what "Sore Eyes" reported. I just installed Beta 2 on Windows 7 running on VMware Fusion 3. It’s interesting that other Windows 7 applications have relatively nice fonts, but after 10 minutes of using Beta 2 I have to stop.

The menu bar and text editor fonts are too blurry for me (and I’ve got 20/20 vision, so this isn’t a "me" issue). Other dialog boxes and tool windows like the Solution Explorer and the Options dialog are fine.

I’m really disappointed. After trying Beta 1 and seeing the hew and cry on the web, I’d hoped you guys would have given in and reverted to the old rendering mode.

I just want to convey that as a developer, I personally don’t care if my source code scales to 400% or looks good in print.

I will not upgrade to Visual Studio 2010 until the text editor renders 10pt Consolas like it does in Visual Studio 2008.

Erik – WPF uses embedded bitmaps to improve the legibility of EA text in old EA fonts at small size. I believe the assumption here is that new fonts would be created with enough hinting information so that they render with similar clarity as if the font had used embedded bitmaps. At this time, WPF does not expose an API to force the use of embedded bitmaps if they are contained in the fonts; however I will consider keep this feature in mind when planning for our next release.

Dear WPF text team, could you please explain what is going on with text in WPF? The improvement but the text still lacks the GDI clarity. I’ve got two screenshots here, could you please take a quick look at them?

Iivari – I took a look at your screenshots and you have hit a known bug where we do not render text correctly when using: ClearType + a light color text + a dark color background. Thanks for reporting this. We are working to fix it.

Hi, I’ve been just playing with TextFormattingMode on .NET 4.0 Beta 2 and I must thank you guys for implementing Display mode because it is exactly what I’ve been missing in WPF for a long time. One question – I’m trying to turn Display mode on and off on RichTextBox programmatically to see the difference, but it does not seem to have any effect. It works fine with TextBlock etc. but RichTextBox retains the mode which is initially set and I found no way how to change it later – event tried to set the mode on the RichTextBox itself and all its visual children using VisualTreeHelper. Is this expected behavior? How can one change TextFormattingMode of RichTextBox dynamically? Thanks…

Martin – Thanks for reporting this issue. The intended design is that TextFormattingMode would need to be changed on the FlowDocument which the RichTextBox is displaying. This behavior is consistent with how other properties are not passed from the parent RichTextBox to the child FlowDocument. After trying to repro your issue, it’s clear that dynamically changing the TextFormattingMode of the FlowDocument does not have any effect. I’ve filed a bug on this issue.

We made a fix to text rendering for light text on dark backgrounds which made it into the RC build. Unfortunately, that fix did not have as large an effect as we hoped. We are looking into other fixes for this problem. Once I know something more definite, I’ll definitely make a post here and respond to the multiple connect bugs open on this issue.

Hope this will be ported to Silverlight 5. (SL4 texts looks like VS2010 Beta1 !!)

I am curious why TextFormattingMode="Display", SnapsToDevicePixels = true, UseLayoutRounding = true is not set by default. This is most wanted behaviour for 99% of developers. Who want to do animation can turn it off.