3.2 Processing model

The Recommendation describes the processing model for XSL-FO as a series of formal steps in the derivation of the areas of content to be rendered from the instance expressing the intent of formatting, as depicted in Figure 3-1. The Recommendation does not cover the creation of the XSL-FO instance, nor the detailed semantics of rendering, but focuses entirely on how to get from the former to the latter (note the thicker arrows in the diagram at the beginning and end of the formatting process).

Figure 3-1. XSL processing model flow summary

Note:

Although the processing model is described in the Recommendation using constructs and procedural steps following a well-defined sequence, there is no obligation on a vendor that a particular implementation perform the steps as documented. The only obligation on a formatter is that it produce the rendered result as if it were implemented according to the steps described in the text.

This nuance is important to vendors in that it allows them to implement any algorithm producing equivalent results, without constraining the innovation or flexibility to accomplish the results using any algorithm they wish.

One ramification of this flexibility is that none of the intermediate results described in the processing model can be standardized or be required of a particular implementation. Conformance testing would be far simpler if there were a serialization of the abstract result of the interpretation of the formatting intent, without needing to interpret a rendered result as having successfully met the criteria.

First, the instance of elements, attributes, and data becomes a node tree of abstract nodes representing these constructs for processing. It is possible that this node tree is passed directly from the result of transforming some source XML into resulting XSL-FO without instantiating the result as markup characters. However, if the information is presented to the formatter as an instance of markup characters , this must be interpreted into a node tree suitable for the formatter to work with.

This node tree of elements, attributes, and text represents the expression of the intent of what the designer desires in the rendered result. This is called the Instance Tree and includes all of the content, including references to external foreign objects not expressible in XML, that is to appear in the target medium. The instance is the mechanism used by the designer to express the information to be presented using the desired semantics as described in the XSL-FO Recommendation.

The Instance Tree is interpreted into the Formatting Object Tree that is comprised entirely of formatting objects and their properties. This requires the (abstract) breaking of text nodes into sequences of character formatting objects, and the creation of properties from attributes.

Note that certain white-space -only text nodes of the Instance Tree are irrelevant to the formatting process and do not create text nodes in the Formatting Object Tree. Also removed for later access by the formatter or rendering agent are in-stream foreign objects ( expressed in XML but not in the XSL-FO vocabulary, e.g. Scalable Vector Graphics (SVG) fragments ), and any objects not from the XSL-FO namespace that are used in the declarations formatting object.

The Formatting Object Tree is interpreted into the Refined Formatting Object Tree that is comprised of objects and traits. Properties can specify two kinds of traits: formatting traits (e.g. size and position) or rendering traits (e.g. style and appearance). Some property specifications are shorthand expressions that encompass a number of separate trait specifications and their values.

Computed property expression values are evaluated and the resulting values assigned to the traits. For example, a property value of 2em when the current font size is 20pt produces a trait value of 40pt .

Inheritance plays an important role in trait derivation. Some traits are derived from the closest ancestral specification of the corresponding property. Some traits that are not inherited by default can have their value inherited by using the explicit inherit property value.

Once all traits that are applicable to all formatting objects are determined, traits not applicable to each object are removed. At this point the information is comprised of all the objects that are used to create areas, and each object has all the traits and only the traits that are applicable to it.

The Refined Formatting Object Tree is interpreted into the Area Tree that is comprised of areas and traits, according to the semantics of the objects. A given object may create areas at different branches of the Area Tree. Most objects produce exactly one area, and some objects do not produce any areas.

Each area has a geometric position, z-layer position, content, background, padding, and borders. Areas are nested in a tree within ancestral areas up to the highest (and largest) area which is the page area.

Page areas are the children of the root node in the Area Tree. Page areas are ordered by their position in the Area Tree, but they are not geometrically related to each other in any way.

The rendering agent effects the impartation of the areas in the Area Tree according to the medium. The Recommendation gives guidelines on the rendering of areas in either visual or aural media. Some missing trait values, such as font or volume, can be arbitrarily inferred by the rendering agent. This allowance leads to differing renderings by different tools in cases when an XSL-FO instance does not express the missing trait values.

The Recommendation document is written to direct a formatter implementer in carrying out the requirements of interpreting the formatting intent. Certain traits are boolean values targeted solely to the implementer and reflecting an area's role or relative order to other areas. These traits are not specifiable in the XSL-FO instance but are indicated in the Recommendation to make implementation easier.

The rigor of the Recommendation language is necessary in order to ensure proper interpretation of finely- tuned typographical nuances . This makes the Recommendation difficult to read for many people who just want to write stylesheets. Fortunately, simple things can be done simply, once you get around the necessary verbosity of the Recommendation document.