Re: page-breaking strategies and performance

[Jeremias Maerki]

On 02.03.2005 17:05:55 Glen Mazza wrote:
> Yes, I'm not in Simon's league here--I know very
> little about TeX--so I'll defer to you two on this
> issue.

I'm also still struggling. :-)

>  Just try to make sure that the final algorithm
> will help us support the keep-* properties.

Yes, the algorithm MUST be able to handle full keep support (among other
things). That's part of why we need a new approach. The present one
doesn't quite fit the picture, yet. Thankfully, with the new design we
don't have to again rewrite the whole FOP. The present approach was very
good to point us in the right direction and most of the effort already
invested is not lost. We just have to improve a specific part.

Jeremias Maerki

Re: page-breaking strategies and performance

[Glen Mazza]

Yes, I'm not in Simon's league here--I know very
little about TeX--so I'll defer to you two on this
issue.  Just try to make sure that the final algorithm
will help us support the keep-* properties.

Thanks,
Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Thanks. I think this has only to do with the rules
> to handle keeps and
> breaks and how to resolve conflicts. I don't think,
> however, that these
> parts create a restriction which tells us what
> page-breaking strategy to
> pursue. We could probably run with a first-fit
> strategy and still
> fulfill the rules below if we accept a lot of
> backtracking. But as Simon
> suggested, this seems to be a poor approach.
> 
> Keeps and breaks are only part of what a page
> breaking algorithm has to
> deal with. See [3].
> 
> [3]
>
http://wiki.apache.org/xmlgraphics-fop/PageLayout/InfluencingFeatures
> 
> On 02.03.2005 16:44:17 Glen Mazza wrote:
> > I'm unsure here.  My interpretation comes from two
> > places: 
> > 
> > 1.) Section 4.8, the last paragraph of [1]:
> > 
> > "The area tree is constrained to satisfy all break
> > conditions imposed. ***Each keep condition must
> also
> > be satisfied***, except when this would cause a
> break
> > condition or a stronger keep condition to fail to
> be
> > satisfied."
> > 
> > i.e., keep conditions need to be satisfied.
> > 
> > 2.) The definitions of the three keep-[]
> properties
> > [2] each have a initial value of "auto", meaning
> > "There are no keep-[] conditions imposed by this
> > property."
> > 
> > So by default, if the user does not explicitly
> specify
> > keep properties, e.g.,
> "keep-together.within-page", no
> > text, pictures, etc. are to be kept together on
> the
> > same page, if they wouldn't already be so due to
> > free-flowing (i.e., first-fit) text.  Everything
> would
> > become free-flowing in order to obey the
> stylesheet
> > writer's specifications.
> > 
> > Just my $0.02.
> > 
> > Thanks,
> > Glen
> > 
> > [1]
> >
>
http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#keepbreak
> > 
> > [2]
> >
>
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#keep-together
> > 
> > 
> > --- Jeremias Maerki <[EMAIL PROTECTED]>
> wrote:
> > 
> > > Where did you find such a suggestion? I'd be
> > > interested to know if
> > > there's a hint in this direction in the spec. I
> > > thought it was up to the
> > > implementation to decide the strategy.
> > > 
> > > I think the way we're now taking in our
> discussion
> > > suggests that we're
> > > not going to do a first-fit strategy at all. If
> > > we're really going down
> > > the two-strategy path we'll probably end up with
> a
> > > best-fit strategy and
> > > a total-fit or best-fit plus look-ahead. (See
> > > Simon's list [1]) But
> > > that's something we still need to figure out
> > > together.
> > > 
> > 
> > If we ever have multiple page-breaking options, it
> can
> > be a user-defined configuration switch.  No
> problem
> > there.
> > 
> > Glen
> > 
> > 
> > > [1]
> > >
> http://wiki.apache.org/xmlgraphics-fop/PageLayout
> > > 
> > > On 02.03.2005 14:48:17 Glen Mazza wrote:
> > > > Just a sanity check here, the XSL
> specification
> > > seems
> > > > to suggest always the first-fit strategy for
> page
> > > > breaking *except* where keeps are explicitly
> > > > specified.  Am I correct here?  And, if so, is
> > > what
> > > > you're planning going to result in an
> algorithm
> > > that
> > > > will help us do this?
> > > 
> > > 
> > > Jeremias Maerki
> > > 
> > > 
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: page-breaking strategies and performance

[Jeremias Maerki]

Thanks. I think this has only to do with the rules to handle keeps and
breaks and how to resolve conflicts. I don't think, however, that these
parts create a restriction which tells us what page-breaking strategy to
pursue. We could probably run with a first-fit strategy and still
fulfill the rules below if we accept a lot of backtracking. But as Simon
suggested, this seems to be a poor approach.

Keeps and breaks are only part of what a page breaking algorithm has to
deal with. See [3].

[3] http://wiki.apache.org/xmlgraphics-fop/PageLayout/InfluencingFeatures

On 02.03.2005 16:44:17 Glen Mazza wrote:
> I'm unsure here.  My interpretation comes from two
> places: 
> 
> 1.) Section 4.8, the last paragraph of [1]:
> 
> "The area tree is constrained to satisfy all break
> conditions imposed. ***Each keep condition must also
> be satisfied***, except when this would cause a break
> condition or a stronger keep condition to fail to be
> satisfied."
> 
> i.e., keep conditions need to be satisfied.
> 
> 2.) The definitions of the three keep-[] properties
> [2] each have a initial value of "auto", meaning
> "There are no keep-[] conditions imposed by this
> property."
> 
> So by default, if the user does not explicitly specify
> keep properties, e.g., "keep-together.within-page", no
> text, pictures, etc. are to be kept together on the
> same page, if they wouldn't already be so due to
> free-flowing (i.e., first-fit) text.  Everything would
> become free-flowing in order to obey the stylesheet
> writer's specifications.
> 
> Just my $0.02.
> 
> Thanks,
> Glen
> 
> [1]
> http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#keepbreak
> 
> [2]
> http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#keep-together
> 
> 
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> > Where did you find such a suggestion? I'd be
> > interested to know if
> > there's a hint in this direction in the spec. I
> > thought it was up to the
> > implementation to decide the strategy.
> > 
> > I think the way we're now taking in our discussion
> > suggests that we're
> > not going to do a first-fit strategy at all. If
> > we're really going down
> > the two-strategy path we'll probably end up with a
> > best-fit strategy and
> > a total-fit or best-fit plus look-ahead. (See
> > Simon's list [1]) But
> > that's something we still need to figure out
> > together.
> > 
> 
> If we ever have multiple page-breaking options, it can
> be a user-defined configuration switch.  No problem
> there.
> 
> Glen
> 
> 
> > [1]
> > http://wiki.apache.org/xmlgraphics-fop/PageLayout
> > 
> > On 02.03.2005 14:48:17 Glen Mazza wrote:
> > > Just a sanity check here, the XSL specification
> > seems
> > > to suggest always the first-fit strategy for page
> > > breaking *except* where keeps are explicitly
> > > specified.  Am I correct here?  And, if so, is
> > what
> > > you're planning going to result in an algorithm
> > that
> > > will help us do this?
> > 
> > 
> > Jeremias Maerki
> > 
> > 



Jeremias Maerki

Re: page-breaking strategies and performance

[Glen Mazza]

I'm unsure here.  My interpretation comes from two
places: 

1.) Section 4.8, the last paragraph of [1]:

