通过

Quick Tour of WPF Text Architecture

  • 项目

WPF Text

Hi, my name is Worachai Chaoweeraprasit (or “Chai” for short – I assure you, it doesn’t mean “tea” in my native tongue). I’m the development lead of the WPF Text team. We are the group of people who makes text work in WPF. When you’re reading WPF text, you’re staring at our code, and we thank you for keeping us employed! I would like to use my first post to briefly go around the domain of problems we are solving in WPF, so future posts could probably expand a bit more on ‘how’ we solve each problem along the way and how text really works in the platform. Unlike the earlier posts from Chris and Norris, this one is going to be a bit boring since I don’t have cool XAML snippet for you to play with; although I still have a colorful block diagram for your viewing pleasure toward the end, to say the least.

Overview of Problem Domain and Layering of Text Processing

The problem of text processing spans four main areas – paragraph, line, character, and glyph processing.

The problem of paragraph processing is around how to produce a set of text lines to form a paragraph of text. A paragraph may fill a rectangular empty space as in simple document or most UI text, or within an irregular shape space like when it is desired to flow text around figure within the document body. Paragraph may also stack the lines either horizontally or vertically to the left or to the right depending on the dominant writing system of the document. This is also the area in which support for text editing lies.

It is sometimes difficult to choose the right set of lines to form a good looking paragraph, especially when such paragraph is fully justified within a narrow column. The task of picking an appropriate set of line-breaks along with expansion or compression amount needed for the text within the lines is referred to as the calculation of the optimal paragraph – the idea originally conceived by Don Knuth several decades ago.

The problem of line processing is around how to break continuous stream of text into lines – either by following the standard line-breaking rules or using natural language services such as hyphenation or lexicon-based word-breaking algorithm. It encompasses the problem of modern typesetting requirement such as formatting, bulleting, tab-stops, alignment, tracking and justification; advanced features of various stylistic and typographic requirements such as drop-caps, ligature, and kerning; an emerging area such as the visual build-up of mathematical formulae; and international desktop publishing requirement such as Ruby text and character grid in East Asian publication.

The line processing layer represents a long list of complicated requirements that governs the process of creating high quality electronic document in the modern world. The document preparation program that targets high quality publication generally has the highest demand and expectation in this area; less so for the document viewing program which largely depends on the viewing experience on the targeted form factor.

The character processing problem is about how to transform a sequence of characters into the final glyph representation according to the rendering rule of the underlying writing system. The complexity of the problem lies on the requirement of each writing system supported by the platform. For example, proper vertical Japanese text requires classification of character orientation; right-to-left script such as Arabic requires directional reordering of characters; and Indic script requires contextual analysis of syllable.

The glyph processing problem represents how to extract glyph information within the font, the rasterization of glyph into graphic primitives before rendering it on the targeted display device. The main challenge in this area is the integration of the glyph rendering infrastructure with the underlying graphic and printing subsystem. It represents the problem of how to efficiently compute and store the rasterized glyph data and how to make the appearance of glyph legible on the targeted device. ClearType is a well-known technology that exists to solve glyph rendering problem in this layer. The persistence of the document image format such as XPS also gives rise to the problem of how to semantically associate the final glyph representation to the original text content that produces the glyphs. The following diagram illustrates text layers and the currently available WPF API associates with each layer. We’ll drill into each of this area in the subsequent posts.

 

Comments