On Jul 19, 2007, at 01:31, Manuel Mall wrote:
<snip />
I don't quite understand what you are trying to say here. The test
case
in question checks the use of keep-together.within-line="always" in
the
context of <fo:block, <fo:inline and <fo:marker.
Nope. For the sake of completeness, this is the one and only page-
sequence, including diffs:
<fo:page-sequence master-reference="simple">
- <fo:flow flow-name="xsl-region-body" hyphenate="true">
+ <fo:flow flow-name="xsl-region-body">
<fo:block-container width="100pt" background-color="yellow">
- <fo:block>This is <fo:inline keep-together.within-
line="always">BLah-blah-blah-blah!</fo:inline></fo:block>
- <fo:block>This is <fo:inline keep-together.within-
line="always">Blah-blah-blah-blah!</fo:inline></fo:block>
- <fo:block>This is <fo:inline>Blah blah blah blah!</
fo:inline></fo:block>
+ <fo:block keep-together.within-line="always">This is
Blah blah blah blah!</fo:block>
<fo:block>This is <fo:inline keep-together.within-
line="always">Blah blah blah blah!</fo:inline></fo:block>
+ <fo:block>This is <fo:wrapper keep-together.within-
line="always">Blah blah blah blah!</fo:wrapper></fo:block>
</fo:block-container>
</fo:flow>
</fo:page-sequence>
Have I missed an important use case?
Question seems to be whether you forgot an important /test/ case in
the commit... ;-)
Looking closer, specified properties on an fo:inline are still
ignored after applying your patch (which I took to be the reason for
your removing the fo:inlines or replacing them with fo:wrappers?)
<snip />
Regarding integer keeps I have no real idea how to do it. Can we
express
integer keep conditions correctly using our Knuth sequences for
example
by adjusting the penalty values as you suggest?
I think so.
Consider:
<fo:block>
Some text with "auto" keep-constraint
<fo:inline keep-together.within-line="100">
Some text with a keep.within-line constraint of "100"
<fo:inline keep-together.within-line="500">
keep.within-line="500"
</fo:inline>
Some more text in the first nested inline
</fo:inline>
More text after the first nested inline.
</fo:block>
In the code we get something like:
BlockLM.getNextKnuthElements()
-> LineLM.collectInlineKnuthElements()
-> TextLM.getNextKnuthElements()
-> InlineLM.getNextKnuthElements()
-> TextLM.getNextKnuthElements() [a]
-> InlineLM.getNextKnuthElements() [b]
-> TextLM.getNextKnuthElements() [c]
-> TextLM.getNextKnuthElements()
...
If, at point [a], the first nested inline would prefix the returned
sequence with a penalty of 50, and pass a value of 100 down to its
descendant TextLM to use for penalties to insert between its
elements. Then, before processing the second inline at [b], insert a
penalty of 100, while the second nested InlineLM surrounds its
sequence by two penalties of 250 and passes a value of 500 down its
TextLM [c].
This should steer the line-breaking algorithm in the right direction
to satisfy all keep constraints, IIC. The only big difference
compared to an auto keep-constraint, if I judge correctly, would then
be that we would somehow have to use penalties to represent all legal
break-opportunities. Instead of glues being considered as feasible
breakpoints, they would always be preceded by a zero-width penalty
having a value corresponding to the keep-constraint governing the
base FO.
Cheers
Andreas
