I'm sorry that I missed your plan. I didn't remember your posting this.

I think your plan would be a good start into refactoring the breaking in
block progression direction. I think it'll need to be clarified WRT
resets/backtracking in case of final decisions on page break, column
handling and intrusion. Your approach seems to create BPs in advance of
which some might be discarded because of later decisions. These will
then be rebuilt based on different circumstances.

I'm somewhat torn between a project plan I have to follow and doing
things right the first time. So I'll apply my changes for now and I'll
keep the whole thing on my todo list with a big exclamation mark. It
could very well be that because of my next tasks (tables and keeps) I
will get back to this sooner rather than later. Another aspect here: I'd
like to have some well visible improvements to the code quickly so it
shows to the outside that the project's not dead like many users think.

We'll see what happens. Thanks for your input and I hope you'll find
some time soon to do some coding yourself.

On 06.02.2005 22:08:40 Simon Pepping wrote:
> Jeremias,
> I do not have much time to look into your problem, so I will just try
> to give a quick answer.
> In my view the current BP setup is not able to generate good page
> break decisions. It only can do a first-fit algorithm. From your
> account, BPs are also overloaded to signal the completion of a page
> while they do not really end an area. Your hack is a hack indeed, but
> from a quick inspection I would say that it properly marks the
> overloaded nature of BPs.
> I have written down a proposal for a different strategy of page break
> decision. I put my description on the wiki,
> I believe it serves
> two goals:
> 1. Enabling smarter page break algorithms.
> 2. Simplifying the addAreas calls, and esp. its iteration over the
> collected BPs.
> I have not had time to implement this, and therefore also no time to
> detect the flaws in my proposal. I would not mind if someone else
> would implement it.
> Regards, Simon
> On Thu, Feb 03, 2005 at 06:19:29PM +0100, Jeremias Maerki wrote:
> > Team, 
> > 
> > I've just checked in markers5a and markers5b which look very closely
> > which marker is added to which page for every block.
> > 
> > As I'm still somewhat in the process of getting to know the layout
> > engine I don't have a quick answer to that although I'm making progress
> > in understanding. Here's what I found out so far:
> > 
> > The reason for the bad markers is the addMarkers call, for example in
> > BlockLayoutManager.addAreas(). When the LM finds out that the next area
> > won't fit on the current page it creates a BreakPoss signalling that
> > state. The problem now is that addAreas() also gets these BreakPoss
> > instances which aren't visible in the generated document but are still
> > generating an (empty) Area (on the page preceeding the one where the
> > Area will really come to rest). That causes one marker too many to be
> > added to a page.
> > 
> > The same BTW applies to addID() calls which also remembers IDs on the
> > wrong pages.
> > 
> > What I'm currently doing is trying to really (!) understand the whole
> > BreakPoss mechanism so I can figure out a reliable way to find out how
> > to avoid this bug. Two possibilities:
> > 1. Don't generate bogus areas at all.
> > 2. Just suppress addMarkers() and addID().
> > 
> > I'm currently wondering if the generated BreakPoss instances should get
> > an additional flag (or two) which controls the generation of the area
> > and the addMarkers()/addID() calls. addMarkers()/addID() may be
> > necessary in certain circumstances while on the other side no area is
> > generated (empty block with only markers).
> > 
> > You can easily see these bogus areas when you output to the area tree
> > renderer or in build/test-results/layoutengine when running the Ant
> > build.
> > 
> > I'll continue investigating but would appreciate any ideas you might
> > have.
> > 
> > Jeremias Maerki
> > 
> -- 
> Simon Pepping
> home page:

Jeremias Maerki

Reply via email to