On 01 Dec 2008, at 17:11, Sebastien wrote:
Hi
<snip />
The behaviour that i was expecting was to have empty brackets []
when the ID couldn't be resolved. Instead, i got empty brackets but
with a large space between them [ ].
After a quick look at the code, i saw that page-number-citation
allocates a space corresponding to the string "MMM" if the ID can't
be immediately resolved.
Right. A sort of pessimistic guess. If you're in luck, and the page-
number is resolved before the actual breaks for the part in question
are determined, then this will lead to nice results (= most cases,
since either the link points forwards and the reserved space is more
than enough to fit the actual text, or the link points backwards,
which avoids the generation of the dummy element altogether; once the
page-count grows too large, there might also be undesired side-
effects, IIC).
My FOP understanding is quite limited so i can't understand how FOP
manages to shrink the space previously allocated when it succeeds in
resolving the ID and why it leaves this MMM-space when it fails to
resolve the ID.
So I have two questions:
1) Is there a way to squeeze that space in case of unresolved ID ?
I don't want to hack the code and replace the "MMM" string by a "|"
string for instance, it's ugly and it will surely lead to severe
mistakes in the layout. Is it difficult to implement such a
behaviour ? I'm guessing that if this hasn't been implemented yet it
must be because of some tricky implications and/or issues ?
One could try go into the direction of avoiding the addition of the
area if the link is unresolved. The tricky part is that it's possible
the dummy area is added, and replaced later, so you have no guarantee,
unless you know in advance whether the ID will occur on a later page
in the document...
2) I can bear not to have any page-number-citation at all in case
of unresolved ID but in this case, i will need to know when my ID
can be resolved and when it can't. It leads to some xsl-testing (i
guess) and i don't think an XSLT processor can be aware of such
things... But i may be wrong and perhaps this cool feature exists ?
Well, there is a possibility... Assuming that there is some element-
or attribute-value in the XML source that determines the value of the
ref-id/id pair, then theoretically, it should be possible to check, at
the time the page-number-citation node is generated, whether 'myId' in
your example, will appear anywhere in the result document. If not,
then you can simply skip generation of the element.
As I see it, FOP knows no more about that than you can find out with
the help of your XSLT processor. In some of the most common cases, FOP
never sees the document in its entirety, so it is not able to
determine whether the id will or will not be resolved, eventually. It
can tell you, at a given point, whether a FO with the given id already
exists. If it does not, then there's no way to guarantee that it will
not turn up further in the stream, I'm afraid... unless by having
looked at the entire source-document (which, strictly speaking, the
XSLT processor has, albeit before it was transformed into FO)
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
