Date: Fri, 29 Mar 2024 09:16:50 +0000 (UTC) Message-ID: <686526466.754.1711703810323@cwiki-he-fi.apache.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_753_1305166020.1711703810322" ------=_Part_753_1305166020.1711703810322 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page analyzes aspects around the space-resolution rules def= ined in 4.3.1 in the spec.
Ple= ase note that this page was not updated after the clarification about space traits by the= XSL FO SG!!!
Legend:
Both spaces and conditional lengths (borders and padding) have condition= al elements but they behave a little differently. For spaces the conditiona= lity controls whether a space-specifier has effect at the beginning or = end of a reference-area or a line-area (XSL 1.0, 4.3). For padding and= borders the conditionality controls if the padding should be 0 or reta= ined if its associated edge is a leading-edge in a reference-area for areas= generated from this formatting object that have an is-first (or is-last) v= alue of "false" (XSL 1.0, 7.7.9 and 7.7.31). The difference: While the= conditionality applies to every space-specifier regardless of the is-first= /is-last status of the generated area, it does matter for conditional lengt= hs where the conditionality only applied if it's not the first or last gene= rated area by a formatting object.
Like border and padding, space-before and space-after apply to every are= a generated by a formatting object, not just the first and the last (XSL 1.= 0, 7.10.5). This is further illustrated by the general area model described= in XSL 1.0, 4.2.3.
In the most general situation, the elements needed to represent the spac= e between two block-level formatting objects (say block 1 and block 2) are:=
glue #1 - penalty - glue #2 - box - PENALTY - glue #3
with:
Note that glue #1 is a feasible break too, but it won't never be chosen = as a page break as the following penalty is much better: it adds the stretc= h and shrink of glue #1 to the available stretch and shrink of the page, so= the adjustment ratio will be smaller and the demerits fewer. (Note by JM: = I observed that the glue often doesn't have any stretch and shrink and ther= efore becomes a likely break point. I'll insert an infinite penalty before = glue #1 into the pattern.)
The sequence of elements can be simplified in some particular situations= .
If the resolved space after block 1 and the resolved space before block = 2 are both conditional, one element is enough:
glue A
where glue A is the resolved space between block 1 and block 2 when ther= e is no break.
If there is a keep condition between the block 1 and block 2, a penalty = is needed in order to prevent a page break:
penalty glue A
where the penalty value can be +inf or a finite value.
The penalty could be added even if there is not a break condition betwee= n the blocks: this assures the presence of a feasible break, regardless of = the previous element in the sequence.
If the resolved space after block 1 is conditional, i.e. it is discarded= if the blocks are parted, the sequence can be simplified a little:
glue B - box - PENALTY - glue C
where:
As in the previous situation, a penalty with a finite value can be added= at the beginning of this sequence in order to assure the presence of a fea= sible break, or to represent a keep condition.
If the resolved space before block 2 is conditional, i.e. it is discarde= d if the blocks are parted, the sequence can be simplified much:
glue D - penalty - glue E
with:
In this case there is no need to have an initial penalty, as the "prefer= red" feasible break is the penalty element; should there be a keep conditio= n, its value will be modified.
See the SpaceResolution Examples page.
See also BreakPoss= ibilityBuilding for more information about the interaction of space, bo= rders and padding when building break possibilities with Knuth elements.
Ideas for the implementation can be found here: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/= 200509.mbox/%3cPine.LNX.4.62.0509091354320.29316@malatesta.cs.unibo.it%3e= a> http://mail-archives.apache.org/mod_mbox/xml= graphics-fop-dev/200509.mbox/%3c20050910195456.GC5644@oranjetip.leverkruid.= nl%3e http://mail-archives.apache.org/mod_m= box/xmlgraphics-fop-dev/200509.mbox/%3c20050911101013.GA4716@oranjetip.leve= rkruid.nl%3e
It appears that border and padding handling needs to taken into consider= ation, too, as they can both have conditionality elements. Following Simon'= s suggestion for creating space objects that are placed into the returned e= lement list, objects for border and padding have been created, too. A new L= istElement class forms the new base class for KnuthElement and for the new = UnresolvedListElement which is in turn the base class for a number of class= es:
All these elements will be inspected by the SpaceResolver class where th= e space resolution and the handling of the conditional lengths is handled. = The output is a modified element list with no unresolved elements. SpaceRes= olver.resolveElementList() is called to resolve all unresolved elements pri= or to the breaking process.
Two special Position descendants are used to hold the resolved space-spe= cifier so the LM that will be generating the space will have all the necess= ary information in addAreas(). After all, a single LM does not know with wh= ich other space from other LMs his space interacted. SpaceHandlingBreakPosi= tion is used to notify the involved layout managers about the resolved spac= e specifiers and conditional lengths in a break situation. SpaceHandlingPos= ition does the same for the no-break situation. The layout managers are alw= ays informed through the ConditionalElementListener interface just before a= part (page/flow/line) is painted (addAreas stage) by calling the SpaceReso= lver.performConditionalsNotification().
In the case where a penalty holds a special Position instance (like for = tables) this Position has to be exchanged for the SpaceHandlingBreakPositio= n, but this class will hold the original Position object which will be rest= ored by the parent LM's addAreas() method after all layout managers have be= en notified.
Reminder: an empty block (<fo:block/>) will not s= plit a space-sequence, but BlockStackingLayoutManager currently adds a box = (w=3D0) to the element list so an "id" present on the empty block will stil= l be registered by a later addAreas(). This will interfere with the correct= detection of space-sequences. This will need to be looked at, eventually. = (Case 3d under 4.2.5 Stacking constraints!) See: block_space-before_space-a= fter_8.xml
Other issues:
Someone seems to have started space-start|-end support (see SpaceSpecifi= er and stuff in LayoutContext) long ago, before we introduced Knuth approac= h. We'll have to revisit that since this has currently no effect on the inl= ine element list but only on the areas produced. That means that if you spe= cify a space-start on an fo:inline you will get a space but line breaking w= ill be off. I hope we'll be able to use the stuff I'm building for inline-l= evel spaces, too.