I'm unsure here. My interpretation comes from two places: 1.) Section 4.8, the last paragraph of [1]:
"The area tree is constrained to satisfy all break conditions imposed. ***Each keep condition must also be satisfied***, except when this would cause a break condition or a stronger keep condition to fail to be satisfied." i.e., keep conditions need to be satisfied. 2.) The definitions of the three keep-[] properties [2] each have a initial value of "auto", meaning "There are no keep-[] conditions imposed by this property." So by default, if the user does not explicitly specify keep properties, e.g., "keep-together.within-page", no text, pictures, etc. are to be kept together on the same page, if they wouldn't already be so due to free-flowing (i.e., first-fit) text. Everything would become free-flowing in order to obey the stylesheet writer's specifications. Just my $0.02. Thanks, Glen [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#keepbreak [2] http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#keep-together --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Where did you find such a suggestion? I'd be > interested to know if > there's a hint in this direction in the spec. I > thought it was up to the > implementation to decide the strategy. > > I think the way we're now taking in our discussion > suggests that we're > not going to do a first-fit strategy at all. If > we're really going down > the two-strategy path we'll probably end up with a > best-fit strategy and > a total-fit or best-fit plus look-ahead. (See > Simon's list [1]) But > that's something we still need to figure out > together. > If we ever have multiple page-breaking options, it can be a user-defined configuration switch. No problem there. Glen > [1] > http://wiki.apache.org/xmlgraphics-fop/PageLayout > > On 02.03.2005 14:48:17 Glen Mazza wrote: > > Just a sanity check here, the XSL specification > seems > > to suggest always the first-fit strategy for page > > breaking *except* where keeps are explicitly > > specified. Am I correct here? And, if so, is > what > > you're planning going to result in an algorithm > that > > will help us do this? > > > Jeremias Maerki > >
