WPF Text Blog : text rendering

WPF Text Measurement Units

text — Fri, 11 Dec 2009 23:48:00 GMT

The WPF text team has seen some people get confused about what units WPF uses when measuring text. Samer, a developer on the WPF text team, and I have created this post to try and shed some light on this subject. The first part of this post is very straight forward, whereas the end will only be useful for those of you who are extensively using WPF text APIs.

General Units

WPF supports multiple units for text measurement. The units that can be used are “px” (device independent pixels), “in" (inches), "cm" (centimeters), "pt" (points). If you do not specify the unit of measurement, WPF defaults to px.

<TextBlock FontSize="24">Hello World</TextBlock>

To force WPF to use a different unit of measurement, just append the unit abbreviation to the FontSize.

<TextBlock FontSize="24pt">Hello World</TextBlock>

Device Independent Pixels & Physical Pixels

In accordance with WPF’s resolution independence, the framework measures objects in device independent pixels. These device independent pixels can have different sizes than physical pixels.

1 device independent pixel = 1/96 inch.

1 physical pixel = 1/DPI (dependent on the system DPI)

Default system settings usually choose a DPI of 96 so these two types of pixels come out to be the same size. If this is not the case, it is easy to convert between the two types of pixels.

physical pixels = DPI/96 * device independent pixels

device independent pixels = 96/DPI * physical pixels

Notice that as the DPI increases, so does the number of physical pixels which compose one device independent pixel. Hence, objects that have their sizes specified in device independent pixels get larger as the system DPI increases.

Points

A point (pt) is also a common unit of measurement for fonts.

1pt = 1/72 inches

Converting between points and device independent pixels is also easy.

pt = 72/96 device independent pixels

device independent pixels = 96/72 pt

Remember objects which are measured in device independent pixels get larger as system DPI increases? This is true for text. Since there is a constant ratio between point sizes/device independent pixels, if the point size of text is held constant while the system DPI is increased, the size of the rendered text will grow.

Uses For Font Units

Aside from knowing how to correctly set FontSize, the above knowledge could be helpful in understanding the values that WPF text APIs, such as FormattedText or TextFormatter, use and return for the different text measurements. The metrics returned from these APIs are in device independent pixel (eg. some properties of GlyphTypeface including Baseline, CapsHeight, XHeight). When interacting with these APIs make sure that you convert to device independent pixels from whatever unit your font is measured in, or visa versa.

- Samer and Chipalo

New WPF 4.0 Features

text — Wed, 24 Jun 2009 20:35:00 GMT

WPF 4.0 Beta1 was released last month. While many exciting features were included in Beat1, there was no work targeting text, flow, or layout. This will all be reversed with WPF Beat2. Below is a brief overview for each of the features included in Beta2 which target text, flow, or layout. I will make subsequent posts giving more detail about each feature, including API details. For now, I just want to let everyone know that great features are coming!

Text clarity improvements

In previous versions of WPF, all text is formatted without specifically accounting for pixel boundaries. This approach provides uniform scalability and ensures that glyph outlines adhere to font specifications. Unfortunately, small text appears blurry when it is rendered across pixel boundaries, and this has affected our customers. In the past, we have only been able to say “we are working on a fix.” Now I can tell you that this is solved in WPF4.0!

As of Beta2, WPF provides developers with the ability to control how text is both formatted and rendered. Text can now be formatted to either strictly adhere to font specifications or fall on pixel boundaries. This new option allows text to be rendered more clearly at the slight expense of glyph shape and position.

The option to set the rendering mode for text (eg, aliased, grayscale, ClearType) is also conveniently exposed. In most situations ClearType is an obvious win; however ClearType can degrade the user experience on CRTs and for people whose eyes are color sensitive. In the past, WPF forced all apps to use ClearType. Now, developers can choose between two additional rendering modes.

A Bindable Run

The inability to bind Run.Text has forced many people to create home brew solutions. In WPF4.0, Run.Text has been converted to a Dependency Property. Run.Text now enjoys most of the benefits that come with this change, such as the ability to be bound, styled, and templated.

One-way binding is fully supported. Unfortunately, we did not have time to implement full support for two-way binding. This scenario is supported if a run is only modified through the property system, but not when the run is modified via a RichTextBox or the text object model.

