You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Andreas L Delmelle <a_...@pandora.be> on 2007/07/18 20:31:37 UTC
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
On Jul 18, 2007, at 20:06, manuel@apache.org wrote:
Hi Manuel & others
> Author: manuel
> Date: Wed Jul 18 11:06:09 2007
> New Revision: 557347
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=557347
> Log:
> Added support for keep-togther.within-line="always"
Cool to see this implemented so quickly!
On the other hand, I do have a few (non-blocking) comments.
There is no real support for inline-level elements yet, as your
adaptation of the testcase demonstrates: in one case the fo:inline is
removed, in the other it is substituted with an fo:wrapper. IMO, in
the near future, keeps on other inline-level FOs should be
reactivated as well. I was thinking of reactivating the related
properties on fo.flow.InlineLevel...
I had also been thinking in the direction of letting the TextLM deal
with this, but further considerations made me think this was
suboptimal. Although this approach works perfectly for a value of
"always", it could(?) become rather messy when looking at integer-keeps.
My last ideas on the subject went in the direction of letting the
inline-level LM accumulate the regular sequence, and, for a value of
"always", wrap it in a single box. If the keep-constraint is not
absolute, the TextLM's parent could still do something similar for
the individual elements, or something like: surround the entire
sequence by two penalties, and insert penalties in the sequence but
with significantly higher/lower values.
WDYT?
Cheers
Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jul 20, 2007, at 01:17, Manuel Mall wrote:
>> Nothing. I just don't like those being bound to the text either...
>> Why duplicate the font-, alignment- and other info on the FOText
>> descendant? Either there is no need to store them at the higher level
>> at all, or they are always available from the parent so there is no
>> compelling reason to bind them to the FOText as well.
>
> The main reason is that our object hierarchy does not easily allow to
> retrieve that without messy tests instanceof tests and typecasts. If
> you want to re-architect the object hierarchy within the fo tree just
> to avoid the need to bind against FOText, please by my guest.
Well, it has been on my mind to do so, actually, albeit not just to
avoid this binding.
No priority so far. It's working. Never mind if the design is
suboptimal --at least, nobody else seems to mind. :-)
>> <snip />
>> My point exactly.
>>
>
> Good, so why all the fuss about this particular relatively small
> commit
> then?
Hmm, Fuss? :-/ I wasn't making any fuss... Was I?
Cheers
Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Manuel Mall <mm...@arcus.com.au>.
On Friday 20 July 2007 01:11, Andreas L Delmelle wrote:
> On Jul 19, 2007, at 18:45, Manuel Mall wrote:
> >> <snip />
> >> And in doing so, we would eventually end up back where FOP Trunk
> >> started in 2002: a monolithic black box, which becomes harder and
> >> harder to maintain and extend over time.
> >>
> >> That's more the nature of my concern: that we do not fall prey to
> >> bad old habits.
> >
> > I don't get your point in this context. What is different to
> > binding the Font, Alignment, Color, ... properties to FOText to
> > binding the Keep-together property to it?
>
> Nothing. I just don't like those being bound to the text either...
> Why duplicate the font-, alignment- and other info on the FOText
> descendant? Either there is no need to store them at the higher level
> at all, or they are always available from the parent so there is no
> compelling reason to bind them to the FOText as well.
The main reason is that our object hierarchy does not easily allow to
retrieve that without messy tests instanceof tests and typecasts. If
you want to re-architect the object hierarchy within the fo tree just
to avoid the need to bind against FOText, please by my guest.
> Looking back at something like font-selection strategy: the more I
> look at it, the more I agree with the initial suggestion to deal with
> it during the layout-phase. Instead of generating multiple FOText
> instances that are tied to different fonts, the CommonFont
> information should precisely be moved away from the FOText.
>
This has more to do with CommonFont not being designed to handle list of
fonts then its binding to FOText. If the logic for font selection is
better placed in the TextLM we just need to give it the required data
to be able to do so. If CommonFont can't do it we either need to
redesign CommonFont or have another object that models font lists.
> > Same principle, nothing new introduced here that wasn't there
> > before.
>
> My point exactly.
>
Good, so why all the fuss about this particular relatively small commit
then?
<snip/>
> Cheers
>
> Andreas
Manuel
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jul 19, 2007, at 18:45, Manuel Mall wrote:
>> <snip />
>> And in doing so, we would eventually end up back where FOP Trunk
>> started in 2002: a monolithic black box, which becomes harder and
>> harder to maintain and extend over time.
>>
>> That's more the nature of my concern: that we do not fall prey to bad
>> old habits.
>>
> I don't get your point in this context. What is different to binding
> the Font, Alignment, Color, ... properties to FOText to binding the
> Keep-together property to it?
Nothing. I just don't like those being bound to the text either...
Why duplicate the font-, alignment- and other info on the FOText
descendant? Either there is no need to store them at the higher level
at all, or they are always available from the parent so there is no
compelling reason to bind them to the FOText as well.
Looking back at something like font-selection strategy: the more I
look at it, the more I agree with the initial suggestion to deal with
it during the layout-phase. Instead of generating multiple FOText
instances that are tied to different fonts, the CommonFont
information should precisely be moved away from the FOText.
> Same principle, nothing new introduced here that wasn't there before.
My point exactly.
> FOText is the generic descendant of anything that can have text
> content
> being it a block, an inline, a wrapper, ....
One could answer here that FOText corresponds to PCDATA in the source
document, and PCDATA has no properties.
FOText being indeed the 'generic descendant' results in there being
roughly as many of those in any page-sequence as there are blocks,
inlines, wrappers... put together (most likely even more: two or
three FOTexts for a block with nested inlines or wrappers is not
uncommon).
Given that their ancestors already contain the exact same CommonFont
info, I see no good reason at all to propagate all that info to FOText.
> I admit I am lost in your reasoning.
Don't worry, I get that a lot. :-)
Cheers
Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Manuel Mall <ma...@apache.org>.
On Friday 20 July 2007 00:29, Andreas L Delmelle wrote:
> On Jul 19, 2007, at 18:10, Andreas L Delmelle wrote:
> > <snip />
> >
> >> There is not need for the inline obj to bind to the properties as
> >> its LM
> >> does not use them.
> >> The bind is done only for the FOText as it is the
> >> only object whose LM is currently making processing decisions on
> >> it.
> >
> > See? And why is that? Because you decided to implement it that
> > way. :-)
> >
> > Before your patch the property was not present on FOText, and was
> > not dealt with by the TextLM, but now it is...
> > Keeps and breaks on fo:blocks are definitely handled by the
> > corresponding LM, so in that respect, your solution seems to
> > introduce inconsistencies.
>
> Just to clarify: what I mean is, in the end, we could just as well
> scrap the entire FO Tree and rewrite FOP to generate layoutmanagers
> from the input directly. Who needs FONodes after all? What is their
> use, if ultimately everything is handled by the LM anyway?
>
> And in doing so, we would eventually end up back where FOP Trunk
> started in 2002: a monolithic black box, which becomes harder and
> harder to maintain and extend over time.
>
> That's more the nature of my concern: that we do not fall prey to bad
> old habits.
>
I don't get your point in this context. What is different to binding
the Font, Alignment, Color, ... properties to FOText to binding the
Keep-together property to it? Same principle, nothing new introduced
here that wasn't there before. FOText is the generic descendant of
anything that can have text content being it a block, an inline, a
wrapper, .... I admit I am lost in your reasoning.
>
> Cheers
>
> Andreas
Manuel
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jul 19, 2007, at 18:10, Andreas L Delmelle wrote:
> <snip />
>>
>> There is not need for the inline obj to bind to the properties as
>> its LM
>> does not use them.
>> The bind is done only for the FOText as it is the
>> only object whose LM is currently making processing decisions on it.
>
> See? And why is that? Because you decided to implement it that
> way. :-)
>
> Before your patch the property was not present on FOText, and was
> not dealt with by the TextLM, but now it is...
> Keeps and breaks on fo:blocks are definitely handled by the
> corresponding LM, so in that respect, your solution seems to
> introduce inconsistencies.
Just to clarify: what I mean is, in the end, we could just as well
scrap the entire FO Tree and rewrite FOP to generate layoutmanagers
from the input directly. Who needs FONodes after all? What is their
use, if ultimately everything is handled by the LM anyway?
And in doing so, we would eventually end up back where FOP Trunk
started in 2002: a monolithic black box, which becomes harder and
harder to maintain and extend over time.
That's more the nature of my concern: that we do not fall prey to bad
old habits.
Cheers
Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jul 19, 2007, at 16:10, Manuel Mall wrote:
<snip />
>> Now what does not completely sit right with me, is that the
>> properties are still not accessible on the inline level. Your patch
>> transfers the keeps to the FOText itself, instead of activating the
>> property on inline-level FOs.
>>
>> That said, it obviously works, so no reason to complain.
>>
>
> There is not need for the inline obj to bind to the properties as
> its LM
> does not use them.
> The bind is done only for the FOText as it is the
> only object whose LM is currently making processing decisions on it.
See? And why is that? Because you decided to implement it that way. :-)
Before your patch the property was not present on FOText, and was not
dealt with by the TextLM, but now it is...
Keeps and breaks on fo:blocks are definitely handled by the
corresponding LM, so in that respect, your solution seems to
introduce inconsistencies.
No doubt it's the most convenient and quick way to solve it, but I'm
wondering whether it is also qualitatively the best solution in the
long run? Keep-with-next and keep-with-previous on fo:inlines, for
instance, will have to be implemented someday as well.
Cheers
Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Manuel Mall <ma...@apache.org>.
On Thursday 19 July 2007 19:49, Andreas L Delmelle wrote:
> On Jul 19, 2007, at 13:34, Manuel Mall wrote:
> > On Thursday 19 July 2007 19:27, Andreas L Delmelle wrote:
> >> On Jul 19, 2007, at 04:06, Manuel Mall wrote:
> >>> <snip />
> >>> 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>
> >>
> >> OK, then. Where ?
> >
> > inline_keep-together.xml line 39
>
> Right... and where are are the fo:markers you were talking about?
>
Sorry my bad. I meant to write fo:wrapper not fo:marker.
> Now what does not completely sit right with me, is that the
> properties are still not accessible on the inline level. Your patch
> transfers the keeps to the FOText itself, instead of activating the
> property on inline-level FOs.
>
> That said, it obviously works, so no reason to complain.
>
There is not need for the inline obj to bind to the properties as its LM
does not use them. The bind is done only for the FOText as it is the
only object whose LM is currently making processing decisions on it.
>
> Cheers
>
> Andreas
Cheers
Manuel
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jul 19, 2007, at 13:34, Manuel Mall wrote:
> On Thursday 19 July 2007 19:27, Andreas L Delmelle wrote:
>> On Jul 19, 2007, at 04:06, Manuel Mall wrote:
>>> <snip />
>>> 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>
>>
>> OK, then. Where ?
>>
>
> inline_keep-together.xml line 39
Right... and where are are the fo:markers you were talking about?
Now what does not completely sit right with me, is that the
properties are still not accessible on the inline level. Your patch
transfers the keeps to the FOText itself, instead of activating the
property on inline-level FOs.
That said, it obviously works, so no reason to complain.
Cheers
Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Manuel Mall <ma...@apache.org>.
On Thursday 19 July 2007 19:27, Andreas L Delmelle wrote:
> On Jul 19, 2007, at 04:06, Manuel Mall wrote:
> > <snip />
> > 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>
>
> OK, then. Where ?
>
inline_keep-together.xml line 39
>
> Cheers
>
> Andreas
Manuel
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jul 19, 2007, at 04:06, Manuel Mall wrote:
> <snip />
> 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>
>
OK, then. Where ?
Cheers
Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Manuel Mall <ma...@apache.org>.
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
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Andreas L Delmelle <a_...@pandora.be>.
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
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/standard-testcases/
Posted by Manuel Mall <ma...@apache.org>.
On Thursday 19 July 2007 02:31, Andreas L Delmelle wrote:
> On Jul 18, 2007, at 20:06, manuel@apache.org wrote:
>
> Hi Manuel & others
>
> > Author: manuel
> > Date: Wed Jul 18 11:06:09 2007
> > New Revision: 557347
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=557347
> > Log:
> > Added support for keep-togther.within-line="always"
>
> Cool to see this implemented so quickly!
> On the other hand, I do have a few (non-blocking) comments.
>
> There is no real support for inline-level elements yet, as your
> adaptation of the testcase demonstrates: in one case the fo:inline is
> removed, in the other it is substituted with an fo:wrapper. IMO, in
> the near future, keeps on other inline-level FOs should be
> reactivated as well. I was thinking of reactivating the related
> properties on fo.flow.InlineLevel...
>
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. Have I missed an
important use case?
> I had also been thinking in the direction of letting the TextLM deal
> with this, but further considerations made me think this was
> suboptimal. Although this approach works perfectly for a value of
> "always", it could(?) become rather messy when looking at
> integer-keeps.
>
> My last ideas on the subject went in the direction of letting the
> inline-level LM accumulate the regular sequence, and, for a value of
> "always", wrap it in a single box. If the keep-constraint is not
> absolute, the TextLM's parent could still do something similar for
> the individual elements, or something like: surround the entire
> sequence by two penalties, and insert penalties in the sequence but
> with significantly higher/lower values.
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? If the answer is yes
implementation is easy and can stay within TextLM. If the answer is no
then we have a real problem IMO as the algorithm then has to work on
top of Knuth. I believe the same issue exists for the .within-page case
which is probably even more important.
> WDYT?
>
>
> Cheers
>
> Andreas
Manuel