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

Reply via email to