What Is XSL-FO
by G. Ken Holman
|
Pages: 1, 2, 3, 4, 5, 6, 7
2.2 Processing model
2.2.1 Processing model of formatting
The Recommendation describes the processing model for XSLFO as a series of formal steps in the derivation of the content to be rendered from the instance expressing the intent of formatting, as depicted in Figure 2.1. The Recommendation does not cover the creation of the XSLFO instance, nor the detailed semantics of rendering, but focuses entirely on how to get from the former to the latter.
 |
|
|
| Note 5: |
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 text 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 result XSLFO without instantiating the result as markup characters. However, if the information is presented to a 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. It is the way the designer expresses the interaction of the documented semantics described in the XSLFO 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 whitespace-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 (expressions of the result that are expressed in XML but not in the XSLFO vocabulary, e.g.: a Scalable Vector Graphics (SVG) fragment), and any objects not from the XSLFO 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 corresponding property specification. Some traits that are not inherited by default can have their value inherited by the explicit inherit property value.
Once all traits that are applicable to all formatting objects are determined, all traits not applicable to each object are removed. At this point the information is comprised of all objects that are used to create areas and each object has all the traits and only the traits that are applicable to them.
The Refined Formatting Object Tree is interpreted into the Area Tree that is comprised of areas and traits. 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 the 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 can be arbitrarily inferred by the rendering agent, such as font or volume. This allowance leads to differing renderings by different tools when an XSLFO 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 XSLFO 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 just wanting to write stylesheets. Fortunately, simple things can be done simply once you get around the necessary verbosity of the Recommendation document.
This is a prose version of an excerpt from an edited version of the book
"Practical
Formatting Using XSLFO"
(First Edition ISBN 1-894049-07-1 at the time of this writing)
published by
Crane
Softwrights Ltd., written by
G. Ken Holman.
Copyright © Crane Softwrights Ltd.
