RE: Catch-22 with fo:sequence-specifier-alternating

Indeed, the kind of race condition you describe, in which the satisfaction
of one constraint causes the violation of another related constraint (and
vice-versa) is not so uncommon in composition.  For example, it also arises
in handling the placement of footnotes.  Suppose the callout occurs in the
last line of a page, and the amount of text in the footnote is sufficient to
eat up some of the body column's space.  Result: the callout gets shoved to
the top of the next page, thus violating the same-page requirement of
footnote placement.  But moving the footnote to satisfy that constraint then
results in a space deficiency on the original page, which [expletive deleted] the callout
back to where it was in the first place, which again violates the same-page
constraint.  Deadlock.  

Note that such situations do not reflect designer error; on the contrary,
this is an unavoidable consequence of the goals of a general style language,
one of which is to support the expression of abstract design intentions,
without reference to any specific document instance.  If you view a
stylesheet as a network of constraints, then its pretty easy to see that a
style engine will be able to satisfy those constraints for some document
instances, and not for others.

The way for a style language to accomodate such conditions is to provide for
"fallback" constraints in some manner, either predefining them ("violate the
same-page constraint first, then...") or allowing the designer to express
them ("split the footnote across two pages if the callout is on a verso
page; otherwise put two lines on the callout page and violate the
grow-upwards constraint in favor of grow-downwards etc etc").  The latter,
obviously, is a lot more trouble for the language designer.  In practice I
suspect virtually all composition engines just pick a solution - I'm not
aware of any languages that fully address such situations (emphasis on
"fully").  As for XSL, well, maybe version n.

-Gregg Reynolds, inscribing personal opinions, which do not necessarily
reflect those of the XSL WG nor of his employer.  Etc.

> -----Original Message-----
> From: pandeng@xxxxxxxxxxxx [mailto:pandeng@xxxxxxxxxxxx]
> Sent: Thursday, September 23, 1999 9:54 PM
> To: xsl-list@xxxxxxxxxxxxxxxx
> Subject: Catch-22 with fo:sequence-specifier-alternating
> 
> 
> I'm curious as to the nature of the pagination algorithm the XSL
> designers had in mind when they gave page-master-last-even and
> page-master-last-odd properties to fo:sequence-specifier-alternating.
> 
> Consider the following scenario: 
> 
> In a particular flow object tree, page-master-even and page-master-odd
> both specify page layouts that happen to have relatively large
> fo:region-body areas, while page-master-last-even and
> page-master-last-odd both specify page layouts that happen to have
> quite small fo:region-body areas. The formatter processes the flow
> object tree, and finds itself near the end of the document with about
> a half-page of text left to go, with this text to be placed on an even
> page. This amount of text fits just fine in the page-master-even
> layout, but won't fit in the page-master-last-even layouts. 
> 
> The formatter is now faced with a dilemma: It can use the
> page-master-even layout, and fit all of the text, but that means the
> last page of the document will have used the wrong page master. Or it
> can use the page-master-last-even layout, and not fit all of the text,
> but that means a non-last page will have used the wrong page master.
> 
> The above scenario is somewhat contrived, of course, but it points out
> another problem, which is quite real: In general, there is no way to
> know ahead of time whether or not the flow object tree is going to
> "run out" on a certain page. The only way to know for sure is to
> format the flow objects onto the page. But this means that in practice
> nearly _every_ page must be laid out twice, first as a potential last
> page, and then, if it turns out that it wasn't the last page after
> all, as a normal page.
> 
> -Steve Schafer
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list