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