You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by Apache Wiki <wi...@apache.org> on 2008/07/18 23:43:39 UTC
[Xmlgraphics-fop Wiki] Update of "FormattingObjectsForIndexing" by
AndreasDelmelle
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The following page has been changed by AndreasDelmelle:
http://wiki.apache.org/xmlgraphics-fop/FormattingObjectsForIndexing
New page:
= 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"])
The new properties and objects, for which support needs to be added, in descending order of priority.
== New properties ==
=== index-key ===
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 {id}s 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)
=== ref-index-key ===
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.
=== page-number-treatment ===
Would be a nice bonus for PDF output.
== New objects ==
=== fo:page-number-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:page-number-citation-list-separator / fo:page-number-citation-range-separator ===
TBD
=== fo:index-page-number-prefix / fo:index-page-number-suffix ===
TBD
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org