Thank you for pointing out that keep-together success was spurious. That's saved me a lot of time.
To set up something robust, I need to be able to calculate the lengths of the strings, using the text metrics of the font, and decide on the approach to use for leaders accordingly. That's a bit hairy-chested for XSL, and it sounds like I'm into the realm of procedural programming. Your philosophical note is very interesting. Shouldn't over-constraining be forbidden? It sound like the FO specification leaves a lot of room for interpretation. -----Original Message----- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: 13 March 2003 20:27 To: [EMAIL PROTECTED] Subject: Re: Line-wrap in fo:leader Rob Staveley (Tom) wrote: > Unfortunately the two leaders wind up on the same line, if blah is > less than 50% long and the ref,ref text goes on the following line > (see index.13.xsl). > At the XSLT level, you can try to estimate the width of the blah and ref on one entry: string-length($stuff)*$font-size If width($blah)+$minimal-leader-length+width($ref) > $allocated-width increase leader-length.optimum to $allocated-width and insert the second leader with default length set. > I've tried to use keep-together with some success Spurious success, I'd bet. Keeps don't have no effect whatsoever on line breaking, unfortunately. I should know, I had already bad dreams featuring the current line breaking code. In fact, the keep properties are not even delivered anywhere near the line breaking code. > Is this a Fop issue or am I expecting to achieve something from FO > which is beyond its design? Tricky question: it should be possible to get it to work with keep-with-next.within-line, for example: <fo:block text-align="justify" text-align-last="justify"> <fo:inline keep-with-next.within-line="always">blah</fo:inline><fo:leader leader-pattern="dots" leader-length.minimum="6pt" leader-length.optimum="100%" keep-with-next.within-line="5"/><fo:leader leader-pattern="dots" leader-length.optimum="100%" keep-with-next.within-line="always"/>ref</fo:block> This is overconstrained: The processor is advised to both keep everything within a line but expand the leaders to the full line width. OTOH the leader length can be decreased to 6pt for the first and to 0 for the secons leader, therefore if blah+(6pt leader)+ref fits on the line, nothing special happens, but if not the processor can insert a break somewhere, preferably beween the leaders, which then expand each by itself to fill all available space. However this isn't all that well defined in the spec, some processors could do something else, like simply overflowing the line. J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