"The area tree is constrained to satisfy all break
conditions imposed. ***Each keep condition must also
be satisfied***, except when this would cause a break
condition or a stronger keep condition to fail to be
satisfied."

i.e., keep conditions need to be satisfied.

2.) The definitions of the three keep-[] properties
[2] each have a initial value of "auto", meaning
"There are no keep-[] conditions imposed by this
property."

So by default, if the user does not explicitly specify
keep properties, e.g., "keep-together.within-page", no
text, pictures, etc. are to be kept together on the
same page, if they wouldn't already be so due to
free-flowing (i.e., first-fit) text.  Everything would
become free-flowing in order to obey the stylesheet
writer's specifications.

Just my $0.02.

Thanks,
Glen

[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#keepbreak

[2]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#keep-together


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Where did you find such a suggestion? I'd be
> interested to know if
> there's a hint in this direction in the spec. I
> thought it was up to the
> implementation to decide the strategy.
> 
> I think the way we're now taking in our discussion
> suggests that we're
> not going to do a first-fit strategy at all. If
> we're really going down
> the two-strategy path we'll probably end up with a
> best-fit strategy and
> a total-fit or best-fit plus look-ahead. (See
> Simon's list [1]) But
> that's something we still need to figure out
> together.
> 

If we ever have multiple page-breaking options, it can
be a user-defined configuration switch.  No problem
there.

Glen


> [1]
> http://wiki.apache.org/xmlgraphics-fop/PageLayout
> 
> On 02.03.2005 14:48:17 Glen Mazza wrote:
> > Just a sanity check here, the XSL specification
> seems
> > to suggest always the first-fit strategy for page
> > breaking *except* where keeps are explicitly
> > specified.  Am I correct here?  And, if so, is
> what
> > you're planning going to result in an algorithm
> that
> > will help us do this?
> 
> 
> Jeremias Maerki
> 
> 

Re: page-breaking strategies and performance

[Jeremias Maerki]

Where did you find such a suggestion? I'd be interested to know if
there's a hint in this direction in the spec. I thought it was up to the
implementation to decide the strategy.

I think the way we're now taking in our discussion suggests that we're
not going to do a first-fit strategy at all. If we're really going down
the two-strategy path we'll probably end up with a best-fit strategy and
a total-fit or best-fit plus look-ahead. (See Simon's list [1]) But
that's something we still need to figure out together.

[1] http://wiki.apache.org/xmlgraphics-fop/PageLayout

On 02.03.2005 14:48:17 Glen Mazza wrote:
> Just a sanity check here, the XSL specification seems
> to suggest always the first-fit strategy for page
> breaking *except* where keeps are explicitly
> specified.  Am I correct here?  And, if so, is what
> you're planning going to result in an algorithm that
> will help us do this?


Jeremias Maerki

Re: page-breaking strategies and performance

[Glen Mazza]

Just a sanity check here, the XSL specification seems
to suggest always the first-fit strategy for page
breaking *except* where keeps are explicitly
specified.  Am I correct here?  And, if so, is what
you're planning going to result in an algorithm that
will help us do this?

Thanks,
Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> I'd rather not work on HEAD directly because after
> creating the basics
> for the new mechanism the whole thing will probably
> not work for some
> time (probably 2-4 weeks). But I'd like to be able
> to check in early so
> people can review. I expect that the life time of
> the branch will not
> exceed 8 weeks. So there's almost no chance that
> alt-design is repeated,
> especially since the basic LM infrastructure will
> not be altered big
> time and it looks like we are all going in the same
> direction for the
> new page-breaking. It's clear that it has to be done
> and it seems to be
> moveing in the direction of a derived Knuth
> approach. It's much like the
> migration to the Knuth line breaking and it's mostly
> the block-level LMs
> that will be affected. People can continue to work
> on HEAD during that
> time as long as nothing serious is altered in the
> block-level LMs which
> would make merging difficult.
> 
> Before I can kick off we need to agree to the
> general approach for the
> algorithm and clear a few details so we are
> reasonably sure that it'll
> work. Once we have that the plan for the branch
> should not be a big deal
> if we take the above into account.
> 
> On 02.03.2005 13:16:42 Glen Mazza wrote:
> > 
> > --- Chris Bowditch <[EMAIL PROTECTED]>
> wrote:
> > 
> > > > 
> > > > As for the plan to implement a new
> page-breaking
> > > mechanism: I've got to
> > > > do it now. :-) I'm sorry if this may put some
> > > pressure on some of you.
> > > > I'm also not sure if I'm fit already to tackle
> it,
> > > but I've got to
> > > > do it anyway. Since I don't want to work with
> a
> > > series of patches like
> > > > you guys did earlier, I'd like to create a
> branch
> > > to do that on as soon
> > > > as we've agreed on a strategy. Any objections
> to
> > > that?
> > > 
> > > If we are going to branch the code for this then
> we
> > > need to make sure we have 
> > > a plan to merge the branch back once we are
> > > confident in the new page breaking 
> > > algorithm. This plan (which should be agreed
> before
> > > branching takes place) 
> > > should include an acceptance procedure, e.g.
> will a
> > > single -1 be able to 
> > > prevent the code being merged back? We dont want
> to
> > > end up with another 
> > > alt-design, which eventually moved to source
> > > forge!!!
> > > 
> > > Chris
> > > 
> > 
> > Either way is fine with me, but Chris brings up a
> very
> > valid point.  If you can tolerate and keep up with
> my
> > minor code housekeeping from time to time in some
> of
> > the layout managers (currently mostly PSLM), feel
> free
> > to work from HEAD directly instead if you wish.
> > 
> > Glen
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: page-breaking strategies and performance

[Jeremias Maerki]

I'd rather not work on HEAD directly because after creating the basics
for the new mechanism the whole thing will probably not work for some
time (probably 2-4 weeks). But I'd like to be able to check in early so
people can review. I expect that the life time of the branch will not
exceed 8 weeks. So there's almost no chance that alt-design is repeated,
especially since the basic LM infrastructure will not be altered big
time and it looks like we are all going in the same direction for the
new page-breaking. It's clear that it has to be done and it seems to be
moveing in the direction of a derived Knuth approach. It's much like the
migration to the Knuth line breaking and it's mostly the block-level LMs
that will be affected. People can continue to work on HEAD during that
time as long as nothing serious is altered in the block-level LMs which
would make merging difficult.

Before I can kick off we need to agree to the general approach for the
algorithm and clear a few details so we are reasonably sure that it'll
work. Once we have that the plan for the branch should not be a big deal
if we take the above into account.

On 02.03.2005 13:16:42 Glen Mazza wrote:
> 
> --- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> 
> > > 
> > > As for the plan to implement a new page-breaking
> > mechanism: I've got to
> > > do it now. :-) I'm sorry if this may put some
> > pressure on some of you.
> > > I'm also not sure if I'm fit already to tackle it,
> > but I've got to
> > > do it anyway. Since I don't want to work with a
> > series of patches like
> > > you guys did earlier, I'd like to create a branch
> > to do that on as soon
> > > as we've agreed on a strategy. Any objections to
> > that?
> > 
> > If we are going to branch the code for this then we
> > need to make sure we have 
> > a plan to merge the branch back once we are
> > confident in the new page breaking 
> > algorithm. This plan (which should be agreed before
> > branching takes place) 
> > should include an acceptance procedure, e.g. will a
> > single -1 be able to 
> > prevent the code being merged back? We dont want to
> > end up with another 
> > alt-design, which eventually moved to source
> > forge!!!
> > 
> > Chris
> > 
> 
> Either way is fine with me, but Chris brings up a very
> valid point.  If you can tolerate and keep up with my
> minor code housekeeping from time to time in some of
> the layout managers (currently mostly PSLM), feel free
> to work from HEAD directly instead if you wish.
> 
> Glen



Jeremias Maerki

Re: page-breaking strategies and performance

[Glen Mazza]

--- Chris Bowditch <[EMAIL PROTECTED]> wrote:

> > 
> > As for the plan to implement a new page-breaking
> mechanism: I've got to
> > do it now. :-) I'm sorry if this may put some
> pressure on some of you.
> > I'm also not sure if I'm fit already to tackle it,
> but I've got to
> > do it anyway. Since I don't want to work with a
> series of patches like
> > you guys did earlier, I'd like to create a branch
> to do that on as soon
> > as we've agreed on a strategy. Any objections to
> that?
> 
> If we are going to branch the code for this then we
> need to make sure we have 
> a plan to merge the branch back once we are
> confident in the new page breaking 
> algorithm. This plan (which should be agreed before
> branching takes place) 
> should include an acceptance procedure, e.g. will a
> single -1 be able to 
> prevent the code being merged back? We dont want to
> end up with another 
> alt-design, which eventually moved to source
> forge!!!
> 
> Chris
> 

Either way is fine with me, but Chris brings up a very
valid point.  If you can tolerate and keep up with my
minor code housekeeping from time to time in some of
the layout managers (currently mostly PSLM), feel free
to work from HEAD directly instead if you wish.

Glen

Re: page-breaking strategies and performance

[Chris Bowditch]

Jeremias Maerki wrote:
Hi Jeremias,
I finally have Knuth's "Digital Typography" and let myself enlighten by
his well-written words. In [1] Simon outlined different strategies for
page-breaking, obviously closely following the different approaches
defined by Knuth. At first glance, I'd say that "best-fit" is probably
the obvious strategy to select, especially if TeX is happy with it.
Obviously, it can't find the optimal solution like this but the
additional overhead (memory and CPU power) of a look-ahead/total-fit
strategy is simply too much and unnecessary for things like invoices and
insurance policies which are surely some of the most popular use cases
of XSL-FO. Here, speed is extremely important. People writing
documentation (maybe using DocBook) or glossy stock reports have
additional requirements and don't mind the longer processing time and
additional memory requirements. This leads me to the question if we
shouldn't actually implement two page-breaking strategies (in the end,
not both right now). For a speed-optimized algorithm, we could even
think about ignoring side-floats.
We have dozens of customers using an XSL-FO solution and I can confirm 
invoices and insurance policies are a common use case for XSL-FO. A lot of 
companies have performance as a priority and we have no one using side floats 
or even thinking about using them, so optimizing for speed by ignoring side 
floats sounds like a good idea! But this is just my 2 cents and may conflict 
with other people's wishes.

Obviously, in this model we would have to make sure that we use a common
model for both strategies. For example, we still have to make sure that
the line layout gets information on the available IPD on each line, but
probably this will not be a big problem to include later.
An enhanced/adjusted box/glue/penalty model sounds like a good idea to
me especially since Knuth hints at that in his book, too. There's also a
question if part of the infrastructure from line breaking can be reused
for page breaking, but I guess rather not.
Probably best to re-create an algorithm from scratch for page breaking but 
line breaking can be reviewed for ideas.

As for the plan to implement a new page-breaking mechanism: I've got to
do it now. :-) I'm sorry if this may put some pressure on some of you.
I'm also not sure if I'm fit already to tackle it, but I've got to
do it anyway. Since I don't want to work with a series of patches like
you guys did earlier, I'd like to create a branch to do that on as soon
as we've agreed on a strategy. Any objections to that?
If we are going to branch the code for this then we need to make sure we have 
a plan to merge the branch back once we are confident in the new page breaking 
algorithm. This plan (which should be agreed before branching takes place) 
should include an acceptance procedure, e.g. will a single -1 be able to 
prevent the code being merged back? We dont want to end up with another 
alt-design, which eventually moved to source forge!!!

Chris

Re: page-breaking strategies and performance

[Jeremias Maerki]

On 01.03.2005 22:25:12 Simon Pepping wrote:
> On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
> > Jeremias Maerki wrote:
> > 
> > > processing time and additional memory requirements. This 
> > > leads me to the question if we shouldn't actually implement 
> > > two page-breaking strategies (in the end, not both right 
> > > now). For a speed-optimized algorithm, we could even think 
> > > about ignoring side-floats.
> > > 
> > > Obviously, in this model we would have to make sure that we 
> > > use a common model for both strategies. For example, we still 
> > > have to make sure that the line layout gets information on 
> > > the available IPD on each line, but probably this will not be 
> > > a big problem to include later.
> > 
> > This is an excellent idea. It has from time to time gone under the moniker
> > LayoutStrategy or pluggable layout. To do it without duplicating everything
> > requires that the other pieces of the system be modularized, the concerns
> > separated so that they can be reused. The upside is tremendous and the cost
> > pays for itself in developer productivity.
> 
> The idea of having two page breaking strategies is OK. But it is also
> a goal that is yet far over the horizon.

Right. What I'd like to achieve is having a usable layout engine with
the minimum of effort for most use cases but without blocking our way in
terms of full compliance like what happened with the old code base. I
also don't want to invest to much time in an infrastructure to support
pluggable strategies, only that we keep it in mind while we build the
first one.

> I hope this is smaller than having pluggable layout.

My hope, too. The critical part is to determine the model that helps us
express all the elements of the XSL-FO standard.

> We should try to
> express the layout constraints in a simple language, which can be used
> by the algorithms of both strategies. Knuth's model is an effort to
> achieve that, and a PageLayoutManager which receives the Knuth
> elements and invokes the appropriate algorithm goes with it.

That's what I'm currently trying to figure out. I guess we'll need to
sketch all the different layout elements that we need to support like
you started.

> Such a setup should not only enable multiple page breaking strategies,
> but also help us implement a simple strategy to start with, and
> gradually evolve it to a higher level of sophistication.

That's the idea.


Jeremias Maerki

Re: page-breaking strategies and performance

[Simon Pepping]

On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > processing time and additional memory requirements. This 
> > leads me to the question if we shouldn't actually implement 
> > two page-breaking strategies (in the end, not both right 
> > now). For a speed-optimized algorithm, we could even think 
> > about ignoring side-floats.
> > 
> > Obviously, in this model we would have to make sure that we 
> > use a common model for both strategies. For example, we still 
> > have to make sure that the line layout gets information on 
> > the available IPD on each line, but probably this will not be 
> > a big problem to include later.
> 
> This is an excellent idea. It has from time to time gone under the moniker
> LayoutStrategy or pluggable layout. To do it without duplicating everything
> requires that the other pieces of the system be modularized, the concerns
> separated so that they can be reused. The upside is tremendous and the cost
> pays for itself in developer productivity.

The idea of having two page breaking strategies is OK. But it is also
a goal that is yet far over the horizon.

I hope this is smaller than having pluggable layout. We should try to
express the layout constraints in a simple language, which can be used
by the algorithms of both strategies. Knuth's model is an effort to
achieve that, and a PageLayoutManager which receives the Knuth
elements and invokes the appropriate algorithm goes with it.

Such a setup should not only enable multiple page breaking strategies,
but also help us implement a simple strategy to start with, and
gradually evolve it to a higher level of sophistication.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: page-breaking strategies and performance

[Simon Pepping]

On Tue, Mar 01, 2005 at 03:02:38PM +0100, Jeremias Maerki wrote:
> As for the plan to implement a new page-breaking mechanism: I've got to
> do it now. :-) I'm sorry if this may put some pressure on some of you.
> I'm also not sure if I'm fit already to tackle it, but I've got to
> do it anyway. Since I don't want to work with a series of patches like
> you guys did earlier, I'd like to create a branch to do that on as soon
> as we've agreed on a strategy. Any objections to that?

That is a good idea.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

RE: page-breaking strategies and performance

[Victor Mote]

Jeremias Maerki wrote:

> processing time and additional memory requirements. This 
> leads me to the question if we shouldn't actually implement 
> two page-breaking strategies (in the end, not both right 
> now). For a speed-optimized algorithm, we could even think 
> about ignoring side-floats.
> 
> Obviously, in this model we would have to make sure that we 
> use a common model for both strategies. For example, we still 
> have to make sure that the line layout gets information on 
> the available IPD on each line, but probably this will not be 
> a big problem to include later.

This is an excellent idea. It has from time to time gone under the moniker
LayoutStrategy or pluggable layout. To do it without duplicating everything
requires that the other pieces of the system be modularized, the concerns
separated so that they can be reused. The upside is tremendous and the cost
pays for itself in developer productivity.

Victor Mote

Re: Page breaking

[Jeremias Maerki]

Right here: http://nagoya.apache.org/eyebrowse/[EMAIL 
PROTECTED]&by=thread&from=984205

On 21.02.2005 01:15:41 Renaud Richardet wrote:
> Jeremias,
> 
> > I went back to Simon's and Finn's ideas about page breaking and I see
> > some overlap. 
> 
> could you point me to where Simon and Finn exposed their ideas? 
> thanks, Renaud



Jeremias Maerki

Re: Page breaking

[Renaud Richardet]

Jeremias,

> I went back to Simon's and Finn's ideas about page breaking and I see
> some overlap. 

could you point me to where Simon and Finn exposed their ideas? 
thanks, Renaud

Re: Page breaking [was: Markers added to the wrong page]

[Luca Furini]

Finn Bock wrote:

> I would pass the element on the immidiate parent, which recursively
> passes them on the top-level LM in the direction. For inline, the
> toplevel would be LineLM and for blocks it would be the PageLM.

Ok, I misunderstood what you wrote, now I think we were saying the same
thing using different words! :-)

Regards
Luca

RE: Page breaking [was: Markers added to the wrong page]

[Victor Mote]

Finn Bock wrote:

> Not at all. It is a rather trivial change to knuth to pick a 
> page break when there is N pages of lookahead.
> 
> If we assume that finished page knuth element arrive one at 
> time to the KnuthPage algorithm, the main loop becomes:
> 
> addKnuthElement(element) {
>  if element.isBox():
>  totalWidth += element.width
>  else if element.isGlue():
>  if (previous element is box):
>  considerLegalBreak()
>  totalWidth += element.width
>  totalStretch += element.stretch
>  totalShrink += element.shrink
>  else if element.isPenalty():
>  if element.penalty < INFINITE:
>  considerLegalBreak()
>  if activeList.startLine > currentPage + lookahead:
>  // In the activeList, find the node with the best demerit.
>  bestNode = findBestDemerit()
>  // Remove all nodes in activeList which does not 
> have bestNode
>  // in their parentage.
>  clearActiveList(bestNode)
>   makePageBreak(bestNode)
> 
> Here it is only clearActiveList() which does not have a fast 
> implementation when using the usual implementation of 
> ActiveNode. It will require a scan over all the active node 
> and for each node a scan back thru the previous links to the 
> node at currentPage+1.
> 
> clearActiveList(bestNode):
>  for node in activeList:
>  // jump back thru previous (node.page-currentPage) times.
>  while i++ < node.page - currentPage
>  previous = node.previous
>  if previous != bestNode:
>  activeList.remove(node)
>   
> 
> The rest of the methods called are similar to the methods in 
> my knuth line breaking patch (which is quite similar the 
> current implementation).

Hmmm. I guess it depends on where the N in "N pages of lookahead" comes
from. If that can be set to include the entire page-sequence, then you can
call it a Knuth-style algorithm. Otherwise, I think you have something less,
which is OK for those who don't want the performance hit.

> My own insecurity comes from figuring out which penalty values and 
> demerit algorihtm to use to get keeps and orphans right.

Yes. Fortunately, the XSL-FO standard provides some guidance here, but I
agree that this part will be a challenge.

Good luck. I am glad to see you guys heading down this path. Let me know if
there is anything I can do to help.

Victor Mote

Re: Page breaking [was: Markers added to the wrong page]

[Finn Bock]

[The Web Maestro]
I don't know how the spec deals with this, but I doubt the 
spec cares which algorithm is used. That said, would it be a 
good idea to determine which algorithm to use based on 
something in userconfig.xml or something? If the Knuth system 
is more 'expensive' in terms of resources, we could make 
non-Knuth the default, and enable Knuth via a config file.
Yes indeed. But without measurements I would guess that knuth page 
breaking would be far less expensive than the knuth line breaking. The 
line breaking has to deal with far more elements and because of that a 
far larger set of active nodes.

But clearly a choice will be good, both for page and for line breaking.
[Victor]
The good news is that this is an excellent idea. The bad news is that FOP's
determination to not even tolerate more than one algorithm is what drove FOP
and FOray apart. So you have stumbled in to a somewhat sensitive area, which
might explain the absence of responses (so far).
BTW, since it is relevant here, thanks for your kind comments last week in
another thread. You are ever the peacemaker, a very useful role. As long as
the differences remain as great as they are, we *need* more than one FO
implementation. In the meantime, I am much more useful and productive
outside of FOP than I am in it, and, the FOP developers probably are also.
To my perhaps still naive mind, layout consists of exactly two tasks: 1)
finding line-breaks within logical blocks (nested blocks consisting of a new
logical block), and 2) finding page-breaks between and within logical
blocks. All other tasks can be conveniently handled within the two data
structures, not being dependent on any strategy. The Knuth-style algorithm
is by definition a total-fit algorithm. The scope of such an algorithm for
the first task is the logical block itself. The scope of the second task is
the page-sequence. So, to implement a Knuth-style algorithm (itself a good
idea) for item 2, requires the ability to see an entire page-sequence in the
AreaTree at one time.
Not at all. It is a rather trivial change to knuth to pick a page break 
when there is N pages of lookahead.

If we assume that finished page knuth element arrive one at time to the 
KnuthPage algorithm, the main loop becomes:

