[Accessibility conventions are described at the bottom of the page]

10. Breaks, keeps, spacing, borders and backgrounds
[> 11.][< 9.2.11][^^^]
10.0 Spacing and arrangement constraint definition
[> 10.1][> 11.][< 10.][^^][^^^]
An area's placement is governed by XSL-FO stacking rules and the area's traits refined from object properties
[[1] - at the block level in a page
[[2] - before-float-reference-area
 [2] - normal-flow-reference-areas (page columns)
 [2] - footnote-reference-area
][1] - at the line level in a block
[[2] - lines are generated by the formatter, not the stylesheet
 [2] - different line-stacking strategies are available to be specified
][1] - at an inline-level in a line
[[2] - characters, graphics, etc.
]]
Areas that are stacked normally are stacked in the pertinent progression direction
[[1] - page-level reference areas stack in the block-progression direction
 [1] - lines and table rows stack in the block-progression direction
 [1] - page column, table column and inline areas stack in the inline-progression direction
]
The "natural" stacking of areas may produce typographically unpleasant results
[[1] - initial values implement common-sense formatting control for consistent presentation
 [1] - many traditional conventions break the behavior of the initial values
[[2] - e.g. needing to keep a heading in the body on the same page as the first paragraph to which the heading applies when the naturally occurring page break would otherwise come between the two items
 [2] - necessary sometimes to override the physical arrangement of information implied by the initial values for area properties
]]
Conditionality and precedence can eliminate areas from being rendered
[[1] - can prevent the unnecessary use of inter-block spacing when pagination renders a block without an adjacent sibling
[[2] - e.g. a block forced to the top of a new page doesn't always need the space defined for between blocks to be rendered
][1] - formatting special cases can be accommodated with simple specifications of intent
[[2] - the formatter determine the applicability of spaces based on object properties
 [2] - the transformation process can ascribe properties easier than determining space behaviors
]]
Numerous properties are available to specify these nuances of layout
[[1] - arbitrarily breaking the flow of content to a new column or page
 [1] - maintaining a minimum number of widow and orphan lines of a block on a page
 [1] - keeping information together in the same reference area
 [1] - drawing borders around information
 [1] - painting backgrounds behind information
]
10.1 Break conditions
[> 10.2][< 10.0][^^][^^^]
10.1.1 Breaks
[> 10.2][> 11.][< 10.0][^^][^^^]
One often needs to arbitrarily continue flowing information at the start of the next line, column or page
[[1] - if no change to static content, one need not use a new page sequence to begin on a new page
 [1] - may need to continue at the top of an even page number or odd page number
[[2] - may introduce a blank page that can be accommodated in the page sequence master
]]
Breaking at the line level can be done with an empty <[block]> object
[[1] - adds a block of zero lines to the flow, interrupting the block-progression-direction
 [1] - <block/> behaves somewhat like the HTML <br> element
 [1] - multiple breaks in a row do not create multiple lines as in HTML
[[2] - the areas created by the blocks do not have any dimensions
][1] - can be nested inside of a block of lines without being considered an error
 [1] - not appropriate for typical program listings or other monospace presentations
[[2] - see discussion of preservation of white space in [Preserving white space - Section 4.2.4]
][1] - <block><leader/></block> creates an empty line
[[2] - spaces in the block would get collapsed by default property values
 [2] - the default pattern for a leader is constructed of spaces that are not collapsed
]]
Breaking at the column or page level can be done with the [break-before]= and [break-after]= properties on a block
[[1] - the block may be empty
 [1] - can specify to the next column
 [1] - can specify to the next page
[[2] - regardless of page parity
 [2] - to the next even or odd page
]]
Specifying a break does not mean forcing a break
[[1] - the property specifies a condition to be met, not an action to be performed
 [1] - if the information already satisfies the break requirement, nothing is added to the rendering of the flow
]
Conditionally breaking lines
[[1] - sometimes necessary to display content as a whole, but provide break points for the flowing algorithm to accommodate narrow margins
[[2] - e.g. displaying long URL or URI addresses in narrow-width table cells
 [2] -
http://www.mycompany.com/homePageEnglish.htm
][1] - hyphenation could introduce arbitrary dashes that materially affect the displayed result
[[2] -
http://www.mycompany.com/homePage-
English.htm
][1] - using a zero-width space (&#x200b;) will be invisible if no break needs to happen
 [1] - provides a place to break the line if there is no room for the entire line
[[2] -
http://www.mycompany.com/&#x200b;homePageEnglish.htm

http://www.mycompany.com/
homePageEnglish.htm
]]
10.2 Widows and orphan control
[> 10.3][< 10.1.1][^^][^^^]
10.2.1 Widows and orphans
[> 10.3][> 11.][< 10.1.1][^^][^^^]
The natural breaking of blocks of lines may result in an unpleasant appearance
[[1] - seeing only one line of a block at the bottom or top of a page may leave the impression there is only one line of information
[[2] - having two or more lines can leave the better impression there is more than just those lines in the block on the other side of the page break
][1] - the effect is magnified when the block is justified
[[2] - the last line of a justified block is typically not justified
 [2] - when positioned at the top of a page, the unjustified last line may look more like a heading
]]
Widows are the lines at the end of a block overflowing to the start of a page
[[1] - can specify the minimum number of line-areas allowed in the first area of the page generated by the last lines of a block
 [1] - initial value of [widows]= is "2"
]
Orphans are the lines at the start of a block overflowing at the end of a page
[[1] - can specify the minimum number of line-areas allowed in the last area of the page generated by the first lines of a block
 [1] - initial value of [orphans]= is "2"
]
[Figure 10.1: Widows and orphans of a block
A two column page of blocks is greeked in the image.
The last block of the first column straddles the column break such that the first three lines are in the left column and the last four lines are in the right column.
The rows of the block that are in the left column are labeled orphans. The rows of the block that are in the right column are labeled widows.
]
Breaking happens to the next logical reference area
[[1] - column break if multiple columns in the page
 [1] - a page break if at the end of the last column
]
The entire block is moved to the next reference area if neither condition can be satisfied
[[1] - widows and orphans are not tested until there are widow lines to be accommodated
 [1] - the entire block is moved when there are not enough orphan lines remaining after accommodating the minimum number of widow lines
]
The samp/widows.fo file illustrates the setting of different values:
[Figure 10.2: An illustration of widows and orphans
Six columns of text are shown as three groups of two columns. Each pair is labeled as a test and contains a block of six lines poised to wrap over the bottom of the column. The text of the book describes what is seen in each of the three pairs
]
Note the following regarding the three examples of the six-line block wrapping:
[[1] - in each test the values of widows and orphans ("W=" and "O=") are different to illustrate the behavior for a six-line long block that wraps at the end of each column
 [1] - in Test 1, the widows specification is 0 which is less than or equal to the actual one widow line in the block
[[2] - the block is left untouched and shows what would result when widows and orphans are not defined
 [2] - remember when not specified the values are defined as "2", not "0"
][1] - in Test 2, the widows specification is 4 which is greater than what would be only one widow line in the block as in Test 1
[[2] - three orphan lines are moved to the next column to satisfy the widow count
 [2] - the remaining orphan count of 2 does satisfy the specified orphan count of 0
][1] - in Test 3, the widows specification is 4 which is greater than what would be only one widow line in the block as in Test 1
[[2] - three orphan lines are first moved to the next column to satisfy the widow count, reducing the orphan count to two, as in Test 2
 [2] - the remaining orphan count of 2 does not, however, satisfy the specified orphan count of 4, so all remaining orphans are then moved to the next column as well
]]
10.3 Keep conditions
[> 10.4][< 10.2.1][^^][^^^]
10.3.1 Keeps
[> 10.3.2][> 10.4][> 11.][< 10.2.1][^^][^^^]
Can prevent information from separating over line, column or page contexts
[[1] - line-oriented keeps for inline-level constructs only
[[2] - use keep.within-line= for the line context
][1] - column- and page-oriented keeps for block-level constructs
[[2] - use keep.within-column= for the column context
 [2] - use keep.within-page= for the page context
]]
Overriding widows and orphans with the [keep-together]= property
[[1] - keeping descendants together
 [1] - adding a context break to the flow before an area whose entire content will not fit within the [keep-together]= component context
]
Injecting context breaks with the [keep-with-previous]= and [keep-with-next]= properties
[[1] - keeping siblings together
 [1] - adding a context break to the flow before an area when
[[2] - the following area has a [keep-with-previous]= property component and both areas will not fit within the component context
 [2] - the area has a [keep-with-next]= property component and both areas will not fit within the component context
]]
Relative strengths of keeps can be specified to ensure "more important" areas are kept together when "less important" areas cannot be kept together
[[1] - e.g. safety publishing where a list of steps is attempted to be kept together
[[2] - there may be warnings found in the list of steps
 [2] - if the steps cannot be kept together, the more important blocks associated with the warning are to be kept together
]]
[keep-together]= is inherited and is applied to all areas of influence by the formatting object
[[1] - the .within-line compound component of [keep-together]= is implicitly specified if not explicitly specified as otherwise
 [1] - inline areas in the block will inherit the .within-line component and apply it to the line-areas returned, usually causing undesirable results
 [1] - text needs [keep-together]="auto" to undo the setting by the ancestor
[[2] - alternatively, it is easier to just use .within-page= or .within-column= on the ancestor
]]
10.3.2 Examples of keeps
[> 10.3.3][> 10.4][> 11.][< 10.3.1][^][^^][^^^]
Consider the following "before and after" of not using keeps and then using keeps:
[Figure 10.3: Examples of keeps
Two pages are shown, each with two columns of the same data. On the page on the left the nested block of lines is partially contained at the bottom of the left column and the top of the right column. On the page on the right the nested block of lines is wholly contained at the top of the right column.
]
[Example 10-1: Keeping a group of areas together in a reference area The following markup from samp/keeps.fo illustrates controlling the keep for descendants:
01  <layout-master-set>
02   ...
03   <region-body region-name="frame-body" column-count="2" .../>
04   ...
05  </layout-master-set>
06   ...
07  <flow flow-name="frame-body" font-size="40pt">
08   <block break-before="page">New page</block>
09   <block>This is a test</block>
10   ...
11   <block>This is a test</block>
12   <block>This is a block
13   <block>Block in block</block>
14   ...
15   <block>Block in block</block>
16   End block</block>
17   <block>This is a test</block>
18   ...
19   <block>This is a test</block>
20   <block break-before="page">New page</block>
21   <block>This is a test</block>
22   ...
23   <block>This is a test</block>
24   <block keep-together.within-column="always">This is a block
25   <block>Block in block</block>
26   ...
27   <block>Block in block</block>
28   End block</block>
29   <block>This is a test</block>
30   ...
31   <block>This is a test</block>
32  </flow>
]
Of note:
[[1] - the lines reading "Block in block" spread over the column break on page 1
 [1] - these lines are kept together within the column on page 2
]
Consider the following "before and after" of not using keeps of siblings and then using keeps:
[Figure 10.4: Examples of sibling keeps
Two pages are shown, each with two columns of the same data of people's names. On the page on the left the heading of the third collection of names is at the bottom of the left column and lines of the collection are at the top of the right column. On the page on the right the heading and lines of the third collection of lines are wholly contained at the top of the right column.
]
Note how the space at the head of each reference area is conditional and is, therefore, discarded.
[Example 10-2: Keeping a group of areas together in a reference area The following markup from samp/keeps2.fo illustrates controlling the keep for siblings:
01    <block space-before="1.5cm" space-after="1.3cm"
02   font-weight="bold">L</block>
03   <block space-before=".2em">Lee, Nancy</block>
04   <block space-before=".2em">Lee, Ian</block>
05   <block space-before=".2em">Lee, Mathew</block>
06   <block space-before=".2em">Lee, Allison</block>
07  
08   <block space-before="1.5cm" space-after="1.3cm"
09   font-weight="bold">P</block>
10   <block space-before=".2em">Prole, Diane</block>
11   <block space-before=".2em">Prole, Mark</block>
12   <block space-before=".2em">Prole, Connor</block>
13   <block space-before=".2em">Prole, Sydney</block>
14  ...
15   <block space-before="1.5cm" space-after="1.3cm"
16   keep-with-next.within-column="always"
17   font-weight="bold">L</block>
18   <block space-before=".2em">Lee, Nancy</block>
19   <block space-before=".2em">Lee, Ian</block>
20   <block space-before=".2em">Lee, Mathew</block>
21   <block space-before=".2em">Lee, Allison</block>
22  
23   <block space-before="1.5cm" space-after="1.3cm"
24   keep-with-next.within-column="always"
25   font-weight="bold">P</block>
26   <block space-before=".2em">Prole, Diane</block>
27   <block space-before=".2em">Prole, Mark</block>
28   <block space-before=".2em">Prole, Connor</block>
29   <block space-before=".2em">Prole, Sydney</block>
]
Of note:
[[1] - on page 1 the heading for the third group of names is in a different column than the names
 [1] - on page 2 the heading for the third group of names is kept together with the names
]
10.3.3 Keep strength
[> 10.4][> 11.][< 10.3.2][^][^^][^^^]
The strength of the keep is specified in the property's value
[[1] - "auto" indicates no keep condition imposed
 [1] - "integer-number" indicates a relative keep strength that can be ignored
[[2] - ignored without overflow condition if the keep area doesn't fit
][1] - "always" indicates a keep that cannot be ignored
[[2] - implies an overflow condition when if the keep area doesn't fit
][1] - consider the situation where the pieces of a warning notice have to be kept together within a set of blocks that would be nice to keep together but may not fit on a page
[[2] - the keep of the warning components would have a higher value than the keep of the set of blocks
]]
A keep is attempted to be fit first within what remains within the context
[[1] - if a keep doesn't fit what remains, it begins within the next context (e.g. next column or next page)
 [1] - a keep is ignored if the amount being kept doesn't fit an entire context
[[2] - when ignored, the keep's content is flowed as if there was no keep specified
 [2] - does not begin at the start of the next context, but after the last flowed area
][1] - the keeps of next higher strength within the flow of the keep being ignored are attempted to be kept together
[[2] - any keeps of lower strength are ignored as that strength has already been addressed
][1] - the keep of the next higher strength is then ignored if the length of that keep's flow cannot fit within the context
[[2] - that keep's content is flowed as if there was no keep specified
][1] - a keep of "always" is never ignored and if the areas do not fit in the context, an overflow condition is triggered
]
The size of the flow for a keep doesn't impact on the choice of page geometry
[[1] - a page-level keep will be tested on the next page geometry chosen by page sequencing
 [1] - a smaller page geometry is not simply ignored if it cannot accommodate the information in the keep and a subsequent page happens to fit the content
 [1] - the choice of page geometry is solely based on page sequencing and never on flow
]
Explicit break conditions are stronger than any keep conditions
[[1] - a keep is ignored if a break is specified
]
Consider two situations where keeps are allowed to be ignored and not allowed to be ignored:
[Figure 10.5: Keep strength
The following text describes the diagram in detail.
]
Of note:
[[1] - for each of the two examples, the blocks on the left depict the blocks in the flow, while the pages on the right depict where the blocks end up on the pages
 [1] - the pages are depicted with the odd page numbers on the right and the even page numbers on the left as is typical in left-to-right writing systems
]
In this example, each labeled block includes an area with that label plus the areas of the labeled blocks found therein
Using a numeric value allows the keep to be ignored
[[1] - A has no keep and flows as usual
 [1] - B has keep="2" and contains C, F, and G
[[2] - all of B is longer than what remains on the first page, so the second page is used
 [2] - because it doesn't all fit on the second page, the B keep is "broken" and so ignored
[[3] - its content is flowed on the second page as if no keep was specified for B
]][1] - C has keep="1" and contains D and E
[[2] - though all of C would fit on the next page, the keep strength specified is less than what has already been rejected, so the keep has no force and is ignored as if no keep was specified for C
][1] - D has no keep and flows as usual
 [1] - E has keep="3" and doesn't fit on the rest of the second page
[[2] - the keep strength is higher than what has been rejected, so it is respected
 [2] - content is placed on the third page
][1] - F has keep="3" and doesn't fit on the second page
[[2] - the keep strength is higher than what has been rejected, so it is respected
 [2] - content is placed on the fourth page
][1] - G has no keep and flows as usual
 [1] - H has keep="1" and doesn't fit on the rest of the fourth page
[[2] - it hasn't been part of any keep that has been rejected, and it fits in its entirety on a page, so it is moved to the next page
][1] - I through L do not break over a page so their keep values are not considered
]
Using "always" does not allow the keep to be ignored
[[1] - X has no keep and flows as usual
 [1] - Y doesn't fit on the remainder of the first page,
[[2] - because of the "always" it begins on the second page
 [2] - because it is longer than the second page, an overflow condition exists
[[3] - that which doesn't fit is lost
]][1] - Z has no keep and flows as usual
[[2] - ends up at the start of the third page because the second page is full
]]
10.4 Control of the spacing between areas
[> 10.5][< 10.3.3][^^][^^^]
10.4.1 Spacing, conditionality and precedence
[> 10.4.2][> 10.5][> 11.][< 10.3.3][^^][^^^]
Many components of compound properties specify the width of the space or border before or after formatting objects
[[1] - [space-before]= and [space-after]= for block-level constructs
 [1] - [space-start]= and [space-end]= for inline-level constructs
 [1] - components offer fine-tuned control over behaviors
[[2] - length.optimum= for the preferable amount of space
[[3] - using the shorthand property without a sub-field sets the optimum to the shorthand value
][2] - length.minimum= and length.maximum= for the limits to the actual amount of space
[[3] - not specifying the limits implies the limits do not vary from the optimum
][2] - length.conditionality= for the discarding of unwanted space
[[3] - at the beginning or termination of reference areas
 [3] - also for the discarding of unwanted border widths
][2] - length.precedence= for the arbitration of conflicting space
[[3] - where abutted space specifications are not desired
]][1] - spacing specifications are conditions to be met, not actions to be performed
[[2] - makes stylesheet writing easier by allowing redundant specifications for adjacent areas
]]
Can prevent border, padding and spacing from being used in certain conditions
[[1] - the pagination of flow may result in space specifications leading or trailing in reference areas
[[2] - e.g. discard the space specified before a paragraph when the space is at the top of a page break
[[3] - the stylesheet generating the blocks for paragraphs cannot know where the page breaks will occur in order to turn off the space specification
 [3] - the default is to discard spacing used at the beginning or termination of a reference area
]][1] - it is often easy to write the stylesheet to always specify spacing and arbitrate between two coincident space specifications
[[2] - e.g. arbitrate between a space specified before paragraphs in a section and a space specified after the title of a section
[[3] - it may not be desirable to have the two spaces combine to too large a space before the first paragraph
]]]
Conditionality dictates whether space specifications are discarded
[[1] - the value "retain" can be specified to change the initial value of "discard"
 [1] - all contiguous space specifications that can discarded that are flowed to the start or to the end of a reference area are suppressed
[[2] - each such area's size in the tree is set to zero
][1] - all space specifications after the first non-discarded area (either space, padding, border, or content) and before the last non-discarded area are not suppressed as a result of conditionality
[[2] - may be suppressed as a result of precedence or optimum size
]]
Precedence dictates arbitration between adjacent space specifications
[[1] - e.g. the [space-after]= of a given block is adjacent to the [space-before]= of the following block
 [1] - an integer value (default is zero) is used for arbitration of precedence between adjacent space specifications
[[2] - all unsuppressed areas whose precedence is less than the highest precedence integer value are then suppressed
][1] - the value "force" will protect an unsuppressed area from being suppressed due to precedence
]
Optimum values are used for arbitration between those with equal precedence
[[1] - all unsuppressed areas whose optimum value is less than the greatest optimum value are then suppressed
]
Resolved minimum and maximum are derived from all remaining unsuppressed areas
[[1] - by arbitration described above all have the same (greatest) optimum value
 [1] - resolved minimum is the greatest of all minimums
 [1] - resolved maximum is the least of all maximums
]
[Figure 10.6: Optimum size and precedence arbitration
Two pairs of adjacent blocks are shown as examples of arbitration.
On the left, the upper block has only a [space-after]= property of "y" (representing a length of "y"), while the lower block has only a [space-before]= property of "x". The value of "y" is greater than the value of "x", therefore the distance between the two blocks is "y".
On the right, the upper block has a [space-after]= property of "y" (representing a length of "y"), and a space-after.precedence= of "1," while the lower block has a [space-before]= property of "x" and a space-before-precedence= property of "2". The precedence of "x" is greater than the precedence of "y", therefore the distance between the two blocks is "x".
]
10.4.2 Character spacing
[> 10.5][> 11.][< 10.4.1][^][^^][^^^]
Can loosen or tighten the spacing between characters using [letter-spacing]=
[[1] - a positive value is in addition to the normal spacing, resulting in expanding the text
 [1] - a negative value is taken away from the normal spacing, resulting in compressing the text
]
Some formatting effects are unexpected due to the font:
[[1] - the apparent spacing between letters can be effected by special features of the font
]
[Figure 10.7: The effects of font on apparent spacing
The phrase "Page 1 of 2" is shown at high magnification. The letter "2" is obviously closer to the letter "f" than the "1" is to the "o".
]
Consider the above example:
[[1] - normal spacing is used which might give the impression characters are equally spaced
 [1] - the letter 2 is closer to the word "of" than the letter 1
[[2] - this may give the impression the formatter is not doing is job properly
][1] - the area boxes shown in the bottom half of the image indicate the inter-character spacing to be identical
 [1] - the digit 1 sits loosely inside its font box with a gap between the black of the digit and the edge of the box
[[2] - this is necessary for numerical reports to ensure columnar digits align
][1] - the digit 2 sits tightly inside its font box with no gap at the left of the black of the digit
 [1] - the letter "f" in this font spills over its font box into the following space area
[[2] - this is a design aspect of the letter for the font
][1] - the character edge separation between the black of the "1" and the black of the "o" ends up being much larger than that of the black of the "f" and the black of the "2"
]
10.5 Border specifications
[> 10.6][< 10.4.2][^^][^^^]
10.5.1 Borders
[> 10.6][> 11.][< 10.4.2][^^][^^^]
Both block and inline areas can have the border visible using a non-zero border width
[[1] - separately specified properties on each of before, after, start, and end sides
[[2] - border-before-*=, border-after-*=, etc.
][1] - shorthand properties specified using border-*=
 [1] - *-width= (precedence given to wider widths in coincident table borders)
[[2] - two computed values based on specified or defaulted component settings:
[[3] - *-width.length (from resolution of sizes and precedence)
 [3] - *-width.conditionality= (compound component)
[[4] - "discard" or "retain" applies to the border of split areas
 [4] - column and page reference areas for block areas (including table cells)
 [4] - line reference areas for inline areas
]][2] - a simple *-width="length" length value
[[3] - implies *-width.conditionality="discard"
 [3] - user-agent dependent values of "thin", "medium", and "thick"
]][1] - *-style= (listed in precedence when width equal for coincident table borders)
[[2] - "hidden" forces *-width="0pt"
[[3] - special case for table borders in that "hidden" has higher precedence than any other coincident border specification and the border is never seen
][2] - "double" with both lines and intervening space equal to the width
 [2] - "solid"
 [2] - "dashed"
 [2] - "dotted"
 [2] - "ridge"
 [2] - "outset"
 [2] - "groove"
 [2] - "inset"
 [2] - "none" forces *-width="0pt"
[[3] - special case for table borders in that "none" has lower precedence than any other coincident border specification so may still be seen
]][1] - *-color= (precedence to construct nesting in coincident table borders of equal width and style)
[[2] - color precedence has a different order than numeric construct precedence:
[[3] - (highest to lowest) for cell, row, row group, column, column group, table
]][1] - region areas are fixed at a border width of 0pt and a padding of 0pt
 [1] - note that table border arbitration may be explicitly overridden by numeric precedence
[[2] - see [Table and cell borders - Section 6.2.1] for details
]]
Borders with a conditionality of "discard" (the default) will have borders along split reference area edges discarded
[[1] - a retained border will be drawn along the reference area's edge
]
[Figure 10.8: An illustration of border conditionality
Two tests are shown across four columns of a page. In each pair of columns, two-line blocks are stacked on the page and the block at the bottom of the left column is split to the top of the right column. In the middle of the second column, a multi-line block as a middle portion of inline text bordered.
The left of the two tests uses a conditionality of "discard" and gaps can be seen at the bottom of the bottommost block in column 1 and the top of the topmost block in column 2. Gaps can also be seen in the block edges of the lines containing the bordered inline characters.
The right of the two tests uses a conditionality of "retain" and borders can be seen at the bottom of the bottommost block in column 1 and the top of the topmost block in column 2. Borders can also be seen in the block edges of the lines containing the bordered inline characters.
]
Note the following about the example:
[[1] - each test includes a test of both block and inline level bordered areas
[[2] - in Test 1 the conditional border widths are discarded by default
 [2] - in Test 2 the conditional border widths are retained using the shorthand:
border-width.conditionality="retain"
][1] - the split areas have, respectively, open and closed edges along the splits in the first and second tests implementing each of "discard" and "retain" property values
 [1] - the presence of the retained border in the inline test changes the amount of text that fits on the third line
]
10.6 Displaying backgrounds
[> 11.][< 10.5.1][^^][^^^]
10.6.1 Backgrounds
[> 10.6.2][> 11.][< 10.5.1][^^][^^^]
Properties control the background colors and images
[[1] - [background-color]=
[[2] - either transparent to show through the parent area background (default) or a specified color
][1] - [background-image]=
[[2] - a URI specification to render as the background
][1] - [background-repeat]=
[[2] - repeatedly renders the background image in both directions, in the "x" direction (horizontal left to right according to the reference orientation), in the "y" direction (vertical top to bottom according to the reference orientation), or render only a single time
][1] - [background-position-horizontal]=
[[2] - position the background image in the horizontal direction (left to right according to the reference orientation)
][1] - [background-position-vertical]=
[[2] - position the background image in the vertical direction (top to bottom according to the reference orientation)
][1] - [background-attachment]=
[[2] - whether a background image scrolls in synchronization with the scrolling of an object, or if the presentation is electronic, the background image is fixed in place and the object's content scrolls over the fixed background
]]
An area's background is always within its padding rectangle
[[1] - any gaps in a border that is not solid (e.g. a dotted border) are transparent and will show through the parent area background
]
[Figure 10.9: Background visibility
The rectangles of an area are shown indicating the transparent spacing, opaque border, transparent padding, and the child area content.
In relief, rectangles shown behind these indicate the parent area background within the spacing rectangle, the area background within the padding rectangle and the child area background within the content rectangle.
]
Precedence is to the contained areas
[[1] - a child area's background shows on top of an area's background
 [1] - an area's background shows on top of its parent's background
]
10.6.2 Decorating page columns using a background
[> 11.][< 10.6.1][^][^^][^^^]
Consider the need to decorate columns of a page
[[1] - no properties to decorate the normal-flow-reference-area of a column
 [1] - can create an image of the decoration for the background of the entire page
[[2] - for a single column could center a narrow image of just the decoration
[[3] - such as a simple vertical line
][2] - for multiple columns could create a page-wide graphic with strategically placed decoration
][1] - the graphic of the decoration can be repeated for the entire page
 [1] - this scheme does not work for only a portion of the page, only the entire page
]
[Example 10-3: Keeping a group of areas together in a reference area Excerpted from samp/bkgrnd.fo:
01      <region-body region-name="frame-body" 
02   column-count="2" column-gap=".5cm"
03   background-position-horizontal="center"
04   background-repeat="repeat-y"
05   background-image='url("vertical-line.bmp")'/>
06   ...
07   <block background-color="silver">This is a test</block>
08   ...
]
[Figure 10.10: A decoration between page columns
A two column page of blocks shown with the block backgrounds visible to illustrate the width of the columns.
A vertical black line sits in the center of the gap between the two columns.
]
Of note:
[[1] - the silver background is used here only to illustrate the width of the columns on the page
]


This is an accessible version of Crane's commercial training material. The content has been specifically designed to assist screen reader software in viewing the entire textual content. Figures are replaced with text narratives.

Navigation hints are in square brackets:
[Tx.x] and [Fx.x] are textual representations of the applicability icons;
[digit] indicates list depth for nested lists;
[link [URL]] indicates the URL of a hyperlink if different than link;
[EXAMPLE] indicates an example listing of code;
[FIGURE] indicates the presence of a figure replaced by its description;
[>] jumps forward;
[<] jumps backward;
[^] jumps to start of the section;
[^^] jumps to the start of the chapter;
[^^^] jumps to the table of contents.
Suggestions for improvement are welcome: [info@CraneSoftwrights.com]
Book sales: [http://www.CraneSoftwrights.com/links/trn-acc.htm]
Information: [http://www.CraneSoftwrights.com/links/info-acc.htm]
This content is protected by copyright and, as there are no means to protect this accessible version from plagiarism, please do not make any commercial edition available to others.

+//ISBN 978-1-894049::CSL::Courses::PFUX//DOCUMENT Practical Formatting Using XSL-FO 2008-01-27 17:30UTC//EN
Practical Formatting Using XSL-FO
Seventh Edition - 2008-01-27
ISBN 978-1-894049-19-1
Copyright © Crane Softwrights Ltd.