LayoutRounding

WPF’s layout engine frequently causes subpixel rendering along element boundaries. This can lead to both rendering artifacts and blurry rendering, as antialiasing causes subpixel rendered elements to be displayed over multiple actual pixels. A classic example of this problem is small icons which get blurred because the icon images are placed on subpixel boundaries. Enabling LayoutRounding forces the WPF layout engine to place elements on whole pixel boundaries, thus removing most of the rendering artifacts caused by this problem.

Caret and Selection Brush

The default visual appearance of most objects in WPF can be easily tweaked or completely changed. This provides developers far greater power over the visual look of an application than ever before. Facilitating the creation of highly customized apps has become a major adoption point for WPF. Despite WPF’s extensibility, the color of text selection and carets in text boxes and document viewers remains baked into the framework. WPF now exposes properties to control the brushes used to paint text selection and carets.

-Chipalo

DirectWrite Questions and Answers

text — Tue, 14 Apr 2009 00:57:00 GMT

Hi, my name is Mikhail Leonov, and I’m a Senior Software Development Engineer on the DirectWrite team at Microsoft. I would like to address common user feedback on DirectWrite in a relatively informal ‘simple question – simple answer’ format. Feedback themes were gathered mostly from the user comments on various DirectWrite related blogs. Please feel free to post additional questions in the comments section right after this blog post. Throughout this post, I will assume the reader is familiar with DirectWrite basics. This link provides a good starting point: http://channel9.msdn.com/pdc2008/PC18/.

DirectWrite from the programmer’s point of view

I want to experiment with DirectWrite in my application. How do I start using it?

DirectWrite can be used from native C++ code by including DWrite.h header file and linking to the DWrite.lib library. At the runtime, the application will automatically load DWrite.dll.

To start with, the application needs to call DWriteCreateFactory. The factory pointer returned by DWriteCreateFactory implements IDWriteFactory interface, which can be used to perform actions such as creating DirectWrite font and layout objects.

For more information, please refer to the introductory DirectWrite materials linked in the beginning of this post.

DirectWrite on pre-Windows 7 operating systems

My application needs to work on Vista and XP. Is using DirectWrite an option for me?

DirectWrite technology will ship first with Windows 7. After Windows 7 ships, DirectWrite will be made available for Windows Vista as well. There are no plans today to make DirectWrite available on Windows XP.

Microsoft platforms and applications using DirectWrite

Does Microsoft use DirectWrite in its own products? I installed Windows 7, and I don’t see natural ClearType anywhere on the screen.

DirectWrite is used by the Windows 7 ClearType Text Tuner control panel applet and by the XPS Viewer application. It is worth noting that DirectWrite is a new technology, and it takes time for customers to evaluate their existing text functionality and determine how to take advantage of DirectWrite.

Supported font formats

Does DirectWrite only support TrueType fonts? How about Type 1 fonts or bitmap fonts?

DirectWrite supports font files conformant to the OpenType specification version 1.5, which can be accessed here: http://www.microsoft.com/typography/otspec/default.htm. This support includes OpenType fonts with both TrueType and CFF outlines, and TrueType fonts with embedded bitmaps. Simply speaking, if your font has a TTF, OTF or TTC extension, DirectWrite should support it well.

DirectWrite does not support bitmap or vector .FON font files, and DirectWrite does not support Adobe Type 1 .PFM/.PFB font files.

Installed fonts, local fonts, embedded fonts, per user fonts

My application uses a custom font for certain user interface elements. Do I have to install it on the system in order for DirectWrite to be able to use it?

No, one doesn’t have to install a font in order for DirectWrite to be able to use it. DirectWrite provides full support for font files that are local to an application.

The application that uses DirectWrite needs to register its own IDWriteFontFileLoader interface implementation that manages the association between the font file location and contents. To support local font file enumeration functionality, the application needs to register its own IDWriteFontCollectionLoader interface.

Rendering technologies to use DirectWrite with

Can I use DirectWrite in my GDI+ application? How about using DirectWrite with Direct3D or GDI?

DirectWrite font stack is designed to be independent from any rendering technology, so clients have flexibility to use any existing rendering mechanism in their IDWriteTextRenderer implementation. In addition, DirectWrite is designed to work well with Direct2D rendering components, and Direct2D provides convenient wrappers such as ID2D1RenderTarget::DrawText() for drawing text on D2D surfaces.

