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

Reply via email to