FO Extension Design Specifications

SourceForge.net Logo

Last revised: 24 Nov 2002 $Revision: 1.4 $


[Home] [Requirements] [Specifications]


Specifications for Solutions to FO Requirements

This section contains specifications for FO extensions designed to satisfy the requirements documented in the FO Extension Requirements document. Specifications are labeled as being either "under discussion", "proposed", or "accepted". Specifications that are "under discussion" are just that: the specification is simply a strawman or set of alternative approaches that are under discussion on the EXSLFO list. Specifications that are "proposed" represent what appears to be a consensus based on the discussion in the EXSLFO list. Proposed specifications are then candicates for acceptance by implementors as stable, useful extensions. Specifications that have been implemented by at least two FO implementations are said to be "accepted".

Accepted extensions are not cast in stone--like any software system, all components are subject to further refinement as our understanding of requirements and constraints change. But acceptance does mean that the community and implementors see enough value and stability in the extension to be willing to commit it to code.


General Requirements Specifications

See General Requirements.

No specifications developed.

Auxiliary data output ("side files") [Under Discussion]

See Auxiliary data output ("side files") requirements.

No specifications developed.

Page-Aware Conditional Processing [Under Discussion]

See Page-Aware Conditional Processing requirements.

No specifications developed.


PDF Requirements Specifications

See PDF Requirements.

Bookmark generation [Under Discussion]

See Bookmark generation requirements.

No specifications developed.

Annotation generation [Under Discussion]

See Annotation generation requirements.

No specifications developed.


Layout Requirements Specifications

See Layout Requirements.

Revision marks [Under Discussion]

See Revision marks requirements.

No specifications developed.

"Table continued" header/footer [Under Discussion]

See "Table continued" header/footer requirements.

No specifications developed.

Index Generation [Under Discussion]

See Index Generation requirements.

Both Antenna House and RenderX provide extensions that attempt to address this requirement. Both solutions are presented here as a starting point for discussion. See these product's documentation for details on these extensions.

The Antenna House solution is to provide an additional property on fo:block to indicate that duplicate page numbers created by page-number-citations within the scope of the block should be suppressed, along with any characters between the first page number and its duplicate.

The RenderX solution is to replace the directly-generated sequences of page-number-citations with an extension element that generates the page number sequence by reference to "key" elements. In normal practice, each index marker in the source document would result in one or more "key" elements with their key values derived from the marker content such that all occurrences of the same index entry text would use the same key value. The "rx:page-index" element then refers to a particular key value and generates an appropriate sequence of page numbers, using the specified list separator and range separator strings. In this approach, the FO processor can create page ranges from consecutive sequences of page numbers within a single reference.

The Antenna House approach is very simple but does not directly satisfy the requirement to create page ranges (although that requirement could be satisfied in the initial generation of the page number citations given appropriate markup in the input document indicating that some set of index markers should result in a page range). The RenderX approach simplifies the task of actually constructing the page number list when the FO is generated. However, the range-construction business logic is all or nothing--it doesn't help if the business rules for the index would not unconditionally collapse consecutive page numbers into ranges, meaning that there does not appear to be a way to create ranges explicitly based on the original index markup and not the coincidence of page number occurrence. It also doesn't provide a way to do things like give different presentation effects to different page numbers within a sequence.