On Tue, Apr 04, 2006 at 11:26:38PM +0800, Manuel Mall wrote: > On Tuesday 04 April 2006 03:38, Simon Pepping wrote: > > Hello, > > > <snip/> > > Simon, > > very interesting approach to the problem. You obviously gave this quite > a significant amount of thought. > > While your approach may simplify many Knuth sequences for the less > common (or more convoluted) cases you clearly state that the only case > where the original Knuth algorithm has no solution is this "blasted" > <space><border><space> case where the XSL-FO rules say we have to > suppress the space before the border (assuming the usual property value > settings). > > The solution in the context of the Knuth algorithm I had in mind is to > do a simple re-ordering of the generated elements. Instead of > generating the Knuth sequence for <space><border><space> we generate a > sequence matching <border><space><space> which would suppress all > spaces if a line break is created. However, if the spaces are not > removed we render it as <space><border><space>. While I have not looked > into the details of how this could be implemented in the current FOP > code it didn't strike me as overly complicated. > > On the other hand your solution may well make such workaround > unnecessary. IMO, your best bet to prove that it works is to branch the > FOP code and plug your new model in. As you have outlined the mapping > from old to new that shouldn't be too invasive.
I do not like workarounds very much. Often I prefer to reconsider the basis. And it is a nice project to try to make a variant of Knuth's method work. I will first expand by implementation with a method to easily feed test cases and with Knuth and Plass' bells and whistles. Then I may try my hand at an implementation in a FOP branch. But that will take a while because I have only a limited amount of time to spend on FOP. Simon -- Simon Pepping home page: http://www.leverkruid.nl