Next / Previous / Contents / Shipman's homepage

5.3. XSL-FO design: Line formatting

This project turned out to be a lot more work than the author anticipated, even given the challenges of dealing with the enormous feature set of XSL-FO. The author cannot say for sure whether the increased effort was due to problems with the local FO-to-PDF toolchain or his imperfect understanding of the XSL-FO, but two major features that were supposed to be automatic had to be handled by custom code.

Consequently, this program handles the breaking of overly long lines, and the implementation of the --break option, entirely with custom logic.

This custom logic requires that we compute the exact height and width of each column so we can cut the input lines into pieces that fit. In order to solve this problem with full generality, we would need to know what font will be used, and read the font metrics files for that font. That is a nontrivial problem.

However, so long as this application is used only at the TCC, where the FO processor (xep) uses only a single monospaced font (Vera Sans Mono), we can assume the metrics of that font to predict font width. Experimentation shows that this font has a consistent 5:3 ratio of character height to width.

To force verbatim treatment of spaces, the block will need two attributes: white-space-treatment='preserve' and white-space-collapse='false'.

There is one other subtle problem: what to do about unprintable characters, those not in the range from ASCII SP (space) to “~”. Some of them will affect the display:

For other unprintables, the report will display the character's hexadecimal code using two tiny characters in the normal character space. In practice, the tiny font will be half the current font size (rounded down, so in a 9-point font the tiny font will be 4-point).

Two other options affect the layout of the report body: