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
