On Thursday 19 July 2007 08:39, Andreas L Delmelle wrote:
> 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?)
>

Sorry Andreas but I still don't get it. We have this test case

<fo:block>This is <fo:inline keep-together.within-
line="always">Blah blah blah blah!</fo:inline></fo:block>

which (attempts) to test that keep-together.within-line="always" 
specified on an fo:inline does work correctly. So this property is not 
ignored as far as I can tell. What am I missing?


> > <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.
>
This is worth a shot. I tried before using different penalty values to 
achieve specific effects and it failed miserably. But may be I did 
something wrong. For example in one test I significantly increased the 
penalty associated with a hyphen to see if I can get it to 'hyphenate 
less' and it seemed to have zero effect. Any way trying to do something 
like that would exceed significantly my admittedly very limited time 
available to spend on fop.

>
> Cheers
>
> Andreas

Cheers

Manuel

Reply via email to