addKnuthElement(element) {
if element.isBox():
totalWidth += element.width
else if element.isGlue():
if (previous element is box):
considerLegalBreak()
totalWidth += element.width
totalStretch += element.stretch
totalShrink += element.shrink
else if element.isPenalty():
if element.penalty < INFINITE:
considerLegalBreak()
if activeList.startLine > currentPage + lookahead:
// In the activeList, find the node with the best demerit.
bestNode = findBestDemerit()
// Remove all nodes in activeList which does not have bestNode
// in their parentage.
clearActiveList(bestNode)
makePageBreak(bestNode)
Here it is only clearActiveList() which does not have a fast 
implementation when using the usual implementation of ActiveNode. It 
will require a scan over all the active node and for each node a scan 
back thru the previous links to the node at currentPage+1.

clearActiveList(bestNode):
for node in activeList:
// jump back thru previous (node.page-currentPage) times.
while i++ < node.page - currentPage
previous = node.previous
if previous != bestNode:
activeList.remove(node)

The rest of the methods called are similar to the methods in my knuth 
line breaking patch (which is quite similar the current implementation).

My own insecurity comes from figuring out which penalty values and 
demerit algorihtm to use to get keeps and orphans right.

regards,
finn

RE: Page breaking [was: Markers added to the wrong page]

[Victor Mote]

The Web Maestro wrote:

> e-mail... I suspect there may be another 'side' to the 
> story--there  always is--and that there's may be other 
> contributing factors... but this helps me understand much 
> more than I understood before. Your explanation below also 

Yes, there is another side, and I respect that. The point is that the
differences are hard-wired at a pretty low-level (think silicon instead of
Java). I am constitutionally unable to make myself work on a project that
*can* be broken up into smaller pieces and isn't. Others appear to be
constitutionally unable to allow that to happen. Most can probably live with
it either way. OK, not every problem is solvable, and not every difference
is reconcilable. We go on. You guys pull east, I'll pull west, and as long
as we're pulling *different* wagons, we each have a shot at making some
progress.

> Might these links help:

I think those are the "other" books, but, to tell the truth, after looking
at the links, I can't tell. I'll have to go dig out my old notes to see
which book I was wanting. I'll check into it further. Thanks.

Victor Mote

Re: Page breaking [was: Markers added to the wrong page]

[The Web Maestro]

On Feb 7, 2005, at 11:57 AM, Victor Mote wrote:
The Web Maestro wrote:
I don't know how the spec deals with this, but I doubt the
spec cares which algorithm is used. That said, would it be a
good idea to determine which algorithm to use based on
something in userconfig.xml or something? If the Knuth system
is more 'expensive' in terms of resources, we could make
non-Knuth the default, and enable Knuth via a config file.
Hi Clay:
The good news is that this is an excellent idea. The bad news is that 
FOP's
determination to not even tolerate more than one algorithm is what 
drove FOP
and FOray apart. So you have stumbled in to a somewhat sensitive area, 
which
might explain the absence of responses (so far).
Thanks for the heads up, and also for the 'clue'... I never completely 
understood what happened, as it occurred before I was committed. ;-) I 
understand a bit more, thanks to this e-mail... I suspect there may be 
another 'side' to the story--there  always is--and that there's may be 
other contributing factors... but this helps me understand much more 
than I understood before. Your explanation below also helps! I probably 
just need to ask for help when I don't understand something... but I've 
got enough going in my head anyway...

FOP-DEV... Please don't take this as griping (it's not!), but I get 
lost in thee BP/BPD/IPD/AT speak now and again, which is one reason I 
tend to stay out of the fray on that stuff. If I get confused--and 
choose to attempt to contribute to a discussion--I'll speak up about 
anything that strikes my fancy. If there's something I don't get... 
I'll search Google first.

BTW, since it is relevant here, thanks for your kind comments last 
week in
another thread. You are ever the peacemaker, a very useful role. As 
long as
the differences remain as great as they are, we *need* more than one FO
implementation. In the meantime, I am much more useful and productive
outside of FOP than I am in it, and, the FOP developers probably are 
also.

