On Mon, Dec 1, 2008 at 9:39 PM, Andreas Delmelle < [EMAIL PROTECTED]> wrote:
> On 01 Dec 2008, at 17:11, Sebastien wrote: > > 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... > What about a mechanism which squeeze all the unresolved page-number-citation dummy space at the end of the processing ? I didn't really look into FOP's code so it might very well be a stupid idea and/or an impossible thing to do... I just think that since FOP is obviously able to replace a forward reference when it encounters it, it might be able to replace/squeeze an unresolved reference as well. But again, i'm surely missing some internal details... > > >> 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. I'm not sure i understood your solution. How would you check that ? (ok, i saw your second mail, i understand now ;) ) Actually i named my FO ids with a convenient name which is "[chapter]_[number]" (eg: actions_52) so i might be able to get a list of chapters which are generated from my application. Then i would split the ref-id with the '_' delimiter and compare the first part with the list of generated chapters and decide whether to add the page-number-citation or not... But considering all the links in the document, doing a string split + an array search + a test for each and every one of them seems like a real pain and i would hate to do that. Anyways, if i'm stuck with this problem, this will be the way to go i guess... Thanks for your answers anyways ;) Seb
