Don't know how I got the names wrong, but somehow...
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 3:||Line 3:|
|This page is set up to try to give an overview of what would be involved to support XSL-FO 1.1 indexing features (see: [http://www.w3.org/TR/xsl/#d0e13293 "Formatting Objects for Indexing"])||This page is set up to try to give an overview of what would be involved to support XSL-FO 1.1 indexing features (see: [[http://www.w3.org/TR/xsl/#d0e13293|"Formatting Objects for Indexing"]])|
Formatting Objects for Indexing
This page is set up to try to give an overview of what would be involved to support XSL-FO 1.1 indexing features (see: "Formatting Objects for Indexing")
The new properties and objects, for which support needs to be added, in descending order of priority.
More or less the opposite of the id property, which uniquely identifies a node in the document, the value of the index-key property will typically be identical for several FOs. Apart from this difference, the established mechanism for id-resolution can be applied for keeping track of the index-key occurrences as well. This needs closer investigation. The two can probably work very closely together.
In light of this consideration, apart from using the same pattern as id for storing the property value as a reference in the FO itself, the option of instead creating a mapping from index-key to a set of ids at parse-time may be interesting to look at (or, vice versa, instead of storing the ids in a Set --which is already the case, since FOP needs to verify the uniqueness-- store a mapping of id and index-key)
Depending on this choice, it may be necessary to add a special PropertyMaker subclass. This will have an impact on how the object will be processed further on. If the property is stored on the FObj, then separate checks/handling need to be added for it, which may otherwise be caught generically (as in: every time an id is added to a page, see if an index-key-reference needs updating)
The counterpart of index-key, as ref-id is for id. Necessary for a base implementation, as this will be the property that is used to reference the FOs for which to generate the list of citations.
merge-pages-across-index-key-references / merge-sequential-page-numbers / merge-ranges-across-index-key-references
Rather straightforward properties to implement on the FO tree side (simple enums). Of lesser importance for the base implementation. If FOP can get to the point where it correctly outputs a sequence of page-numbers for a given index-key, these will be relatively easy features to add.
Would be a nice bonus for PDF output.
fo:index-page-citation-list / fo:index-key-reference
The base objects. The most minimal conceivable example needs at least those two objects, and some other FOs with a specified index-key.
fo:index-range-begin / fo:index-range-end
A second step. Initial support could already be provided with a default range spanning the whole document. Implementing index-ranges requires additional validation rules (+ maybe updating the id/index-key mappings, if any are added) in the FO tree.
fo:index-page-citation-list-separator / fo:index-page-citation-range-separator
fo:index-page-number-prefix / fo:index-page-number-suffix