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 Manuel Mall <mm...@arcus.com.au> on 2006/08/03 12:33:17 UTC
Re: [Xmlgraphics-fop Wiki] Update of "ImprovedKeeps" by JeremiasMaerki
On Thursday 03 August 2006 16:47, Apache Wiki wrote:
> Dear Wiki user,
>
...
Hi Jeremias,
just saw your improved keeps wiki and am wondering if an algorithm along
the following lines may do the trick to deal sensibly with different
keep strength values in the context of the Knuth breaking algorithm:
1. For each keep related Knuth penalty we create we remember in the
Knuth element the specified integer keep value (if any)
2. As is now all those penalties are initially set to INFINTE
3. If the breaker can't find a set of break opportunities we adjust the
penalty value for all keep related penalties with the smallest value
keep value down from INFINITE
4. Run the breaker again
5. If no luck take the INFINTE penalties with the next lowest specified
keep value and adjust them down
6. Repeat 4. and 5. until break opportunities are found or nothing is
left that can be adjusted
Assuming that this is rarely needed in practice at lest not many
iterations just scanning a linked list in these circumstances and
running the breaker again should not be a real performance problem.
Manuel
Re: [Xmlgraphics-fop Wiki] Update of "ImprovedKeeps" by JeremiasMaerki
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Well, it's all relative. :-) Moving to a different internal
representation/handling of keep values inside the layout managers is
probably the largest and most pervasive task in all this, one that I
currently don't see a way around if we want to have "relaxed" keeps. I
just want to make sure we use a representation that will also cover
later improvements such as keep-*.within-page. But I still have not
investigated how this latter feature would have to be implemented. Of
course, we can also just do it XP-style and just cater for the problem
at hand. Note, this is all very unrelated to your concrete proposal. I'm
talking about the topic as a whole.
On 03.08.2006 14:06:49 Manuel Mall wrote:
> On Thursday 03 August 2006 18:44, Jeremias Maerki wrote:
> > Hey Manuel,
> >
> > that's a very interesting idea. I think that could work. To me it
> > looks like the biggest problems in the whole topic is determining the
> > right representation of keep values inside the LMs and implementing
> > .within-page for multi-column documents. I won't bother with second
> > for the time being, but any opinions on the first? For me, that's the
> > biggest question mark right now. The other problem, of course, is
> > finding time and/or a sponsor to actually implement it. :-(
> >
>
> Jeremias,
>
> enlighten me please - why is the representation of the keep values
> inside the LMs a (difficult) problem?
>
> <snip/>
> > > Manuel
> >
> > Jeremias Maerki
>
> Manuel
Jeremias Maerki
Re: [Xmlgraphics-fop Wiki] Update of "ImprovedKeeps" by JeremiasMaerki
Posted by Manuel Mall <mm...@arcus.com.au>.
On Thursday 03 August 2006 18:44, Jeremias Maerki wrote:
> Hey Manuel,
>
> that's a very interesting idea. I think that could work. To me it
> looks like the biggest problems in the whole topic is determining the
> right representation of keep values inside the LMs and implementing
> .within-page for multi-column documents. I won't bother with second
> for the time being, but any opinions on the first? For me, that's the
> biggest question mark right now. The other problem, of course, is
> finding time and/or a sponsor to actually implement it. :-(
>
Jeremias,
enlighten me please - why is the representation of the keep values
inside the LMs a (difficult) problem?
<snip/>
> > Manuel
>
> Jeremias Maerki
Manuel
Re: [Xmlgraphics-fop Wiki] Update of "ImprovedKeeps" by JeremiasMaerki
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hey Manuel,
that's a very interesting idea. I think that could work. To me it looks
like the biggest problems in the whole topic is determining the right
representation of keep values inside the LMs and implementing
.within-page for multi-column documents. I won't bother with second for
the time being, but any opinions on the first? For me, that's the
biggest question mark right now. The other problem, of course, is
finding time and/or a sponsor to actually implement it. :-(
On 03.08.2006 12:33:17 Manuel Mall wrote:
> On Thursday 03 August 2006 16:47, Apache Wiki wrote:
> > Dear Wiki user,
> >
> ...
> Hi Jeremias,
>
> just saw your improved keeps wiki and am wondering if an algorithm along
> the following lines may do the trick to deal sensibly with different
> keep strength values in the context of the Knuth breaking algorithm:
>
> 1. For each keep related Knuth penalty we create we remember in the
> Knuth element the specified integer keep value (if any)
>
> 2. As is now all those penalties are initially set to INFINTE
>
> 3. If the breaker can't find a set of break opportunities we adjust the
> penalty value for all keep related penalties with the smallest value
> keep value down from INFINITE
>
> 4. Run the breaker again
>
> 5. If no luck take the INFINTE penalties with the next lowest specified
> keep value and adjust them down
>
> 6. Repeat 4. and 5. until break opportunities are found or nothing is
> left that can be adjusted
>
> Assuming that this is rarely needed in practice at lest not many
> iterations just scanning a linked list in these circumstances and
> running the breaker again should not be a real performance problem.
>
> Manuel
Jeremias Maerki