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 
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 

> 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.




Reply via email to