DirectWrite itself provides GDI interoperability helpers via IDWriteGdiInterop interface. One can create a DirectWrite font face object that corresponds to a font selected in a GDI HDC and easily replace ExtTextOut(…, ETO_GLYPH_INDEX, …) calls with DirectWrite based glyph run drawing calls without requiring significant changes to the rest of the application code. One can also create a LOGFONT description for a DirectWrite font face object to re-use existing GDI based controls from a DirectWrite based text processing component. On top of that, one can create GDI surfaces that satisfy DirectWrite rendering requirements through IDWriteGdiInterop::CreateBitmapRenderTarget() method, and draw DirectWrite glyph runs on that surface using IDWriteBitmapRenderTarget::DrawGlyphRun() method.

Interoperability with GDI+ can be achieved via GetHdc() and FromHdc() methods provided by the GDI+ Graphics object. The client has a choice of starting with a Graphics object and only switching to HDC methods for DirectWrite interoperability calls, or starting with an HDC obtained from IDWriteBitmapRenderTarget::GetMemoryDC() and switching to Graphics object derived from it. Which of these two approached is the best depends on the application needs.

Applications that render using Direct3D usually need to obtain text in either bitmap or outline form. To get the former, the client can ask DirectWrite to produce alpha textures containing text using IDWriteGlyphRunAnalysis interface. To get the latter, the client can use IDirectWriteFontFace::GetGlyphRunOutline() method to produce a geometry containing text.

Rendering quality

How do I specify text rendering options in DirectWrite? I want to use the new natural ClearType for text paragraphs, while having text in my menus and buttons look like the rest of the operating system.

In your case, two different measuring modes should be used—DWRITE_MEASURING_MODE_NATURAL for text paragraphs, and DWRITE_MEASURING_MODE_GDI_CLASSIC for menu and button text. The measuring mode then gets passed to drawing calls such as ID2D1RenderTarget::DrawText() and DrawGlyphRun() as an input parameter. For clients who create IDWriteTextLayout themselves, DWRITE_MEASURING_MODE_NATURAL corresponds to calling IDWriteFactory::CreateTextLayout(), and DWRITE_MEASURING_MODE_GDI_CLASSIC corresponds to calling IDWriteFactory::CreateGdiCompatibleTextLayout() with useGdiNatural set to FALSE.

Tips for improving your WPF text rendering experience

text — Thu, 19 Oct 2006 00:39:00 GMT

WPF uses the latest version of ClearType to render text. This version of ClearType has a few new features over the standard ClearType used in GDI and WinForms. You can read more about these features here.

We’ve found that a couple simple tips can improve your reading experience:

-Make sure your monitor is set to its native resolution, typically the maximum resolution possible. This can be adjusted through Control Panel-->Display Properties on XP or Control Panel--> Adjust screen resolution on Vista.

-Use the ClearType tuner PowerToy. This adjusts the system's ClearType settings including pixel orientation and Gamma. Though WPF's ClearType engine is separate from GDI and WinForms, WPF still picks up these system wide settings.

-For advanced users who are comfortable playing with regedit, there is one additional WPF ClearType setting that may help improve your experience: you can adjust the color level that WPF ClearType uses for sub-pixel anti-aliasing. At the moment this can only be tuned via registry keys, but we do have future plans to update the ClearType tuner to include this setting in a UI.

To adjust this you will need to create this new reg key:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\<displayName>\

With <displayName> typically being 'DISPLAY1'. You can adjust things independently if you have multiple monitors.

Then create the following DWORD with any value between 0 and 100 (base 10):

ClearTypeLevel

The default value of 100 is the maximum amount of color and provides the greatest utilization of sub-pixels. On LCD panels this is the most optimal setting for the majority of users. If you perceive color fringes or halos around your text at a normal reading distance tune the value lower (You will need to restart any WPF application to see the effects of the change). The value of 0 uses only grayscale anti-aliasing and no color. Note if 'font smoothing' is turned off or set to ‘anti-alias’ on the system level, WPF will automatically render using grayscale anti-aliasing. Due to our pixel independent architecture we cannot render aliased text even if ‘font smoothing’ is turned off completely.

-Chris Han