To my perhaps still naive mind, layout consists of exactly two tasks: 
1)
finding line-breaks within logical blocks (nested blocks consisting of 
a new
logical block), and 2) finding page-breaks between and within logical
blocks. All other tasks can be conveniently handled within the two data
structures, not being dependent on any strategy. The Knuth-style 
algorithm
is by definition a total-fit algorithm. The scope of such an algorithm 
for
the first task is the logical block itself. The scope of the second 
task is
the page-sequence. So, to implement a Knuth-style algorithm (itself a 
good
idea) for item 2, requires the ability to see an entire page-sequence 
in the
AreaTree at one time. I am a little confused about whether FOP's 
design will
even allow that to happen right now. I understood both Keiron's and 
Finn's
design ideas (and Peter West's also) to be releasing pages from the 
AreaTree
long before a page-sequence was even completely parsed. However, I may 
have
misunderstood, especially Finn's, which I am especially fuzzy on.

I read somewhere that Peter Karow was going to try to implement a
Knuth-style algorithm for URW, and I have tried desperately and
unsuccessfully to get a copy of his book on the topic. If anybody 
knows that
status of that effort or how to find his out-of-print books, please 
let us
know.
Might these links help:
http://www.google.com/search?hl=en&q=Peter+Karow+book&spell=1
http://www.amazon.com/exec/obidos/ISBN%3D0387572236/102-3161708-3958541
http://www.amazon.com/exec/obidos/ISBN%3D0387565094/102-3161708-3958541
The general approach that FOray hopes to take eventually is a first-fit
algorithm for the initial pass through a page-sequence, then a second
optimization look that I hope to make do a Knuth-style evaluation. 
That may
be sub-optimal, but it is my best guess right now about a reasonable 
way to
proceed.

Victor Mote
Thanks again for the explanation! Cheers!
Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

RE: Page breaking [was: Markers added to the wrong page]

[Victor Mote]

The Web Maestro wrote:

> I don't know how the spec deals with this, but I doubt the 
> spec cares which algorithm is used. That said, would it be a 
> good idea to determine which algorithm to use based on 
> something in userconfig.xml or something? If the Knuth system 
> is more 'expensive' in terms of resources, we could make 
> non-Knuth the default, and enable Knuth via a config file.

Hi Clay:

The good news is that this is an excellent idea. The bad news is that FOP's
determination to not even tolerate more than one algorithm is what drove FOP
and FOray apart. So you have stumbled in to a somewhat sensitive area, which
might explain the absence of responses (so far).

BTW, since it is relevant here, thanks for your kind comments last week in
another thread. You are ever the peacemaker, a very useful role. As long as
the differences remain as great as they are, we *need* more than one FO
implementation. In the meantime, I am much more useful and productive
outside of FOP than I am in it, and, the FOP developers probably are also.

To my perhaps still naive mind, layout consists of exactly two tasks: 1)
finding line-breaks within logical blocks (nested blocks consisting of a new
logical block), and 2) finding page-breaks between and within logical
blocks. All other tasks can be conveniently handled within the two data
structures, not being dependent on any strategy. The Knuth-style algorithm
is by definition a total-fit algorithm. The scope of such an algorithm for
the first task is the logical block itself. The scope of the second task is
the page-sequence. So, to implement a Knuth-style algorithm (itself a good
idea) for item 2, requires the ability to see an entire page-sequence in the
AreaTree at one time. I am a little confused about whether FOP's design will
even allow that to happen right now. I understood both Keiron's and Finn's
design ideas (and Peter West's also) to be releasing pages from the AreaTree
long before a page-sequence was even completely parsed. However, I may have
misunderstood, especially Finn's, which I am especially fuzzy on.

I read somewhere that Peter Karow was going to try to implement a
Knuth-style algorithm for URW, and I have tried desperately and
unsuccessfully to get a copy of his book on the topic. If anybody knows that
status of that effort or how to find his out-of-print books, please let us
know.

The general approach that FOray hopes to take eventually is a first-fit
algorithm for the initial pass through a page-sequence, then a second
optimization look that I hope to make do a Knuth-style evaluation. That may
be sub-optimal, but it is my best guess right now about a reasonable way to
proceed.

Victor Mote

Re: Page breaking [was: Markers added to the wrong page]

[The Web Maestro]

On Feb 7, 2005, at 7:21 AM, Luca Furini wrote:
Finn Bock wrote:
Using your description as a jumping point, here is my ideas for page
breaking. I suppose it is even more pie-in-the-sky since I haven't yet
written anything about it.
As I have been doing a few experiments about page breaking, I'm happy 
to
join in this conversation.
I rarely find myself feeling the urge to enter these conversations 
(it's not really my forte), but every now and then, I find I might 
offer an idea or two I think (hope) will be constructive...

The algorithm that the PageLM uses are a slightly modified knuth (no
need to maintain fitnessclass, and with the ability to decide on a 
break
when there is N pages of lookahead). The elements return from the LMs
are boxes (for lines), spaces and penalties.
Note that using the box - penalty - glue representation does not
necessarily involve using Knuth's algorithm.
A first-fit (or best-fit) algorithm could be enough in most situations;
and if there are no adjustable elements in the fo document (for exaple,
lots of paragraphs without adjustable spaces between them) Knuth's
algorithm becomes a best-fit.
Given its higher cost, maybe it could be used only when it could really
produce a better output.
I don't know how the spec deals with this, but I doubt the spec cares 
which algorithm is used. That said, would it be a good idea to 
determine which algorithm to use based on something in userconfig.xml 
or something? If the Knuth system is more 'expensive' in terms of 
resources, we could make non-Knuth the default, and enable Knuth via a 
config file.

The elements are not
returned from the LMs but pushed from the LM into the pageLM:
   parent.generateElement(new Space(resolveBefore());
   parent.generateElement(new Box(lineHeigth);
I'm not sure it is always possible to do this: sometimes the
representation of a block depends on the properties of a higher level
block. For example:
 outer block
 |
 -
 |   |
  innerinner
  blockblock
12
In order to decide whether there can be a page break between the lines
generated by innerBlock1 and innerBlock2, we must know:
- if inner block 1 has keep-with-next
- if inner block 2 has keep-with-previous
- if outer block has keep-together
This can be done if the outer BlockLM calls receives the elements 
created
by its child, looks at them and adds / removes / corrects; could this 
be
done if the inner BlockLMs directly give their element to the top-level
LM?

BTW, what about your great refactoring of all the knuth code?
Regards,
Luca
Cheers!
Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Page breaking [was: Markers added to the wrong page]

[Finn Bock]

[Luca]
I'm not sure it is always possible to do this: sometimes the
representation of a block depends on the properties of a higher level
block. For example:
 outer block
 |
 -
 |   |
  innerinner
  blockblock
12
In order to decide whether there can be a page break between the lines
generated by innerBlock1 and innerBlock2, we must know:
- if inner block 1 has keep-with-next
- if inner block 2 has keep-with-previous
- if outer block has keep-together
This can be done if the outer BlockLM calls receives the elements created
by its child, looks at them and adds / removes / corrects; could this be
done if the inner BlockLMs directly give their element to the top-level
LM?
I would pass the element on the immidiate parent, which recursively 
passes them on the top-level LM in the direction. For inline, the 
toplevel would be LineLM and for blocks it would be the PageLM.

BTW, what about your great refactoring of all the knuth code?
I do not have the time atm to do the followup and bugfixes, so it will 
have to wait. If anyone also wants to commit it, feel free.

regards,
finn

Re: Page breaking [was: Markers added to the wrong page]

[Luca Furini]

Finn Bock wrote:

>Using your description as a jumping point, here is my ideas for page
>breaking. I suppose it is even more pie-in-the-sky since I haven't yet
>written anything about it.

As I have been doing a few experiments about page breaking, I'm happy to
join in this conversation.

>The algorithm that the PageLM uses are a slightly modified knuth (no
>need to maintain fitnessclass, and with the ability to decide on a break
>when there is N pages of lookahead). The elements return from the LMs
>are boxes (for lines), spaces and penalties.

Note that using the box - penalty - glue representation does not
necessarily involve using Knuth's algorithm.
A first-fit (or best-fit) algorithm could be enough in most situations;
and if there are no adjustable elements in the fo document (for exaple,
lots of paragraphs without adjustable spaces between them) Knuth's
algorithm becomes a best-fit.
Given its higher cost, maybe it could be used only when it could really
produce a better output.

>The elements are not
>returned from the LMs but pushed from the LM into the pageLM:
>
>parent.generateElement(new Space(resolveBefore());
>parent.generateElement(new Box(lineHeigth);
>

I'm not sure it is always possible to do this: sometimes the
representation of a block depends on the properties of a higher level
block. For example:

 outer block
 |
 -
 |   |
  innerinner
  blockblock
12

In order to decide whether there can be a page break between the lines
generated by innerBlock1 and innerBlock2, we must know:
- if inner block 1 has keep-with-next
- if inner block 2 has keep-with-previous
- if outer block has keep-together
This can be done if the outer BlockLM calls receives the elements created
by its child, looks at them and adds / removes / corrects; could this be
done if the inner BlockLMs directly give their element to the top-level
LM?

BTW, what about your great refactoring of all the knuth code?

Regards,
Luca

RE: Page breaking infinite loop

[Rhett Aultman]

A little musing on the infinite loop issue...

It seems that, for the most part, each layout manager turns predominately to its 
children LMs to see what they're up to.  As a result, it's not easy to spot at a high 
level (ala the PageLayoutManager) that some singular element is holding the entire 
works up.  In the case of one of my stripped-down infinite loop tests, it's a single 
string of text that is constantly spilling off the page.  The only indication I can 
seem to locate in code that its TextLayoutManager is not making progress in laying it 
out is that, at every time its getNextBreakPoss() method is called, it can poll itself 
to see what character in its internal array it's starting the positioning at, and 
discover that, call after call, it's making no progress and trying to constantly 
reposition the same string starting at the same character number...every time.

I'm suspecting that, in general, these "low men on the totem pole" are the only LMs in 
any position to spot the abject lack of progress that characterizes the infinite loop. 
 At that point, they need to send a notice up the line that they suspect an infinite 
loop.

Now, here's the hard part as I see it- our users are defining page sequences of 
variable size, and so it just might take many iterations in general to finally reach a 
page with room for the object in question.  Would the correct policy in this case be 
for there to be a callback process from the low-level LMs to send messages up the line 
back to their PageLMs so that they can keep an eye on the page sequencing and, after 
all possible pages have been tried, give up?

Or would an acceptable solution to the maintenance branch (which is a dead-end branch) 
just be to let the cycle run for, say, 20 iterations and, at that time, assume an 
infinite loop and throw an Exception to break the cycle?

-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002 3:56 AM
To: FOP
Subject: Re: Page breaking infinite loop


On Wed, 2002-09-18 at 20:38, Christian Geisert wrote:
> Go for it! (don't forget to assign the bug to yourself)
> 
> By the way .. any comments from you (as a classloader expert ;-)
> on the following bug:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255

If you want to fix that bug why not simply do a null check and maybe try
the system class loader.

> Christian



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Page breaking infinite loop

[Rhett Aultman]

Sounds reasonable.  Depending on certain things, though, the system classloader might 
not be able to find the classes.  I asked the guy in charge of deployment at my 
workplace where we kept FOP under Apache 4.0.4, and he said we kept it in Apache's 
"common-lib" folder, so perhaps the best way to combat this is with documentation?  
Like I said...it's been my experience that, if you put it in the right place, FOP 
works fine under TC 4.0.4

-Original Message- 
From: Keiron Liddle [mailto:[EMAIL PROTECTED]] 
Sent: Thu 9/19/2002 3:56 AM 
To: FOP 
Cc: 
    Subject: Re: Page breaking infinite loop



On Wed, 2002-09-18 at 20:38, Christian Geisert wrote:
> Go for it! (don't forget to assign the bug to yourself)
>
> By the way .. any comments from you (as a classloader expert ;-)
> on the following bug:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255

If you want to fix that bug why not simply do a null check and maybe try
the system class loader.

> Christian



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




<>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Page breaking infinite loop

[Keiron Liddle]

On Wed, 2002-09-18 at 20:38, Christian Geisert wrote:
> Go for it! (don't forget to assign the bug to yourself)
> 
> By the way .. any comments from you (as a classloader expert ;-)
> on the following bug:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255

If you want to fix that bug why not simply do a null check and maybe try
the system class loader.

> Christian



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Page breaking infinite loop

[Rhett Aultman]

I'll make the bug assignment.

As for the bug mentioned, "FOP can't be embedded in Tomcat 4.0.4", I have to say this- 
we've been using various versions of FOP under Tomcat 4.0.4 for a while...at least, 
until my supervisor switched us to Jetty.  Everything ran fine.  I have made no 
*EXPLICIT* attempt at reproducing that bug, but I can make some guesses on what might 
be going on.  I mentioned this in a previous post, but I'll speculate it again- what I 
think is happening in this case is a function of where the FOP classes were getting 
loaded from.  Clearly, this person wasn't packing FOP in a WAR, since if that were the 
case, no class packed in a WAR could get to its own classloader, which would mean web 
applications of all kinds (including some I've written here at FCCI) would have 
experienced this problem in Tomcat 4.0.4.  So, my best guess, without having analyzed 
Tomcat 4.0.4 source, would be that they are putting FOP in a directory that's loading 
classes Tomcat wants to keep protected from other parts of the program being able to 
access.  I suppose that they could load classes with a classloader that would kill the 
classloader reference of the Class object for the sake of internal security.  

Quite why they would want to do this, I have no idea, but like I said, I haven't read 
much TC 4.0.4 source to know.  The bug report says it was "due to a change in 
security," so it just might have something to do with allowing applications in WARs to 
have access to classes loaded by some "library classloader", but denying them access 
to that classloader, which I guess would be a technique to prevent web applications 
from having access to a classloader that has domain over lots of Tomcat internals.  
That seems like a bit of a roundabout to go through, but it might be what's going on.

I can say right now that I suspect I will have enough time this weekend to work on one 
thing we'd like cleared up.  If you guys would rather see the root of this TC 4.0.4 
classloader bug pinned down, I can work on that instead.  I really just want to put my 
effort where it's needed

I'm not sure when I became a classloader expert, but I won't complain. ;)

-Original Message-
From: Christian Geisert [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 18, 2002 2:39 PM
To: [EMAIL PROTECTED]
Subject: Re: Page breaking infinite loop


Rhett Aultman schrieb:
> I'm having a very involved working weekend this weekend, and I'm writing my list of 
>things to do.  There's some openings in it, and I thought I might tackle the infinite 
>loop that occurs in the page breaking test as has been documented in some previous 
>bugs in our Bugzilla.  Before I settled in to that, though, I wanted to make sure my 
>effort wasn't being repeated elsewhere.  I haven't seen anyone resolve the bug, so 
>I'm assuming it's still needing work.  Is anyone else out there working on this, or 
>should I roll up my sleeves and get to it?

Go for it! (don't forget to assign the bug to yourself)

By the way .. any comments from you (as a classloader expert ;-)
on the following bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255

Christian


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Page breaking infinite loop

[Christian Geisert]

Rhett Aultman schrieb:
> I'm having a very involved working weekend this weekend, and I'm writing my list of 
>things to do.  There's some openings in it, and I thought I might tackle the infinite 
>loop that occurs in the page breaking test as has been documented in some previous 
>bugs in our Bugzilla.  Before I settled in to that, though, I wanted to make sure my 
>effort wasn't being repeated elsewhere.  I haven't seen anyone resolve the bug, so 
>I'm assuming it's still needing work.  Is anyone else out there working on this, or 
>should I roll up my sleeves and get to it?

Go for it! (don't forget to assign the bug to yourself)

By the way .. any comments from you (as a classloader expert ;-)
on the following bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255

Christian


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]