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.
home page: http://www.leverkruid.nl