xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas L. Delmelle" <andreas.delme...@telenet.be>
Subject Re: FormattingObjectsForIndexing - intermediate format or extension?
Date Mon, 16 May 2011 19:40:05 GMT
On 04 May 2011, at 22:57, Giuseppe Briotti wrote:

Hi Guiseppe

Apologies for the delayed response. 

> Hi all, I'm really interested on merge-pages-across-index-key-references / merge-sequential-page-numbers
/ merge-ranges-across-index-key-references.

You are addressing a feature that would greatly improve usability and basic compliance. It
has been requested a couple of times now, but not enough to lead to action, unfortunately...

> As per http://wiki.apache.org/xmlgraphics-fop/FormattingObjectsForIndexing it seems that
they are:

I had started to compile some basic ideas on that page, in an attempt to separate out the
core functionality, i.e. the components that *definitely* need to be added to make even the
smallest possible example work. 

> 1) "Rather straightforward properties to implement on the FO tree side (simple enums)."
> 2) "Of lesser importance for the base implementation."
> 3) "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. "
> The point (1) suggests that this is not so complicated.

Well, it is ultimately still a challenge, as it is so comprehensive (= changes will affect
multiple packages, requiring an understanding of different areas of the code and how they
work together). 

> The point (2) suggests that this feature is not so close to complete.

Apart from having added the symbolic literals in org.apache.fop.fo.Constants --for the new
properties, property enum values and FOs-- nothing is in place yet. 
Some properties can be quite straightforwardly implemented, if they are simple enum values.
(see also: http://wiki.apache.org/xmlgraphics-fop/PropertyHandling)

However, the "merge-*" properties by themselves are useless. On the other hand, "(ref-)index-key"
both are *required* for a minimal implementation. 

> The point (3) suggests that there is some kind of problem to correctly outputs a sequence
of page numbers.

Not really a problem. As pointed out above, it requires understanding the FO tree part /and/
the layout engine. In that respect, the reference to the (ref-)id property-pair is, IMHO,
rather crucial. Make sure to study closer how these are processed/passed, and you will get
a lot closer to an implementation for (ref-)index-key.

Once a base implementation is in place to be able to produce a separated list of all page-numbers,
the remaining non-essential stuff --whether to merge sequential page-numbers-- would be trivial
to add. 

As for new FO objects, I think the first pair is all we need to get a proof-of-concept for
such a base implementation working.
The second pair, related to index-ranges, only becomes relevant in the context of merge-*,
so is considered non-essential.
The TBDs are really only cosmetics, although we might want to take care to make the separator
replaceable (i.e. not a hard-coded comma or semi-colon or some such...)

> I know that I can use a "double-pass" approach and act on Intermediate Format. I can
figure out if it possible to obtain the same result by a new extension or implementing such
feature in the FOP code. 
> I would like to try :-)
> Any suggestion?

If a standard feature covers your requirements, but is not implemented, then obviously from
our perspective, you are very much encouraged to try and add this. :-)

If some the above does not immediately make sense or raises further questions, just chime
back in here.



View raw message