WPF 4.0 Text Stack Improvements

Published 24 August 09 07:23 PM | text 

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.

Language

Font

Traditional Chinese

MingLiu

Simplified Chinese

SimSun

Japanese

MS Gothic

Korean

Gulium

Korean

Batang

 

-Chipalo

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Doug said on August 24, 2009 3:28 PM:

MS has put the priority on screen readability, which is a good thing.

Do any of the recent changes address device independence in terms of getting text to render the same size, with consistent line breaks, on different printers? Or, has this already been taken care of?

# Rick Brewster said on August 24, 2009 4:49 PM:

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.

# Rob said on August 24, 2009 6:15 PM:

All your image links are broken.

# David said on August 24, 2009 6:19 PM:

Would love to see the sample images & comparisons but the links all seem to be broken.

# Patrick said on August 24, 2009 7:55 PM:

Unfortunately the URL's to the images in the blog post seem to be incorrect.

# danieldsmith said on August 25, 2009 4:14 AM:

Absolutely agree with Rick about the animated text blurring.  It looks absolutely dreadful and it's a strain on the eyes.

In Visual Studio the WPF Proprerties window is really painful to use :-(

# Axel said on August 25, 2009 12:12 PM:

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?!?

# text said on August 25, 2009 8:58 PM:

Doug –

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.

# PO said on August 26, 2009 1:47 PM:

Can East Asian using embeded bitmap render with ClearType?

# Chris W said on August 27, 2009 2:48 PM:

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

# Josh B said on August 27, 2009 5:46 PM:

Will TextFormattingMode be available in Silverlight 4 as well?  I think this would resolve a lot of the frustrations people have with the font rendering in Silverlight versions 1 through 3.

# Mike said on August 28, 2009 3:30 AM:

I think Scott Guthrie has the first screenshots of VS 2010 Beta 2 here http://weblogs.asp.net/scottgu/archive/2009/08/27/multi-targeting-support-vs-2010-and-net-4-series.aspx

Nice job on the text guys, it looks good now :)

# Dave said on September 3, 2009 10:50 AM:

On my previous team the one thing that prevented us from using WPF over Win Forms was the poor text readability. This is a great improvement!

# Martin said on September 10, 2009 6:07 AM:

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

# Daniel Smith said on September 15, 2009 5:51 PM:

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.

# text said on September 16, 2009 2:21 PM:

Bo –

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.

# gavinm said on October 22, 2009 9:20 PM:

Is there a way to set the TextRenderingMode when calling DrawingContext.DrawText on a RenderTargetBitmap? Is this scenario going to be supported?

# Leonardo said on October 25, 2009 4:07 AM:

Have you tried TextOptions.TextFormattingMode="Display" with FlowDocumentReader and tried to zoom? It seem like a bug...

# z said on October 26, 2009 12:46 PM:

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.

# Borek said on October 26, 2009 3:05 PM:

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.

Thanks for the great work!

# Andy Kutruff said on October 27, 2009 6:37 AM:

Good stuff!  Any improvements to text layout performance?  

# Erik Olofsson said on October 29, 2009 9:52 AM:

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

I have been trying to fool Visual Studio 2010 Beta 2 to render my custom bitmap font by using a TTF with embedded bitmaps, but have not been successful yet.

To make non-WPF applications use the embedded bitmaps the only thing you seem to need to do is include the 949 - Korean Wansung char set in the font.

This does not seem to be enough for WPF. I tried opening one of the fonts that render with bitmaps in Visual Studio 2010 Beta2 (MingLIU) in FontForge and just changing the name and exporting it again.

This caused the bitmaps to not be rendered in VS2010, so some property that WPF is looking for must have been lost.

What are the requirements for WPF to decide to use the bitmaps in the font?

# text said on November 9, 2009 1:32 PM:

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.

Erik – I’ll ask around to get an answer for you.

# Sore Eyes said on November 11, 2009 4:04 AM:

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

# text said on November 11, 2009 9:38 AM:

Sore Eyes - If you send me an email with details about your machine configuration I'd be glad to try look into your issue.

# Sore Eyes Also said on November 12, 2009 1:31 PM:

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.

# text said on November 13, 2009 11:32 AM:

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.

# Erik Olofsson said on November 14, 2009 8:27 AM:

So what you are saying is that you hard-coded some fonts to use the embedded bitmaps?

From my testing it cannot be hard-coded on the font name, so some kind of checksum?

I don't need a API to force embedded bitmaps, I want to craft a font where the bitmaps are used automatically.

I guess I will have to resign myself to reverse-engineering it in the end, maybe even patch the assembly.

# Iivari Mokelainen said on November 16, 2009 9:27 AM:

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?

http://mokelainen.com/blog/post.aspx?id=31

I hope the text rendering engine in beta 2 isn't final(?)...

# text said on November 18, 2009 12:46 PM:

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.

Leave a Comment

(required) 
(optional)
(required) 

  
Enter Code Here: Required
Page view tracker