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]

Reply via email to