Response below. -----Original Message----- From: Victor Mote [mailto:vic@;outfitr.com] Sent: Friday, November 15, 2002 1:48 PM To: [EMAIL PROTECTED] Subject: RE: Getting breaks: revisited
>>Just to be clear, I should point out that there is not a layout that is impossible to perform. The standard allows (and would have to) implementation-specific handling of what they call "over-constrained" requirements. In other words, requirements can be prioritized and allowed to slip when they are contradictory or "impossible".<< True, and that was what I meant to refer to. Thank you for the clarification. Still, I think that before a decision that something has to give can be made, the layout has to be recognized for being "impossible" under the user-given constraints. I think we're on the same wavelength here. >>From a design standpoint, the best ideas I have seen/heard revolve around some scoring system. I think the HZ program, TeX, and Lout all use this approach. To do this, you would need for each break manager to return not just the best break, but a collection of possible breaks with some ranking mechanism. Ideally, somebody at the highest level (page-sequence) decides what is best, based on information that percolates up from the lower levels. This implies to me that we can see the entire page-sequence sub-tree at one time, which may not be true in our SAX event-based model. It seems that the page-sequence would attempt to lay itself out using the "best" breaks that came up from sub-nodes, then adjust if over-constrained, perhaps with the concept of a layout Plan or Proposal.<< I like the fundamentals of this idea as well, but I also can't help but wonder if there might not be other options. Perhaps a system where LMs report to their parents on how well they're doing their jobs, allowing issues to percolate up the tree? If the LM system can go back to past breaks as Keiron was talking about, then it might be possible to lay everything out as per normal and, when an issue gets raised, to revert back to some past break, analyze what caused the issue, remove an offending constraint, and go back to work. Granted, this is not as cool a solution as a planned layout system (ala your suggestion), but if generating a layout plan requires more omniscience than the SAX event-based model provides, then a sort of "rollback" mechanism may be a sufficient alternative. Hm...and what about a fusion of the two. If the LMs submitted potential breaks and some sort of information about the constraint that has to be removed to use them, and this information was held on to, then at some point down the line in processing, FOP could rewind back to a past break and select from the "next best" list...essentially meaning that FOP flies blind until there's a problem, then goes back and examines a plan of alternate routes, and after picking one, goes with it and gets back to work as usual. Is any of this making sense, or is this all just a bunch of hoohah? >>I know it is easier said than done, and may already be done. Please pardon my ignorance of the current design. I would offer it as my $.02 worth, but someone would want a nickel change ($.05).<< I dunno. I was playing around with a HEAD snapshot a few weeks back, and did run one of the infinite looping bugs on bugzilla against it and found that I could get the LMs to lock in a loop by doing something as simple as creating a block containing unhyphenatable text that was larger than the bodies of all the specified pages. This tells me that if there is a system in place to protect against over-constrained layouts, it's not there yet. I'd played with a fix on it that allowed the LM closest to the action (a TextLayoutManager) keep track of how many characters in its string it had successfully laid out and, if it didn't progress after 100 tries, halting. Obviously, we don't want to go with that. -- Rhett. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
