J.Pietschmann wrote:
Maybe I'm wrong in trying to do so, but I'd like to handle both
formatting objects in the same way.
If page numbers can be resolved to strings early, it should be
done. All the hassle for space readjusting, and perhaps reflowing
content, should be reserved for forward references, if only for
performance reasons.
Sorry, my last message was not very clear (and / or I misunderstood your
comments).
The point is that the "real" page numbers are not known until the
addAreas() phase, when pages are actually created.
The Knuth-style page breaking algorithm gets a representation of a whole
page-sequence (or part of it, if there are break conditions) and then
computes all the page breaks at once: so, the fo:page-numbers comprised in
that page-sequence cannot know in which page they will be placed, and the
line breaking is necessarily performed using elements whose width could be
just a guess.
What I meant when I said that both page-number and page-number-citation
should be handled in the same way was this: during the line breaking their
real value is equally unknown.
Well, to be more precise the value of a page-number is *always* unknown
during line breaking, while a page-number-citation could refer to an
object in a previous page-sequence, so it could be known: in this case the
method PNCLM.get() already returns a TextArea with the "real" value and
its ipd (maybe you were referring to this? this won't be changed at all).
[from the other message]
- sometimes, when a particularly elegant output is needed, it would
really be desirable to have a two-steps algorithm, with line-breaking
performed again once the actual width of each object is known.
Well, it's not for particular elegant output, it's for the
case of having multiple page number citations which point
to five digit page numbers in the same line. Real life examples
include references to page numbers in roman number format, which
easily get into the six character range, and enumerating
references in book indices, where the problem is may be amplified
as an index is usually set in several narrow columns.
Great examples, I did not think of them!
I imagine that, should the index be in a page-sequence preceding the ones
with the content, the line breaking of it could be really ugly, due to the
provisional width of the references.
This example is really interesting: in this case, a re-flowing of the
index pages could not be able to achieve a better output, should it be
performed before the breaking of the page-sequence with the content; and
it could be avoided just deferring the breaking of this page-sequence, so
that the first breaking can already work using the real values for all
page-number-citations.
If we see each page-sequence as a node, and a page-number-citation as a
directed edge from one node (the target page-sequence) to another one (the
page-sequence containing the page-number-citation), this is a well-known
problem: the topological sorting of a graph.
If the graph is acyclic then there is a sorting of its nodes such that for
each edge going from a node A to a node B, A precedes B in the sorting
order; i.e., the page-sequences could be ordered so that each one is
flowed when all its page-number-references are already known.
Very interesting indeed ... as soon as I finish working on the
line-adjusting I'll spend some more thought on this ...
(sorry for the long message!)
Regards
Luca
