The excerpt I’d like to show you comes from chapter 17 of the book and introduces the new WPF concept of Flow documents. Broadly, WPF seperates your docs into two types type-set documents for printing – fixed documents – and dynamic documents designed for viewing on a computer – flow documents.
I’ll let Matt take up the story…
Caveat: This excerpt’s not finished yet, it still needs another round of technical review, copy-edit and a few other bells and whistles before it’s ready for print. Also, we’re still working on the best way to convert them into HTML, so it’s a little rough around the edges. You’ll have to forgive any errors – the system will get a lot better very soon.
WPF separates documents into two broad categories:
- Fixed documents. These are typeset, print-ready documents. The positioning of all content is fixed (for example, the way text is wrapped over multiple lines and hyphenated can’t change). Although you might choose to read a fixed document on a computer monitor, fixed documents are intended for print output. Conceptually, they’re equivalent to Adobe PDF files, and they’re represented in WPF by the Microsoft competitor XPS (XML Paper Specification). You’ll learn about fixed documents in Chapter 18.
- Flow documents. These are documents that are designed for viewing on a computer. Like fixed documents, flow documents support rich layout. However, WPF can optimize a flow document based on the way you want to view it. It can lay out the content dynamically, based on details like the size of the view window, the display resolution, and so on. Conceptually, flow documents are used for many of the same reasons as HTML documents, but they have more advanced text layout features.
Although flow documents are obviously more important from an application-building point of view, fixed documents are important for documents that need to be printed without alteration (like forms).
WPF provides support for both types of documents using different containers. The DocumentViewer allows you to show fixed documents in a WPF window. The FlowDocumentReader, FlowDocumentPageViewer, and FlowDocumentScrollViewer give you different ways to look at flow documents. All of these containers are read-only. However, WPF includes APIs for creating fixed documents programmatically, and you can use the RichTextBox to allow the user to edit flow content.
In this chapter, you’ll consider flow documents in detail. You’ll learn about fixed documents in Chapter 18.
The Need for Flow Documents
In a flow document, the content adapts itself to fit the container. Flow content is ideal for on-screen viewing. In fact, it avoids many of the pitfalls of HTML.
Ordinary HTML content uses flow layout to fill the browser window. (This is the same way WPF organizes elements if you use a WrapPanel.) Although this approach is very flexible, it only gives a good result for a small range of window sizes. If you maximize a window on a high-resolution monitor (or, even worse, a widescreen display), you’ll end up with long lines that are extremely difficult to read.
Many websites avoid this problem by using some sort of fixed layout that forces content to fit a narrow column. (In WPF, you can create this sort of design by placing your content in a column inside a Grid container, and setting the ColumnDefinition.MaxWidth property.) This prevents the readability problem, but it results in a fair bit of wasted screen space in large windows.
Flow document content in WPF improves upon these current-day approaches by incorporating better pagination, multi-column display, sophisticated hyphenation and text flow algorithms, and user-adjustable viewing preferences. The end result is that WPF gives the user a much better experience when reading large amounts of content.
The Flow Elements
You build a WPF flow document using a combination of flow elements. Flow elements have an important difference from the elements you’ve seen so far. They don’t inherit from the familiar UIElement and FrameworkElement classes. Instead, they form an entirely separate branch of classes that derive from ContentElement and FrameworkContentElement.
The content element classes are simpler than the non-content element classes that you’ve seen throughout this book. However, content elements support a similar set of basic events, including events for keyboard and mouse handling, drag-and-drop operations, tooltip display, and initialization. The key difference between content and non-content elements is that content elements do not handle their own rendering. Instead, they require a container that can render all its content elements. This deferred rendering allows the container to introduce various optimizations. For example, it allows the container to choose the best way to wrap lines of text in a paragraph, even though a paragraph is a single element.
Note:Content elements can accept focus, but ordinarily they don’t (because the Focusable property is set to false by default). You can make a content element focusable by setting Focusable to true on individual elements, by using an element type style that changes a whole group of elements, or by deriving your own custom element that sets Focusable to true. The Hyperlink is an example of a content element that sets its Focusable property to true.
There are two key branches of content elements:
- Block elements. These elements can be used to group other content elements. For example, a Paragraph is a block element. It can hold text that’s formatted in various different ways. Each section of separately formatted text is a distinct element in the paragraph/
- Inline elements. These elements are nested inside a block element (or another inline element). For example, the Run element wraps a bit of text, which can then be nested in a Paragraph element.
The content model allows multiple layers of nesting. For example, you can place a Bold element inside an Underline element to create text that’s both bold and underlined. Similarly, you might create a Section element that wraps together multiple Paragraph elements, each of which contains a variety of inline elements with the actual text content. All of these elements are defined in the System.Windows.Documents namespace.
Tip:If you’re familiar with HTML, this model will seem more than a little familiar. WPF adopts many of the same conventions (such as the distinction between block and inline elements).
