On 01.06.2006 18:37:44 Apache Wiki wrote: <snip/> > + === Comments on the Article === > + * It is assumed that paragraphs have already been broken into lines. I see > two restrictions implied by such an assumption: > + * it won't be possible to apply this method to sequences of pages of > different widths;
That's a point that becomes more important now. We've had an incident on fop-users lately and one of my clients (not the same as for the fop-users incident) has recently upped the priority for this. So, we should try to make this possible. How exactly this is to be done I don't know, yet. Looks like I have to struggle to keep up with you. But at least we don't build any additional barriers if we don't keep this out of the pictures again. <snip/> > + * It is possible to tweak the algorithm to allow pages which are not > entirely full (yet still with balanced facing pages). Indeed sometimes it is > impossible to find a layout which respects all of the contraints (full pages, > no widow/orphan, keeps...) The FO spec does not seem to allow for relaxing the widow/orphan setting. However, in 4.8 it allows to relax keep conditions. Maybe even for "always"? But I'm not sure about that. Anyway, I think that only book-like documents will run into the problem that no layout can be found without relaxing some rules. Given that TeX relies an manual modifications/hints (AFAIK) to improve the layout situation, I think it is valid to leave it up to the user to do something similar in FO. Relaxing conditions may not be welcome by certain users except if they allowed it themselves. > + * Although the algorithm assumes that each line of text is separated by > some glue, it only relies on their minimum and maximum values. It doesn't > take the optimal value into account. And as it tries to minimize the total > number of pages, we may end up with spaces systematically set to their > minimum value. Indeed, if there are no before-floats nor footnotes, it will > obviously be the case. I think this may break the XSL-FO spec; at least we > can expect complaints from users. Yes, I think it would be bad if everything would be set to minimum values. I know at least one real-life example where this would be highly unwelcome. > + * Related to this: the possibility to break a page is binary: allowed or > not. This constraint is IMO too heavy: although an orphan is undesirable, it > should be acceptable when no better layout is possible. In fact this > algorithm doesn't utilize the whole range of penalty values available in the > Knuth model; only two are allowed, 0 and infinity. As indicated above FO seems to be pretty strict about the widow/orphan condition. I wonder how many (real-life) documents would actually result in problematic layouts to make it worthwhile to invest too much time in solving something that a user could easily improve himself with some hints. > + > + === Resulting Thoughts === > + The algorithm cannot be used directly as it is presented, mainly because of > the two last items of the previous section. However, it provides a strong > basis IMO. Some points: > + * There may be cases where it is impossible to find a layout which > fulfills all of the criteria. We may consider to perform a second pass with > some relaxed properties, but: > + * can we afford the additional computation time? For book-style documents, in many cases, yes. For business-documents, no, but I think the problem will not even present itself there, usually. We should simply try to make sure that simple documents like invoices, policies and business letters don't suffer too much from a complex algorithm tailored to book-style documents. Speed vs. functionality problem. Note that in the past, investments into FOP have often come from the business docs side, and less from the book docs side. > + * which properties to relax, in which order? Possibilities: > + * orphans/widows properties; but contrary to TeX, in XSL-FO it is only > possible to define the number of orphans/widows, not a penalty associated to > them. > + * keep properties: those may have integer values that allow for some > flexibility > + * page fullness: AFAICT the XSL-FO spec does not impose that pages be > full. And as explained earlier, the algorithm can use this possibility. > According to the article this becomes quite easy to find a layout just by > allowing pages to be only 90% filled. This might even become possible to > perform only one pass (which would ideally find the optimal pagination when > possible, and one with some percentage of fullness otherwise). > + * There is a free bonus implied by this algorithm: this should give pages > which are vertically justified [[FootNote(don't forget to have a look at > Luca's LayoutExtensions on this issue)]]. That is, the bottoms of pages > should coincide with the bottom of the region-body area. The only exception > would be in "relaxed mode", when a percentage of fullness is introduced. Vertical justification is certainly something welcome even though it's an extension for XSL-FO. And at any rate it should be an optionally enabled feature. <snip/> Jeremias Maerki
