Design Notes for Extensible Stylesheet Language (XSL) 2.0

See the XSL-FO 2.0 Requirements Document, section 2.1.1

Add support for non-rectangular areas wherever appropriate. This is for areas where the content needs to be flowed inside an non-rectangular shape.

Requirement:

See the XSL-FO 2.0 Requirements Document, section 2.1.2

Run text on a path including flowing from one path to another. This goes further than simply including SVG, as we're also supporting the line breaking rules that XSL-FO provides. Text should be able to flow from one line to the next line of the multiline paths but it needs to be explicitly specified what each line of the path is, as we do not intend to stack paths automatically. The intent is to apply the normal line building properties to text on a path.

(This draft does not yet address this requirement)

Requirement:

See the XSL-FO 2.0 Requirements Document, section 2.1.2

Add support for runarounds or intrusions (text flowing around illustrations, regions and other objects). This is related to effects obtained by overlapping areas of either rectangular or non-rectangular shape in any suitable combination, but it doesn't really require non-rectangular areas.

Allow one object to intrude into another.

Support intrusions into all 4 sides

Support specifying pull-quotes without the need to repeat the content of the pull-quote. This is related to 2.2.9.4 Generalized markers [and will be addressed in that section]

Support cut-outs

The objects (both the intruder as well as the object intruded upon) may be of arbitrary shape

Allow users to specify the relations between the objects that are impacted by the intrusion

For non-rectangular areas, XSL-FO 2.0 uses shapes expressed in SVG [SVG]. Regions and block containers can have associated shapes.

Intrusions and cut-outs are seen as two ways of looking at one shape affecting another, and are both modeled as intrusions.

Relative priority between shapes is handled using the z-index property.

2.1.1 fo:page-master

The fo:page-master is used in the generation of pages and specifies the geometry of the page. The page may be subdivided into an arbitrary number of regions, each called an fo:region.

The region has similar behaviour to a region-body, this means that an fo:page-master is formed by an arbitrary number of body-like regions. Regions are positioned absoulutely into the page and have a concept of z-index.

The fo:page-master formatting object generates no area directly. It is used in the generation of pages by an fo:page-sequence.

When the fo:page-master is used to generate a page, a viewport/reference pair is generated, consisting of a page-viewport-area and a page-reference-area. The page-viewport-area represents the physical bounds of the output medium. The page-reference-area represents the portion of the page on which content is intended to appear; that is, the area inside the page margins.

In addition, when the fo:page-master is used to generate a page, viewport/reference pairs that correspond to the regions that are the children of the fo:page-master are also generated.

A large shape called Region A is filled with text, and has z-index of zero. A smaller shape, called region B, wholly contained within region A, also contains text (coloured red). Region B has a z-index of 1, so that the text in region A is pushed away from it. If both regions had the same z-index, the text would ovelap. A third region, region C (coloured green) has z-index of 2, and forces the text in the other two regions to avoid it.

Figure 1. The z-index property. A large shape called Region A is filled with text, and has z-index of zero. A smaller shape, called region B, wholly contained within region A, also contains text (coloured red). Region B has a z-index of 1, so that the text in region A is pushed away from it. If both regions had the same z-index, the text would ovelap. A third region, region C (coloured green) has z-index of 2, and forces the text in the other two regions to avoid it.

Trait Derivation:

Same as fo:simple-page-master

Same as fo:simple-page-master

The following properties apply to this formatting object:

(region)+

[7.10 Common Margin Properties-Block]

[7.xx.1 "bleed-box"]

[7.25.8 "master-name"]

[7.25.13 "page-height"]

[7.25.15 "page-width"]

[7.20.3 "reference-orientation"]

[7.xx.2 "trim-box"]

[7.27.7 "writing-mode"]

2.1.2 fo:shape

Used in constructing a shape outline. This object defines a shape using a child from a SVG Documents to describe the region's shape. The permitted structure of this child is that defined for that namespace.

The definition of the shape using the fo:shape permits the shape re-use among different regions similarly to the concept of page-masters.

The fo:shape may define background, border and padding properties. These are applied to the SVG shape's path. In the case the SVG shape already defines a border (using the stroke attribute) and/or a background (using a fill attribute) the fo properties are overimposed to the SVG document.

The fo:shape object has a child from an SVG Document to describe a region's shape. The permitted structure of this child is that defined by SVG [SVG].

Example 1: Path based shape

<fo:shape shape-name="trapezoid">
	        <svg:svg xmlns:svg="http://www.w3.org/2000/svg">
	          <svg:path d="M ... z " />
	        </svg:svg>
	      </fo:shape>

	      <fo:shape shape-name="free-hand">
	        <svg:svg xmlns:svg="http://www.w3.org/2000/svg">
	          <svg:path d="M ... z" />
	        </svg:svg>
	      </fo:shape>

Example 2: Showing border, padding and background.

<fo:shape shape-name="circle" 
	              border-width="2pt" border-color="black"
	              padding-width="10pt"> 
	        <svg:svg xmlns:svg="http://www.w3.org/2000/svg">
	          <circle cx="250" cy="250" r="200"/>
	        </svg:svg>>
	      </fo:shape>

Text is set inside a circle, with a border a short distance from the text; around the circle is a square, just large enough to contain the circular border and the text inside it. The square is the region bounding box.

Figure 2. The bounding box of a shaped region is the smallest rectangle that completely contains the shape, and is here called the region bounding-box. The border and padding follow the outline of the shape itself.

The following properties apply to this formatting object:

[7.10 Common Margin Properties-Block]

[7.xx.1 "bleed-box"]

[7.25.8 "master-name"]

[7.25.13 "page-height"]

[7.25.15 "page-width"]

[7.20.3 "reference-orientation"]

[7.xx.2 "trim-box"]

[7.27.7 "writing-mode"]

2.1.3 fo:region

Used in constructing a page-master, the behavior of each fo:region is similar to the behavior of fo:region-body of XSL-FO 1.1. A region specifies a viewport/reference pair that is located in an absoulte position within the fo:page-master. The "overflow"trait controls how much of the underlying region-reference-area is visible; that is, whether the region-reference-area is clipped by its parent region-viewport-area.

Typically, for paged media, the areas returned by the fo:flow formatting object in a fo:page-sequence are made to be descendants of a sequence of region-reference-areas that correspond to region-bodies. These region-reference-areas are all area descendants of page-areas for which the page-master included an fo:region-body. If the fo:flow flow is assigned to some other region, then the areas returned by the fo:flow are constrained to be descendants of region-reference-areas generated using the assigned region-master.

The fo:region may be divided into multiple columns. When the column-count trait is greater than one the region will be subdivided into multiple columns.

Same as fo:region-body

Trait Derivation:

Same as fo:region-body

Same as fo:region-body

The following properties apply to this formatting object:

(shape-name-specifier,
	      shape-path-specifier?,
	      shape-background-specifier*, shape-border-specifier*)

Example

<fo:page-master 
	        master-name="only"
	        page-height="11in" page-width="8.5in"
	        margin-top="3pt" margin-bottom="3pt" 
	        margin-left="3pt" margin-right="3pt">

	        <fo:region 
	          absolute-position="absolute" 
	          top="0.8636in" left="1.125in"
	          width="6.75in" height="7.75in"
	          region-name="region_A" 
	          z-index="0"
	          wrap="shape"
	          wrap-sides="both"
	          wrap-path="shape">
	          ... shape reference specifier(s) ...
	        </fo:region>

	        <fo:region 
	          absolute-position="absolute" 
	          top="1.3in" left="1.4in"
	          width="3.6in" height="5.4in"
	          region-name="region_B" 
	          z-index="1"> 
	          ... shape reference specifier(s) ...
	        </fo:region>

	      </fo:page-master>

[7.5 Common Absolute Position Properties]

[7.7 Common Border, Padding, and Background Properties]

[7.10 Common Margin Properties-Block]

[7.1x Common Wrap Properties]

[7.20.1 "clip"]

[7.25.2 "column-count"]

[7.25.3 "column-gap"]

[7.13.4 "display-align"]

[ 7.15.6 "height"]

[7.20.2 "overflow"]

[7.25.17 "region-name"]

[7.20.3 "reference-orientation"]

[7.15.14 "width"]

[7.27.7 "writing-mode"]

[7.28.9 "z-index"]

The shape assignment model allows a region to point to one or more regions that are used to define:

content path: where the region's content is bound to wrap

wrapping path: where the region's intruded content is bound to wrap around

border: one or more shapes used to define a border that is beyond standard FO border capabilities or it is designed ad-hoc

background: one or more shapes used to define a background effect that is beyond standard FO background capabilities

This draft does not yet cover the interactions between non-rectangular shapes and footnotes.

Shape assignment model illustration

Figure 3. Shape assignment model illustration.

Example 3. Full Shape and Region use and re-use.

<fo:layout-master-set>
	        <fo:shape shape-name="hexagon"> 
	          <svg:svg xmlns:svg="http://www.w3.org/2000/svg">
	            <svg:path d="M ... z " />
	          </svg:svg>
	        </fo:shape>

	        <fo:shape shape-name="intruder-bag"> 
	          <svg:svg xmlns:svg="http://www.w3.org/2000/svg">
	            <svg:path d="M ... z " />
	          </svg:svg>
	        </fo:shape>

	        <fo:shape shape-name="border-bag"> 
	          <svg:svg xmlns:svg="http://www.w3.org/2000/svg">
	            <svg:path d="M ... z " />
	          </svg:svg>>
	        </fo:shape>

	        <fo:shape shape-name="bag"> 
	          <svg:svg xmlns:svg="http://www.w3.org/2000/svg">
	            <svg:path d="M ... z " />
	          </svg:svg>
	        </fo:shape>

	        <fo:page-master 
	          master-name="only"
	          page-height="11in" page-width="8.5in"
	          margin-top="3pt" margin-bottom="3pt" 
	          margin-left="3pt" margin-right="3pt">

	          <fo:region 
	            absolute-position="absolute" 
	            top="0.8636in" left="1.125in"
	            width="10in" height="12in"
	            region-name="region_A" 
	            z-index="0">

	            <fo:shape-name-specifier
	              shape-name-reference="bag"
	              width="100%" height="100%"
	              display-align="center" />

	            <fo:shape-path-specifier
	              shape-name-reference="intruder-bag"
	              width="100%" height="100%"
	              display-align="center" />

	            <fo:shape-border-specifier
	              shape-name-reference="border-bag"
	              width="100%" height="100%"
	              display-align="center" />

	            <fo:fo:shape-background-specifier
	              shape-name-reference="hexagon"
	              width="80%" height="80%"
	              relative-position="relative"
	              top="6in" left="6in" />

	            <fo:fo:shape-background-specifier
	              shape-name-reference="hexagon"
	              width="60%" height="60%"
	              relative-position="relative"
	              top="4in" left="4in" />

	            <fo:fo:shape-background-specifier
	              shape-name-reference="hexagon"
	              width="40%" height="40%"
	              relative-position="relative"
	              top="2in" left="2in" />

	            <fo:fo:shape-background-specifier
	              shape-name-reference="hexagon"
	              width="20%" height="20%"
	              relative-position="relative"
	              top="1in" left="1in" />

	          </fo:region>
	        </fo:page-master>

	      </fo:layout-master-set>

2.1.4 fo:shape-name-specifier

The fo:shape-name-specifier element is used to name a shape for the applicable region or block container, and also to constrain the width and height for that shape.

The following properties apply to this formatting object:

EMPTY

[shape-name-reference similar to flow-name-reference]

[7.13 Common Relative Position Properties]

[7.13.4 "display-align"]

[ 7.15.6 "height"]

[7.15.14 "width"]

2.1.5 fo:shape-path-specifier

The fo:shape-path-specifier is used to specify the intrusion path created from this region when intruding other regions.

The following properties apply to this formatting object:

EMPTY

[shape-name-reference similar to flow-name-reference]

[7.13 Common Relative Position Properties]

[7.13.4 "display-align"]

[ 7.15.6 "height"]

[7.15.14 "width"]

Value:	skip \| path \| none
Initial:	skip
Percentages:	N/A
Applies to:	fo:region
Inherited:	no
Media:	visual

Use the "wrap" property to specify flow run-around.

skip: This is the default behavior. The content in the flow will skip the entire intrusion area continuing from the first available un-intruded allocation area
Figure 4. With wrap=skip the embedded shape acts as if it took up the whole available width, so that there is no room for text to either side of it.
path: The runaround contour is determined following the wrap-path property strategy
Figure 5. With wrap set to path, the shape appears to cut a hole in the containing object, so that the text in that object flows around the shape, as close t otouching the wrap-path as possible.
none: No runaround is applied. If regions are overlapping their content will overlap.
Figure 6. With wrap=none the background text continues as if the embedded shape were not present, rather in the manner of an absolutely-positioned block-container

Open issue: 8859

this also needs to relate to floats: we have basically defined a sort of centre float here. Should we allow float: left/right/none to take a percentage too?

2.1.8.2 wrap-path

When two or more shaped areas interact, the "wrap-path" property determines how text and other inline objects in one area flow around the shape of the other area.

Value:	shape \| bounding-box \| auto
Initial:	shape
Percentages:	N/A
Applies to:	fo:region
Inherited:	no
Media:	visual

This is the default behavior. The path is custom and it is indicated using the shape-path-specifier within the shape-assignment for the region. If there is no shape-map associated with the intruded region the behaviour is defaulted to bounding-box.

shape

bounding-box

The path is determined by the bounding-box of the overlapping region

The path is inferred as follows:

clip-path embedded in the content of the intruding region.

path detection through image color threshold or alpha-channel (transparency) in the content in the intruding region.

If neither of these are available, or the implementation does not support them, the path is defaulted to the bounding-box.

2.1.8.3 wrap-side

The "wrap-side" property indicates what strategy should be applied for the runaround.

Value:	all \| start \| end \| inside \| outside \| largest \| smallest
Initial:	shape
Percentages:	N/A
Applies to:	fo:region
Inherited:	no
Media:	visual

all: This is the default behavior. Runaround is performed, if possible, on both sides of the intruding area.
Figure 7. With wrap-side=both, text flows on both side of an intrusion.
start: The run-around is performed only in the start side of the intruding area.
Figure 8. With wrap-side=start, text is rendered between the start edge of the containing area and the runaround, but not on the other side of the runaround.
end: The runaround is performed only in the end side of the intruding area.
Figure 9. With wrap-side=end, text is rendered between the runaround and the end edge of the containing area, but not on the start-edge side side of the runaround.
inside: The runaround is performed only in the inside of the intruded area. The inside is the side nearer to the spread "spine". The spread spine is considered the contact line between the two pages forming the spread. If the region is not part of a spread the inside value is interpreted as nearest to the binding edge, as for text-align.
Figure 10. With wrap side=inside, text can flow between the edge of the containing area that is nearest to the binding and the runaround, but not the other side.
outside: The runaround is performed only in the outside of the intruded area. The outside is determined as elsewhere, e.g. text-align.
Figure 11. With wrap side=outside, text can flow between the runaround shape and the edge of the containing area that is furthest away from the binding, but not the other side.
largest: The runaround is performed only in the largest area available as result of the intrusion.
Figure 12. With wrap-side=largest the text can only flow into the largest available area.
smallest: The runaround is performed only in the smallest area available as result of the intrusion.
Figure 13. With wrap-side=smallest the text can only flow into the smaller of the two gaps on either side of the runaround.

What about V-shaped or W-shaped intrusions?

2.2 Copyfitting

See the XSL-FO 2.0 Requirements Document, section 2.1.4

Add support for copyfitting, for example to shrink or grow content (change properties of text, line-spacing, ...) to make it constrain to a certain area. This is going to be managed by a defined set of properties, and in the stylesheet it will be possible to define the preference and priority for which properties should be changed. That list of properties that can be used for copyfitting is going to be defined.

Additionally, multiple instances of alternative content can be provided to determine best fit.

This includes copyfitting across a given number of pages, regions, columns etc, for example to constrain the number of pages to 5 pages.

Add the ability to keep consistency in the document, e.g. when a specific area is copyfitted with 10 pt fonts, all other similar text should be the same.

2.2.1 Summary

Allowing copyfitting on fo:region, fo:region-* objects, fo:block-container and fo:table-cell.

Adding a new value ("justify") for the property "display-align" (already in XSL-FO) to activate copyfitting. Though the same property is used for vertical justification, users can exploit the property "force-page-count" (along with a correct definition of page-masters and page-sequences) to avoid conflicts.

Introducing the concept of “list of prioritized adjustable properties”. An adjustable property is an existing XSL-FO property that can be modified in order to do copyfitting or vertical justification.

Exploiting range values of existing properties to specify how (and how much) each property can be adjusted. Introducing the idea of "elasticity".

Adding a new property "adjustable-properties" that specifies such lists.

Adding new values to the property "force-page-count" to model copyfit into a fixed number of pages or a multiple of a number.

Adding a new formatting object fo:alternative-copyfit-content to express alternative content for copyfitting

How to express consistency and relationships among copyfitted areas? how to copyfit irregular shapes?

how to express alternative content: what happens if it is not possible? how to express consistency and relationships among copyfitted areas? how to copyfit irregular shapes?

2.2.2 Copyfit: basic approach and definitions

Many options exist to copyfit content to a certain area. For example, a user could add some space between paragraphs, widen or narrow spaces before and after titles, images and tables, modify the line height of some paragraphs, etc. All these fine tunings, and their multiplicity of combinations, lead to different results, and different users could have different preferences.

Thus, copyfitting actually requires two logically separated tasks: (1) the request of copyfitting to a given area, and (2) the definition of strategies to copyfit.

Copyfitting is enabled by setting the property display-align to the value "justify". Copyfitting strategies are then expressed through "adjustable properties lists" using the. adjustable-properties property.

Although the same approach is used for vertical justification, users can exploit the property force-page-count and/or the definition of page-masters and page-sequences to avoid conflicts.

The display-align property applies to fo:region, fo:region-*, fo:block-container and fo:table-cell. It is then possible to copyfit content in a block-container or in a table cell, and also to copyfit the content of one flow to a single region, multiple flows to a single region or even multiple flows to multiple regions.

A display-align-last property is also added, to specify different treatment of the last page in a copyfitted seqence, by analogy with text-align and text-align-last.

2.2.3 Copyfit Examples

Let us first consider two flows A and B that go into two distinct regions R1 and R2, as defined in the following XSL-FO excerpt:

<?xml version="1.0" encoding="UTF-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
    <fo:page-master master-name="sample1" page-height="11in" page-width="8.5in" margin-top="3pt"
        margin-bottom="3pt" margin-left="3pt" margin-right="3pt">
        <fo:region  region-name="R1" 
                    display-align="justify" 
                    adjustable-properties="line-height"/> 
        <fo:region  region-name="R2" 
                    display-align="before"/> 
    </fo:page-master>

    <fo:flow-map flow-map-name="M1">
        <fo:flow-assignment>
            <fo:flow-source-list>
                <fo:flow-name-specifier flow-name-reference="A"/>
            </fo:flow-source-list>
            <fo:flow-target-list>
                <fo:region-name-specifier region-name-reference="R1"/>
            </fo:flow-target-list>
        </fo:flow-assignment>
        <fo:flow-assignment>
            <fo:flow-source-list>
                <fo:flow-name-specifier flow-name-reference="B"/>
            </fo:flow-source-list>
            <fo:flow-target-list>
                <fo:region-name-specifier region-name-reference="R2"/>
            </fo:flow-target-list>
        </fo:flow-assignment>
    </fo:flow-map>

    <fo:page-sequence force-page-count="1" flow-map-reference="M1">
        <fo:flow flow-name="A">
            <fo:block> Lorem maecenas blandit ac, neque sed ut pulvinar, lectus sagittis 
            sapien per risus vel.  Ligula sapien sed morbi cras tellus commodo. Si qua ex 
             docet dei etris crucis</fo:block>
            <fo:block> curabitur magna nisi, faucibus sed ornare sed, congue eu dui. 
             Pellentesque habitant morbi tristique senectus et netus et malessecularia uada                     
             fames ac turpis egestas. </fo:block>
            <fo:block> Nunc sit amet dolor sed sem congue mattis sed ut arcu. Mauris id
             magna sit amet elit aliquam.</fo:block>
            <fo:block>Pellentesque habitant morbi tristique senectus et netus et malesuada
                fames.</fo:block>
        </fo:flow>
        <fo:flow flow-name="B">
            <fo:block>Crucis rosa ut hoc sien qua non res veni.</fo:block>
            <fo:block> Etiam tristique, nulla a pulvinar hendrerit nihil tortor urna auctor etim
                domine secularia cali sed ut quotie ire in domince hoc fantus quis eius rei rei.
            </fo:block>
        </fo:flow>
    </fo:page-sequence>
</fo:root>

The property display-align is added to the element "fo:region" to activate copyfit for region R1. No copyfit is activated on region R2 since the property display-align has value "before". Note also that the property force-page-count of the element "fo:page-sequence" states that the overall content has to be copyfitted in one page. Finally, the property adjustable-properties lists those XSL-FO properties that can be modified to copyfit text.

The expected result is shown below:

A page contains two regions; the first, R1, is full of text in red; the second, R2, is about half-full with the rest of the text, in black.

Figure 14. Expected result of copyfit example.

The same flows and regions are expected to produce a different output, when the flow-map M2 is used instead:

<fo:flow-map flow-map-name="M2">
        <fo:flow-assignment>
            <fo:flow-source-list>
                <fo:flow-name-specifier flow-name-reference="A"/>
                <fo:flow-name-specifier flow-name-reference="B"/>
            </fo:flow-source-list>
            <fo:flow-target-list>
                <fo:region-name-specifier region-name-reference="R1"/>
                <fo:region-name-specifier region-name-reference="R2"/>
            </fo:flow-target-list>
        </fo:flow-assignment>
</fo:flow-map>

In this case, the two flows go into region R1 and then region R2. If the properties display-align does not change, the expected result is the following:

A page contains two regions; the first, R1, is full of text in red; the second, R2, starts with a continuation of the red text; this text is followed by the black text.

Figure 15. Expected result of copyfit example with display-align = before.

The expected result is different when either the property "display-align" of region R2 is set to "justify":

<fo:page-master master-name="sample1" page-height="11in" page-width="8.5in" margin-top="3pt"
       margin-bottom="3pt" margin-left="3pt" margin-right="3pt">
       <fo:region  region-name="R1" 
                   display-align="justify" 
                   adjustable-properties="line-height"/> 
       <fo:region  region-name="R2" 
                   display-align="justify"/>
   </fo:page-master>

In fact, both the regions end up being copyfitted as shown below:

Figure 16. Expected result of copyfit example with display-align = justify.

When the formatter is expected to produce as many pages as needed (for instance, by setting the property force-page-count to "no-force"), the property display-align is used to activate vertical justification. The property display-align-last is then used to set the vertical alignment of the last page.

Let us consider the following example, where only one region R1 and one flow A are declared:

<?xml version="1.0" encoding="UTF-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
    <fo:page-master master-name="sample1" page-height="11in" page-width="8.5in" margin-top="3pt"
        margin-bottom="3pt" margin-left="3pt" margin-right="3pt">
        <fo:region-body region-name="xsl-region-body" 
            display-align="justify" 
            display-align-last="relative"
            adjustable-properties="..."/>
    </fo:page-master>

    <fo:page-sequence>
        <fo:flow flow-name="A">
            <fo:block>Lorem ipsum dolor sit amet, nunc euismod nisl nam euismod, quis maecenas
                blandit ac, neque sed ut pulvinar, lectus sagittis ... quorneque tortor
                neque, commodo mauris sagittis yurpis,hic fecit leuc em.</fo:block>
            <fo:block>Lorem ipsum dolor sit amet, nunc ... lectus sagittis sapien
                mauris per risus.</fo:block>
            <fo:block>Ligula sapien sed morbi cras tellus ... quoque
                cra ut sic fecit quorem deis hoc hac lorem ipse die cruci faucibus sed ultrices
                tempor inter dum.</fo:block>
            <fo:block>Lorem ipsum dolor sit amet, .... Rutrum mattis accumsan.</fo:block>
        </fo:flow>
    </fo:page-sequence>
</fo:root>

The values of the properties display-align and display-align-last of the element "fo:region-body" require the formatter to produce the following output:

Three pages of text; the first two are full, and the third is partially filled.

By setting the property display-align-last to "justify", the last page is also vertically justified:

Note also that this case can be easily generalized for the case of multiple flows going into the same region.

The formatter is expected to copyfit text in a given number of pages when the property force-page-count is set to an integer value. Consider for instance the previous declaration of "fo:region-body" changed into:

<fo:region-body region-name="xsl-region-body" 
            display-align="justify" 
            display-align-last="justify"
           force-page-count="2"
            adjustable-properties="..."/>

The formatter is now expected to produce the following result:

The last page is vertically justified since the property display-align-last is set to "justify". By changing that property, user can obtain the same number of pages without imposing the last one to be completely filled.

A more complex example is shown below, summarizing multiple cases:

2.2.4 Content Adjusting Strategies

XSL-FO provides a general mechanism to express strategies for copyfitting or vertical justification. The overall approach is flexible and independent on the formatting task and may be applied to other contexts in the future.

An "adjustable properties list" is an ordered sequence of properties names (or group of names) that a formatter is allowed to modify to format the content. In fact, such lists are used to drive copyfitting, vertical justification and feathering. The order of the names in the list follows the priority rules described below.

Adjustable properties lists can be associated with fo:objects using the property adjustable-properties.

It is important to note that the “adjustable-properties list” only states the strategy to format the content and does not define the actual property ranges the application is allowed to modify. These are instead expressed (as in an XSL-FO 1.1 document) throughout the flow and its descendant formatting objects: this provides a great expressing power in a simple way, as, for example, it allows for different fo:block elements to have different adjusting properties.

For example: adjustable-properties=”space-before word-spacing” means that the application is allowed to modify the actual value of the space-before and word-spacing properties. Although the “adjustable-properties” property is defined in the fo:flow-assignment object, the variations are defined in the “space-before” and “word-spacing” properties of the blocks within the actual flow. In most cases values of these properties are actually inherithed. The application should try to adjust the text by choosing appropriate values for the space-before traits (using a value either greater or smaller that the .optimum one but still between the relevant .minimum and .maximum) of each block.

In fact, many FO properties (dating back to the initial XSL-FO specification) can be given a length range value, expressed using a .minimum, .optimum and .maximum components; others (allowed-height-scale, allowed-width-scale) can be given a list of numeric values; font-family can be given a list of values.

A property having a range value can create some elasticity: the dimensions of the areas generated by the affected formatting objects can stretch or shrink from an optimal value. An FO subtree is said to have inline elasticity if there are properties involved in the line building process that have some degree of elasticity; similarly, an FO subtree is said to have block elasticity if there are properties involved in the block stacking process that have some degree of elasticity. It should be noted that a length range in an inline-related property can involve both inline and block elasticity (as, for example, a variation in word-spacing may result in the creation of fewer or more lines), while a range in a block-related property only creates block elasticity.

The presence of some elasticity is the first condition to adjust content (for copyfitting or vertical justification). Properties with range or list values, in fact, can be adjusted in order to achieve the expected result.

On the other hand, elasticity does not automatically imply that content will be formatted as expected. It may happen that properties listed in “adjustable properties list” do not have elasticity while other do. In that case the formatter cannot achieve the expected result and should warn the user.

If properties listed in the “adjustable properties list” do have elasiticy but the formatter is not able to achieve the expected result – because of syntax errors, limitated support of required strategies, etc. – the formatter should warn the user too.

An example of copyfit declaration and application is shown below:

<?xml version="1.0" encoding="UTF-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
    <fo:page-master master-name="sample1" page-height="11in" page-width="8.5in" margin-top="3pt"
        margin-bottom="3pt" margin-left="3pt" margin-right="3pt">
        <fo:region  region-name="R1" 
                    display-align="justify" 
                    adjustable-properties="line-height"/> 
        <fo:region  region-name="R2" 
                    display-align="before"/> 
    </fo:page-master>

    <fo:flow-map flow-map-name="M1">
        <fo:flow-assignment>
            <fo:flow-source-list>
                <fo:flow-name-specifier flow-name-reference="A"/>
            </fo:flow-source-list>
            <fo:flow-target-list>
                <fo:region-name-specifier region-name-reference="R1"/>
            </fo:flow-target-list>
        </fo:flow-assignment>
        <fo:flow-assignment>
            <fo:flow-source-list>
                <fo:flow-name-specifier flow-name-reference="B"/>
            </fo:flow-source-list>
            <fo:flow-target-list>
                <fo:region-name-specifier region-name-reference="R2"/>
            </fo:flow-target-list>
        </fo:flow-assignment>
    </fo:flow-map>

<fo:page-sequence force-page-count="1" flow-map-reference="M1">
    <fo:flow flow-name="A">
        <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt" 
            line-height.minimum="8pt" line-height.maximum="14pt"> 
            Lorem maecenas blandit ac, neque sed ut pulvinar, lectus sagittis 
            sapien per risus vel.  Ligula sapien sed morbi cras tellus commodo. 
            Si qua ex docet dei etris crucis</fo:block>
            <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt" 
            line-height.minimum="8pt" line-height.maximum="14pt"> curabitur 
            magna nis, faucibus sed ornare sed, congue eu dui. 
            Pellentesque habitant morbi tristique senectus et netus et 
            malessecularia uada fames ac turpis egestas. </fo:block>
        <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt" 
            line-height.minimum="8pt" line-height.maximum="14pt"> Nunc sit amet dolor 
            sed sem congue mattis sed ut arcu. Mauris id magna sit amet elit aliquam.</fo:block>
        <fo:block>Pellentesque habitant morbi tristique senectus et netus et malesuada
            fames.</fo:block>
    </fo:flow>
    <fo:flow flow-name="B">
        <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt" 
            line-height.minimum="8pt" line-height.maximum="14pt">Crucis rosa ut 
            hoc sien qua non res veni.</fo:block>
        <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt" 
            line-height.minimum="8pt" line-height.maximum="14pt"> Etiam tristique, 
            nulla a pulvinar hendrerit nihil tortor urna auctor etim
            domine secularia cali sed ut quotie ire in domince hoc fantus quis eius rei rei.
        </fo:block>
    </fo:flow>
</fo:page-sequence>
</fo:root>

The two regions R1 and R2 use different strategies to copyfit. Flow A is copyfitted into region R1 by only adjusting the word-space of each block (that will be a value between 1pt and 4pt), while flow B is copyfitted into region R2 by adjusting line-height of each block (that will be a value between 8pt and 14pt).

Notice again that the declaration of the strategies for copyfitting is completely disconnected from the declaration of the copyfit itself.

The definition of “adjustable-properties” in a fo:flow-assignment object provides great flexibility to the copyfit process (and, similarly, to the vertical justification). In fact, different blocks may have different values of the same property that are all within the allowed ranges. Though any result that satisfies the specified constraints would conform to this specification, current typographic practice would tend to use the available elasticity with uniformity within the same page-sequence or, at least, whitin the same page. So, for example, if two fo:blocks having the same values for space-before happen to generate areas for a copyfitted page, and the application has to use this elasticity, the result most use will expect would have both spaces being set to an identical value.

2.2.5 Objects and properties for copyfit

2.2.5.1 adjustable-properties

The adjustable-properties property is used to define strategies for copyfitting or vertical justification. It takes effect only if the property display-align is set to "copyfit" or "justify".

Value:	<property-name-list>
Initial:	everything
Applies to:	fo:region, fo:region-body, fo:region-before, fo:region-after, fo:region-start, fo:region-end, fo:block-container, fo:table-cell
Inherited:	no
Percentages:	N/A
Fallback:	everything

The value is a whitespace separated list of names (property names and / or shorthand names), possibly grouped in subsets by a single level of parenthesis; formally, it can be defined by these rules:

prioritized-list-of-names = [<priority-group>]*
		  priority-group = <property-name> | <shorthand-name> | ([<property-name> | <shorthand-name>]+)

where a property-name can be the name of any property defined by the FO recommendation;

a shorthand-name stands for a pre-defined sequence of property names:

inline-spacing = word-spacing letter-spacing leader-length
block-spacing = space-before space-after
. . .
any = any property having a range value

2.2.5.2 Value list simplification

An XSL-FO implementation MUST simplify the value list as follows:

remove empty paren pairs, ()
"(" name ")" is equivalent to name
if property-name refers to a property that cannot accept either range values (.minimum, .optimum, .maximum) or multiple values (such as font-family), it can be removed; the application SHOULD warn the user about the uselessness of using that property name, since the value cannot be varied as a part of copyfitting.
if property-name refers to a property which the application is not able to adjust automatically, it can be removed; the application SHOULD warn the user about the application limitation.
if a priority group contains the shorthand "any", than the other property names or shorthand names can be removed
every priority group following "any" MUST be discarded; a processor SHOULD warn the user about any discarded priority groups.

At the end of the simplification process the property value could be the empty list. This means that there is no elasticity that the application is able to handle, and the output will not be formatted as requested. The default value of "any" has been chosen to reduce the likelihood of this.

2.2.5.3 Priority

Items in the simplified value list are given a decresing priority: the first item's priority is greater than that of the second one, and so on; values between parenthesis have the same priority. The application has to respect this priority assignment while adjusting properties:

Definition: The [Definition: active properties set] is the set of properties whose value the application is allowed to choose at a certain time during the adjustment process; initially, the active properties set contains the values of the first priority group;
The application has to check whether it is possible to adjust the content using the current active properties set (choosing an appropriate value between their .minimum and .maximum, or among the available values)
if there is a way to adjust the content, the output should reflect that particular choice of values without changing the other properties (e.g. using their .optimum values); otherwise, the next priority group should be added to the active properties set.

Points to note:

The described behaviour follows an incremental approach rather than a combinatorial one; in other words, the number of attempts the application could need to perform is linear in the size of the property list, instead of growing exponentially.
The main aim of the prioritized property list is for the user to be sure that some properties will be adjusted (moving away from their optimal value) only “as a last resort”; this confidence allows the users to give many properties a length range value without fearing for the resulting quality of the output.
At any given moment during the adjustment process, the application has complete freedom concerning the use of the available elasticity (coming from the active properties at that moment); in other words, it is not forced by this specification to exhaust the elasticity of a property before using the one of a different property.

2.2.5.4 fo:alternative-copyfit-content

The fo:alternative-copyfit-content formatting obiect is intended to express alternative content for copyfit.

It might be a child of a fo:flow object (when copyfitting content into a region) or fo:block-container or fo:table-cell (when copyfitting content in block-containers or table cells).

The fo:alternative-copyfit-conten formatting object does not generate any areas. The fo:alternative-copyfit-content formatting object returns the areas generated and returned by its children.

The following properties apply to this formatting object:

(%block;)*

Example:

<fo:flow flow-name="A">
   <fo:alternative-copyfit-content>
        <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt" 
            line-height.minimum="8pt" line-height.maximum="14pt">Crucis rosa ut 
            hoc sien qua non res veni.</fo:block>
        <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt" 
            line-height.minimum="8pt" line-height.maximum="14pt"> Etiam tristique, 
            nulla a pulvinar hendrerit nihil tortor urna auctor etim
            domine secularia cali sed ut quotie ire in domince hoc fantus quis eius rei rei.
        </fo:block>
   </fo:alternative-copyfit-content>

        <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt" 
            line-height.minimum="8pt" line-height.maximum="14pt"> 
            Lorem maecenas blandit ac, neque sed ut pulvinar, lectus sagittis 
            sapien per risus vel.  Ligula sapien sed morbi cras tellus commodo. 
            Si qua ex docet dei etris crucis</fo:block>
            <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt" 
            line-height.minimum="8pt" line-height.maximum="14pt"> curabitur 
            magna nis, faucibus sed ornare sed, congue eu dui. 
            Pellentesque habitant morbi tristique senectus et netus et 
            malessecularia uada fames ac turpis egestas. </fo:block>
        <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt" 
            line-height.minimum="8pt" line-height.maximum="14pt"> Nunc sit amet dolor 
            sed sem congue mattis sed ut arcu. Mauris id magna sit amet elit aliquam.</fo:block>
        <fo:block>Pellentesque habitant morbi tristique senectus et netus et malesuada
            fames.</fo:block>
</fo:flow>

(to be decided; probably any)

2.3 Initial Caps

2.3.1 Initial Caps

See the XSL-FO 2.0 Requirements Document, section 2.1.7

Add support for raised initial capitals and n-line dropped capitals. This includes support for the first n characters.

Large initial capital letters are often used for the first paragraph of a new section or chapter. Many scripts have precise alignment conventions for how the initial letter should be positioned relative to the text in the paragraph.

There are three main types of initial letter.

The first of these is called a [raised initial]; it is set in a larger size then the main text, and space must be left for it in the block direction. No special support is needed for raised initials, as an fo:inline can be used with an increased font-size.

The second sort is a margin initial; it protrudes into the margin in the inline direction, and is often larger than the paragraph text. This is treated as a special case of the third sort of initial capital, because of its vertical alignment requirements.

The third sort of initial letter is often called a drop capital (often abbreviated to "drop cap"). The initial letter is large enough that it extends in the block direction to the Nth following baseline; the drop capital in Figure 21 is sized such that its baseline aligns with the baseline of the fourth line of text in the paragraph, and the top aligns with the cap-height on the first line; this is called a 4-line drop cap.

A paragraph of text starting with the word Decorative, in which the D is large, and extends down so that its baseline is the same as that of the fourth line of text in the paragraph, and the top of the D is aligned with the tops of the capital letters in the first line of text.

Figure 21. Sample Paragraph Starting With Four-Line Drop Capital.

The height of the letter D is thus one cap-height plus three line-heights (including vertical spacing); this will not in general be equal to four times the font size, and an implementation may need to use an algorithm such as binary search to discover the correct font size given the number of lines to span.

If the line spacing varies over the course of the paragraph, the resulting size of an initial cap is implementation dependent: it must either be positioned using the inherited line spacing where the initial occurs, or must correctly take into account the varying line spacing, and align with the appropriate actual line of text.

Several properties are used on an "fo:inline" element as follows:

2.3.1.1 initial-cap-lines

This property specifies the number of lines spanned by the initial letter.

Value:	<number> \| <distance>
Initial:	0
Applies to:	fo:inline
Inherited:	yes
Percentages:	refer to inherited font size
Media:	visual

A value of 1.0 would indicate a regular-sized letter, and a value of 4 would indicate that the first character (or glyph) contained in the "fo:inline" bearing this property must be sized such that its baseline is aligned with the baseline of the 4th line of the containing block, and the cap-height aligned with the cap-height of the first line.

For a vertical script, the corresponding leading and trailing alignments points must be used.

If a distance is given instead of a unitless number, it is to be used instead of computing the distance in terms of line heights; in this case the formatter is not expected to guarantee alignment of the baseline of the initial with that of the nearest text baseline.

Open issue: 7562

An alternative design for initial caps and the initial-cap-lines property would be to say that the value of "auto" for font-size would mean that the font-size was computed from the number of lines.

If the "fo:inline" should happen to format to more than one glyph, the second and subsequent glyphs should be drawn at the same size as the first, even if after line-breaking this results in the first character no longer aligning with the fourth baseline.

If the value is negative, an implementation MAY interpret it as as "dropping" backwards (e.g. upwards for horizontal top-to-bottom scripts).

A non-integral value represents a proportion, so that a value of 3.5 would indicate that the initial should be half-way between the baselines of the third and fourth lines of text.

A value of zero MUST taken to be the same as the default value of 1.0, and is in effect ignored.

If the containing block does not have enough content to span the given number of lines, the initial SHOULD be formatted as if there was enough content, and the size of the initial cap MUST then be included in the block-direction dimension of the block.

If there is not enough room left in the column, page or region, the initial must be taken onto the next page along with the text.

When the "initial-cap-lines" property is set on a formatting object that is not at the start of the block, any preceding text should be pushed out into the margin; this is often used for quote marks.

2.3.1.2 initial-cap-lines-before

Sometimes an initial capital extends before the start of the text as well as perhaps continuing for several lines.

Value:	<number> \| <distance>
Initial:	0pt
Applies to:	fo:inline
Inherited:	yes
Percentages:	Not applicable.
Media:	visual

The "initial-cap-lines-before" property indicates that the initial is to be formatted at a size such that it protrudes in the block-direction to the given distance or number of lines.

Figure 22 shows a Greek initial capital that protrudes above the first line (as measured from the cap height of the first line of text) as well as extending below it.

A value of zero indicates that the leading edge of the initial is to align exactly with that of capital letters in the regular text size.

If the value is negative, an implementation MAY interpret it as as "dropping" forwards.

In this Greek example, a large decorative initial Alpha extends above the cap height of the text on the first line, and also reaches down to align to the baseline of the second line of text below.

Figure 22. Sample Greek Paragraph Starting With Two-Line Initial Capital Protruding Before and After.

Open issue: 7563

Need a clear description of margins, spacing, and initial caps

2.3.1.3 initial-cap-kern-lines

The "initial-cap-kern-lines" property indicates the number of lines of text that should be abutted to the large inital.

Value:	<length> \| <integer>
Initial:	0
Applies to:	fo:inline
Inherited:	yes
Percentages:	refer to initial-cap-lines-after
Media:	visual

A value of 1 would indicate that the first line of text should be set as close as possible, taking into account the shape of the enlarged glyph.

If a distance is given, such as 3cm, any lines whose baselines fall within that distance of the starting reference point of the initial cap are abutted.

The value must not be negative. The default value of zero indicates that no lines are to be kerned closer, and hence all lines are set using the margin.

In Figure 21, the first line is set close, and subsequent lines are set vertically using the "margin" trait of the "fo:inline" element where it is next to the text.

2.3.1.4 initial-cap-indent

The exact font size of the initial is in general computed by the formatter, so the exact distance for an indent must also be computed.

Value:	<length> \| <percentage> \| auto \| inherit
Initial:	0pt
Applies to:	fo:inline
Inherited:	yes
Percentages:	refer to width of enlarged glyph
Media:	visual

The initial-cap-indent property distance (either as an absolute value or as a percentage of the actual formatted initial cap width) by which the initial is indented in the inline direction.

The "initial-cap-indent" is most often either zero or negative, moving the initial into the margin; a value of -50% leaves the glyph centered on the edge of the containing content area. A value of 20% indents the initial (and hence the first n lines of text) by one fifth (20%) of the width of that glyph.

<length>: The enlarged initial is moved in the inline-direction by the given amount.
<percentage>: The enlarged initial is moved in the inline-direction by the given percentage of the size of the glyph.
<auto>: The indent is computed based on any text that precedes the "fo:inline" container in the same block; if the initial is not at the start of a line, the default behaviour (with a "initial-cap-indent" of zero, the default value) is to put such text in the margin: this is most often an opening quote or other punctuation. With a value of auto, the initial is placed wherever it occurs, and the resulting trait value is computed by the formatter.

2.4 Marginalia

See the XSL-FO 2.0 Requirements Document, section 2.2.3

Add support for marginalia.

Note:

Note: this section needs to be revised in the light of the new general fo:region

2.4.1 Extension Regions

The region-body has two extension-regions, called extension-region-start and extension-region-end, which implicitly specify corresponding reference-areas called "start-marginalia-reference-area" and "end-marginalia-reference-area".

The extent in the inline-direction of each extension-region is indicated in the "extent" attribute of the "fo:extension-region-*" declaration, while the block-dimension of the area is the same of the region-body.

Figure 23 shows the current XSL-FO 1.1 page model extended to also include these regions.

Figure 23. Extending the page XSL-FO 1.1 model to include extensions regions

An example declaration of these regions is shown below:

<fo:simple-page-master master-name="only"
	      page-height="29.7cm"
	      page-width="21cm"
	      margin-top="1cm"
	      margin-bottom="2cm"
	      margin-left="2.5cm"
	      margin-right="2.5cm">
	      <fo:region-body margin-top="3cm" margin-bottom="1.5cm"
	      margin-left="2cm" margin-right="2cm"/>
	      <fo:extension-region-start extent="1cm" distance="0.5cm"/>
	      <fo:extension-region-end extent="1cm" distance="0.5cm"/>
	      <fo:region-before precedence="true" extent="3cm"/>
	      <fo:region-after precedence="true" extent="1.5cm"/>
	      <fo:region-start extent="1cm"/>
	      <fo:region-end extent="1cm"/>
	      </fo:simple-page-master>

The element "fo:extension-region-*" also defines other properties of the region such as border, padding, background, etc.

It is an error if a marginalia is contained in a page whose "fo:simple-page-master" does not contain any "fo:extension-region" declaration.

Open issue: 7564

Should users be able to direct marginalia to another region, or only to a predefined marginalia area?

Open issue: 7565

Extension regions may be confusing on a single page master. So far everything is computed relative to the beginning of the page. What about using multiple region bodies of XSL-FO 1.1? That solution would give users more freedom but would require them to impose alignment constraint among regions.

Open issue: 7566

The spec needs to clarify the relation between marginalia and footnotes. In particular, we need to decide whether the marginalia areas can collapse if there's no marginalia. Do we want such a dynamic behavior? There is a note in the requirement document about marginalia and footnotes but it seems to be mainly related to numbering issues.

2.4.1.1 The "extension-region-start" Region

Used to define a rectangular region that extends from the region-body along the "start" direction to contain marginalia, if they exist.

The specification will need to handle non-rectangular regions too here; this is work in progress. [no specific bugillza item for this: it is pervasive]

The extension-region-start specifies a viewport/reference pair that is located on the "start" side of the region-body, meaning that the before edge of the extension-region is aligned with the before-edge of the region-body and the end-edge of this region is parallel to the start-edge of the region-body, at a distance specified by the "distance"attribute.

None.

Empty.

2.4.1.2 The "extension-region-end" Region

Used to define a rectangular region that extends from the region-body along the "end" direction to contain marginalia, if they exist.

The "extension-region-end" region specifies a viewport/reference pair that is located on the "end" side of the region-body. The before-edge of this region is aligned with the before-edge of the region-body and the start-edge of this region is parallel to the end-edge of the region-body, at a distance specified by the "distance" attribute.

None.

Empty.

2.4.1.3 distance

Specifies the distance between the edge of the region-body and the edge of the extension region to which it applies.

Value:	<length> \| <percentage>
Initial:	0pt
Inherited:	no
Percentages:	refer to the corresponding inline-progress-dimension of the page-viewport-area.
Media:	visual

If it applies to fo:extension-region-end, it indicates the distance between the start-edge of the extension region and the end-edge of the region-body. If it applies to to:extension-region-start it indicates the distance between the end-edge of the extension region and the start-edge of the region-body.

<length>: This is an unsigned length. Negative values are treated as if they were zero.
<percentage>: The value is a percentage of the corresponding inline-dimension of the page-viewport-area.

2.4.2 Formatting Objects for Marginalia

2.4.2.1 fo:marginalia

The fo:marginalia formatting obiect is intended to be used to produce marginalia, positioned in a separate area external to the start-edge or end-edge of the region-body.

The fo:marginalia formatting object does not generate any areas. The fo:marginalia formatting object returns the areas generated and returned by its child fo:inline formatting object. The fo:inline element is optional.

The fo:inline formatting object is also useful for numbered marginalia, requirement 2.2.3.1.

If the fo:inline is empty, the fo:marginalia object does not generate any area.

Additionally the fo:marginalia formatting object returns the block-areas with area class "xsl-marginalia" generated by its fo:marginalia-body child. The areas with area-class "xsl-marginalia" are placed as children of the marginalia-reference-area in the corresponding extension region.

An fo:marginalia is not permitted to have an fo:marginalia, fo:float, fo:footnote, or fo:marker as a descendant. Additionally, an fo:marginalia is not permitted to have as a descendant an fo:block-container that generates an absolutely positioned area.

The term "marginalia-body-area" is defined to mean the first area generated and returned by the fo:marginalia-body, child of the fo:marginalia.

The term "anchor-area" is defined to mean the line area parent of the area generated by the fo:inline child of the fo:marginalia. If the fo:marginalia does not generate any area, the anchor-area is the previous line area in the pre-order visit of the area tree.

These terms are used to specify how to align a marginalia with the text it refers to, setting the "marginalia-relative-align" property. See details below.

The following properties apply to this formatting object:

(inline?,marginalia-body)

marginalia-destination-area: to indicate the marginalia-reference-area where the block-areas generated by the child "fo:marginalia-body" will be placed. This property can be inherited.
Possible values of this attribute are:
marginalia-relative-align: to indicate the alignment of the marginalia with respect to the text it refers to. This property specifies the alignment, in the block-direction, between two areas.
Possible values of this attribute are:
- "before": the before-edge of the marginalia-body-area is placed aligned with the before-edge of the anchor-area.
- "baseline": the distance between the baseline of the marginalia-body-area is the same as the distance between the baseline of the anchor-area.

2.4.2.2 fo:marginalia-body

The fo:marginalia-body is used to generate the marginalia content.

The fo:marginalia-body generates and returns one or more block-level areas with area-class "xsl-marginalia". The areas with area-class "xsl-marginalia" are placed as children of the marginalia-reference-area in the corresponding extension region.

The fo:marginalia-body is only permitted as a child of an fo:marginalia.

The position of a marginalia in the page (i.e., the corresponding marginalia-reference-area) is indicated in the "marginalia-destination-area" attribute of the "fo:marginalia formatting object."

Areas with area-class equal to "xsl-marginalia "are defined to be "stackable", indicating that they are supposed to be stacked, in the block-direction within their marginalia-reference-area. In addition a "special stacking rule" has to be applied for placing marginalia in the marginalia-reference-area.

The term "marginalia-body-area" is defined to mean the first area generated and returned by the fo:marginalia-body. The term "anchor-area" is defined to mean the line area parent of the area generated by the fo:inline child of the fo:marginalia. If the fo:marginalia does not generate any area, the anchor-area is the previous line area in the pre-order visit of the area tree.

The offset of the before-edge of the marginalia-body-area from the before-edge of the marginalia-reference-area cannot be smaller than the offset of the before-edge of the anchor-area from the before-edge of the region-reference-area. This constraint makes marginalia anchored to the text they refer to.

The "marginalia-relative-align"property of the fo:marginalia formatting object allows users to further specify the alignment of a marginalia with the text it refers to.

The following properties apply to this formatting object:

Common accessibility properties; id; index-class; index-key.

2.4.2.3 marginalia-destination-area

Specifies the marginalia-reference-area in which to place the block-areas generated by the child fo:marginalia-body to which it applies.

Value:	start \| end \| inside \| outside \| inherit
Initial:	start
Applies to:	fo:marginalia
Inherited:	yes
Percentages:	Not applicable.
Media:	visual

start: The content of the marginalia will be placed in the extension-region-start region.
end: The content of the marginalia will be placed in the extension-region-end region.
inside: The content of the marginalia will be placed in the extension-region-end region on even pages and in the extension-region-start region on odd pages.
outside: The content of the marginalia will be placed in the extension-region-start region on even pages and in the extension-region-end region on odd pages.

2.4.2.4 marginalia-relative-align

Specifies the alignment of the marginalia with respect to the text to which it refers. This property specifies the alignment, in the block-direction, between two areas.

Value:	before \| baseline \| end \| inherit
Initial:	before
Applies to:	fo:marginalia
Inherited:	yes
Percentages:	Not applicable.
Media:	visual

A general comment: vertical positioning (and justification) is connected to regions and columns, and the interaction between them, and that work is not yet complete. In addition, the term Vertical in this section should be taken to mean block-direction.

before: The before-edge of the marginalia-body-area is aligned with the before-edge of the anchor-area.
baseline: The distance between the baseline of the marginalia-body-area is the same as the distance between the baseline of th anchor-area extension-region-start region.
end: The after-edge of the marginalia-body-area is aligned with the after-edge of the anchor-area.

2.5 Vertical Positioning

2.5.1 Feathering

Feathering is the process of fitting a block of text to available space, such as the height of the page, for example by adding a small (and ideally imperceptible) amount of space between each line of text. The formatter adjusts the space-before and space-after traits of the stacked block-areas and line-areas in order to fill the reference area.

Feathering can be seen as a special case of vertical justification, where the set of adjustable properties is fixed (line-height, space-before and space-after).

Thus, our proposal is to activate feathering by indicating that vertical justification is done by adjusting those properties. This can be done by setting the property display-align to "justify" and by listing the names "line-height", "space-before", "space-after" in the "adjustable-properties" property. The short-hand "feathering" can be used as a value for this property instead.

Space-specifiers (minimum, optimum and maximum) are used to specify constraints on the amount of space to be added, as explained for vertical justification ([ADD LINK]).

2.5.2 Correlating vertical position

See the XSL-FO 2.0 Requirements Document, section 2.2.4.2

Add support for correlating vertical position so that lines of text on two adjacent pages, columns or regions are visually next to each other. Also support alignment of the two sides of the same sheet, so that the lines of text on the back side and front side of the sheet are aligned. Note that this requirement is different from optical alignment. The problem arises if pages/columns contain objects whose height is different than the normal line-height. Some space must be added before/after those objects in order to adjust the layout.

To address this we introduce a new property that specifies a "normalized line height" that must be used as an atomic unit of height. That property specifies a length that the block -dimension of each generated area must be a multiple of. Spaces are added before/after each generated area in order to adjust the block-dimension. In a multi-column region, the same value is used for all columns.

A provisional name is "block-unit", whose value is a length.

2.5.2.1 block-unit

When this property is set and non-zero, the block dimension of each generated area must be rounded up to the nearest multiple of the property value.

Value:	<length>
Initial:	0pt
Applies to:	fo:region-body, fo:region-before, fo:region-after, fo:region-start, fo:region-end, fo:block-container
Inherited:	yes
Percentages:	Not applicable.
Media:	visual

A value of zero means that there is no such constraint on the area block dimension.

The block dimension of each generated area should be rounded up to the nearest greater value that is an integer multiple of the specified length. The difference between the original block dimension and the rounded one MUST be transformed into a space-before and / or a space-after (according to the area position and the space conditionality).

For example, suppose that a region has block-unit="12pt". Each block <fo:block line-height="10pt" line-stacking-strategy="font-height" >Text ......</fo:block> will have a block dimension equal to N * 12pt (the block dimension of each line area is not changed). So, if the block creates eight line areas, the first two placed at the bottom of a page and the other six at the beginning of the next page, the first block area will be given a block dimension equal to 24pt (with a 4pt space-before) and the second block will have a 60pt block dimension with no extra space.

The property applies to fo:region-* and fo:block-container, and defines how to adjust the block dimension of the first-level block formatting objects (the direct children of either fo:flow or fo:static-content).

The intended consequence is that lines of text on facing pages will line up, and also that show-through of lines printed on the other side of a page will be reduced, because the lines of text are printed in corresponding places on each side of the paper.

2.5.3 Vertical alignment within a page or column

See the XSL-FO 2.0 Requirements Document, section 2.2.4.3

Add support for vertical alignment, such as centering the content of the columns or aligning to the bottom within pages, regions or columns.

Note:

This section does not yet take new work on columns (elsewhere in this document) into account.

For this, we use the existing "display-align" property:

In a multi-column region the same value is used for all columns, apart from the last one (specified with the property "display-align-last-column").

Applies to: fo:region-body, fo:region-before, fo:region-after, fo:region-start, fo:region-end and fo:block-container.

Note:

Property "display-align" also applies to: fo:external-graphic, fo:instream-foreign-object, fo:inline-container, and fo:table-cell. A similar issue exists for vertical justification.

2.5.4 Vertical alignment specific for the last column

See the XSL-FO 2.0 Requirements Document, section 2.2.4.4

Allow users to do alignment specific to the last column.

2.5.4.1 display-align-last-column

Specifies how to align the last column of a multi-column region. This property specifies the alignment, in the block-direction, of the areas that are the children of a reference-area.

Value:	<auto \| before \| center \| after \| inherit
Initial:	auto
Applies to:	fo:region-body
Inherited:	no
Percentages:	Not applicable.
Media:	visual

Values for the property have the following meaning:

auto: If the "relative-align" property applies to this formatting object the "relative-align" property is used. If not, this value is treated as if "before" had been specified.
before: The before-edge of the allocation-rectangle of the first child area is placed coincident with the before-edge of the content-rectangle of the reference-area;
center: The child areas are placed such that the distance between the before-edge of the allocation-rectangle of the first child area and the before-edge of the content-rectangle of the reference-area is the same as the distance between the after-edge of the allocation-rectangle of the last child area and the after-edge of the content-rectangle of the reference-area;
after: The after-edge of the allocation-rectangle of the last child area is placed coincident with the after-edge of the content-rectangle of the reference-area.

2.5.5 Vertical justification across pages and columns

See the XSL-FO 2.0 Requirements Document, section 2.2.4.5

Add support for adjusting properties to do vertical justification within a page, a region or a column, as well as across regions.

We extend the display-align property with a new value "justify".

It is also important to allow users to specify which properties should be modified in order to do vertical justification. Feathering is one of the possibilities. Other solutions might include widening or narrowing spaces before and after images and tables, stretching or compressing text, changing word-spacing, adjusting the character-spacing, or other strategies.

Thus, we propose the general approach of adjustable properties as described under ‘copyfitting’ and introduce a property adjustable-properties whose value is a list of properties that the formatter is allowed to change.

Note:

The display-align property also applies to fo:external-graphic, fo:instream-foreign-object and fo:inline-container.

2.5.6 display-align

This property specifies the alignment, in the block-direction, of the areas that are the children of a reference-area.

Value:	auto \| before \| center \| after \| inherit \| justify
Initial:	auto
Inherited:	yes
Percentages:	N/A
Media:	visual

If the relative-align property applies to this formatting object the "relative-align" property is used. If not, this value is treated as if "before" had been specified.

before

The before-edge of the allocation-rectangle of the first child area is placed coincident with the before-edge of the content-rectangle of the reference-area.

center

The child areas are placed such that the distance between the before-edge of the allocation-rectangle of the first child area and the before-edge of the content-rectangle of the reference-area is the same as the distance between the after-edge of the allocation-rectangle of the last child area and the after-edge of the content-rectangle of the reference-area.

after

The after-edge of the allocation-rectangle of the last child area is placed coincident with the after-edge of the content-rectangle of the reference-area.

justify

For each reference area generated by a region, the before-edge of the its content-rectangle is placed coincident with the before-edge of the allocation-rectangle of the first child area, and the after-edge of the its content-rectangle should be placed coincident with the after-edge of the allocation-rectangle of the last child area. If the application is not able to achieve copyfitting and the accumulated block-dimension of areas is less the the block-dimension of the reference area (which could happen either for lack of elasticity in the content or for partial support by the formatter), the areas are placed as if "auto" had been specified.

Note that for block-containers and table cells, the available space (height and width) must be known in advance in order for the implementation to be able to fit the text into that space.

2.5.7 display-align-last

This property specifies in the block-direction, of the areas that are the children of a reference-area. It is used to express the alignment of a region in the last page or in any page ending with a forced break.

Value:	auto \| before \| center \| after \| inherit \| justify
Initial:	auto
Inherited:	yes
Percentages:	N/A
Media:	visual

auto: If the relative-align property applies to this formatting object the "relative-align" property is used. If not, this value is treated as if "before" had been specified.
before: The before-edge of the allocation-rectangle of the first child area is placed coincident with the before-edge of the content-rectangle of the reference-area.
center: The child areas are placed such that the distance between the before-edge of the allocation-rectangle of the first child area and the before-edge of the content-rectangle of the reference-area is the same as the distance between the after-edge of the allocation-rectangle of the last child area and the after-edge of the content-rectangle of the reference-area.
after: The after-edge of the allocation-rectangle of the last child area is placed coincident with the after-edge of the content-rectangle of the reference-area.
justify: For each reference area generated by a region, the before-edge of the its content-rectangle is placed coincident with the before-edge of the allocation-rectangle of the first child area, and the after-edge of the its content-rectangle should be placed coincident with the after-edge of the allocation-rectangle of the last child area. If the application is not able to achieve copyfitting and the accumulated block-dimension of areas is less the the block-dimension of the reference area (which could happen either for lack of elasticity in the content or for partial support by the formatter), the areas are placed as if "auto" had been specified.

2.6 Tables and Lists

2.6.1 Decimal Alignment

See the XSL-FO 2.0 Requirements Document, section 2.2.5.1

To improve decimal alignment, extend the character alignment in table cells to permit a specification of the horizontal position of the alignment point within the column.

Text alignment is ordinarily the same for all cells in a column, so the natural choice is to specify the "text-align" property on the fo:table-column and specify 'text-align="from-table-column()"' on all the fo:table-cell objects in that column. To specify a value other than the default for a specific fo:table-cell in the table-column, use that value in the "text-align" property.

The only accepted value for fo:table-column would be "left", "right", and "decimal" (newly added). When the value is "decimal", each cell's text is aligned on the decimal separator as determined by the locale setting, e.g. "." or ",".

2.6.1.1 Considerations

In Microsoft Excel or spreadsheet, the alignment of text in a cell is usually done based on the data's type, e.g. alphabetic text is usually aligned to the left, numbers are usually aligned to the right, and Boolean values are usually aligned to the center. Do we also need to extend the "text-align" property to allow automatic alignment? Should decimal alignment could be a special case for number alignment?

Text in the cells with a single table may be numbers and strings with mixed fonts and properties. Do we also need to provide a guide of the fallback mechanism if the alignment point cannot be determined?

Consider a long table that has tens of thousands of rows. Aligning a column with decimal alignment will have huge impact on the performance on the rendering of the table, since the formatter must know the position of the decimal point in the cell in every row of the column before it can start to calculate the appropriate alignment for all the cells.

Also, inspired by the OASIS table model, should we add a new property only available for either table-cell or table-column called "text-align-charoff". This property would be used if and only if "text-align" is given a single-character string as its value. The value for the "text-align-charoff" property would be the same as the OASIS table model, i.e. specifying a percentage of current column width between the start-edge (as determined based on the "writing-mode") and the point at where the character is aligned. For example, the default value "50" would specify that the character is aligned at the center of the column.

<table-cell text-align="'.'">...

2.6.2 Table header/footer on boundaries

See the XSL-FO 2.0 Requirements Document, section 2.2.5.2

Be able to specify different instances of what the table header or footer should be depending on the different boundaries (page, column and region). This also would allow specifying that certain headers must be omitted at certain boundaries.

Similar to fo:page-sequence-master-alternatives and selecting page masters, provide new formatting objects for selecting alternative headers and footers for tables: fo:table-header-alternatives, fo:table-footer-alternatives, fo:conditional-table-header-reference, and fo:conditional-table-footer-reference.

fo:table-header-alternatives is a child object of fo:table-header. It doesn't have any properties.

fo:table-footer-alternatives is a child object of fo:table-footer. It does not have any properties.

fo:conditional-table-header-reference is a child of fo:table-header-alternatives. It has a header-position property.

fo:conditional-table-footer-reference is a child of fo:table-footer-alternatives. It has a footer-position property.

The valid values for both "header-position" and "footer-position" are "page", "column" and "region". If a fo:conditional-table-header or fo:conditional-footer-reference doesn't have "header/footer-position" property, it's the default reference for the table.

Sample XSL FO snippet:

	    <fo:table>
	      <fo:table-header>
	        <fo:table-header-alternatives>
	          <fo:conditional-table-header-reference> 
	            ...
	          </fo:conditional-table-header-reference>
	          <fo:conditional-table-header-reference header-position="page">
	            ...
	          </fo:conditional-table-header-reference>
	            <fo:conditional-table-header-reference header-position="column">
	              ...
	          </fo:conditional-table-header-reference>
	          ...
	        </fo:table-header-alternatives>
	      </fo:table-header>
	      <fo:table-footer>
	        <fo:table-footer-alternatives>
	        </fo:table-footer-alternatives>
	      </fo:table-footer>
	      <fo:table-body>
	        ...
	      </fo:table-body>
	    </fo:table>

2.6.2.1 fo:conditional-table-layout-reference

It's relatively cumbersome to use different formatting objects that distinguish alternative headers from alternative footers, so a single object could be introduced to represent the concept e.g. a fo:table-layout-alternatives. Its parent object would determine whether this object represents a header or a footer. The reference object would correspondingly be named fo:conditional-table-layout-reference.

2.6.2.2 Split tables

See the XSL-FO 2.0 Requirements Document, section 2.2.5.3

Allow users to specify that tables can be split horizontally. It should be possible to have a column repeated when the table is split horizontally, by specifying a row header. There should be a way to keep the split parts visually next to each other depending on binding edge.

In case a table is split over multiple pages and both the rows and columns don’t fit a page, allow users to specify which table part comes out in which order (rows first or columns first).

When printing from spreadsheet applications, printing a table that overflows a single page as series of pages, usually with repeated header rows and columns, is common. Within XSL FO, overflow behavior is specified with the "overflow" property, but the XSL 1.1 "overflow" property has similar semantics to CSS and does not sufficiently handle overflow on tables.

2.6.2.2.1 table-overflow

Value:	paginate-column-first \| paginate-row-first \| auto
Initial:	auto
Applies to:	fo:table
Inherited:	no
Percentages:	Not applicable.
Media:	paged

The "table-overflow" property specifies the method for paginating a large table into multiple pages.

paginate-column-first: Paginate columns before rows
paginate-row-first: Paginate rows before columns.
auto: This is the default behavior. The User Agent determines the pagination method.

Open issue: 8860

Should other values of "overflow" property be allowed for the "table-overflow" property, e.g. "visible", "hidden", "scroll", and "error-if-overflow"?

Note:

Normally, we would expect the row header and the column header to be repeated during the pagination, but do we need to add another property to allow the user to override the default behavior or to suppress the behavior? Maybe table-omit-header-at-break and table-omit-footer-at-break apply to the alternatives and/or conditional references.

2.6.2.3 Repeat contents of split spanned cell

See the XSL-FO 2.0 Requirements Document, section 2.2.5.4

Allow users to specify that when a spanned cell in a table is split, the entire cell contents should be repeated on each table instance. This applies to splitting as well as spanning in the block-direction as well as the inline-direction.

In paged media, a table cell may be split, either vertically or horizontally or both, because another table cell in the same row or column overflows its available area. Additionally, a table cell that spans multiple rows or columns may be split because the rows or columns that it spans are paginated on separate pages.

Allow the "overflow" property to be applied to fo:table-cell and add the "repeat" value that applies only to fo:table-cell.

When the value is "repeat", the content of the fo:table-cell will be repeated on the next page.

2.6.2.4 Cell borders extending beyond the table

See the XSL-FO 2.0 Requirements Document, section 2.2.5.5

Allow the column lines to extend down or right the table to visually indicate that the table continues. When this happens, any vertical border should be extended beyond the bottom border for the last row or right column [on the page].

This applies to pagination of tables split vertically, horizontally or both vertically and horizontally.

XSL 2.0 defines the following properties: "border-break", "border-before-break", "border-after-break", "border-start-break" and "border-end-break". Their allowed values are: "auto", "hidden" and "extend".

When the value is "extend", the respective border is extended till the end of the area.

2.6.2.4.1 3.5.1 Considerations

When the "border-collapse" property is set to be "collapse", which value of the "border-break" value takes higher priority? "extend"?

When the "border-collapse" property is set to be "separate", if one of the adjacent borders set the "border-break" property to be "auto" or "hidden", but the other is set to be "extend", the rendered table border will looks like this:

The table has borders around every cell except the bottom right hand cell, which lacks the bottom and right borders.

Figure 24. Example of spread-viewport-area.

Open issue: 8861

Do we need to set the "border-break" style at the fo:table-row level and fo:table-column level, or at table-cell level as proposed here?

2.6.2.5 Adjacent borders

See the XSL-FO 2.0 Requirements Document, section 2.2.5.6

When one formatting object is immediately preceding another in block-dimension, be able to specify what to do with their adjacent borders.

Allow the "border-collapse" property on other formatting objects in addition to fo:table-cell, e.g. fo:block and fo:inline.

2.6.2.6 Borders on break

See the XSL-FO 2.0 Requirements Document, section 2.2.5.7

Allow having different borders when a break occurs so that a formatting object is split, e.g. a cell that splits, have a thinner border for the split.

Define properties "border-break-style", "border-start-break-style", "border-end-break-style", "border-before-break-style", and "border-after-break-style". The properties' values are the same as for the "border-style" property, and the same border conflict resolution rules CSS border conflict resolution rules apply.

2.6.2.7 Spanning cell over all row and columns

See the XSL-FO 2.0 Requirements Document, section 2.2.5.8

The current specification of XSL says that number-rows-spanned and number-columns-spanned should be a positive integer. Other specifications, such as HTML 4.01, allow 0 as a value, which means that all rows or columns of the current table section are spanned over. This behavior may be added to XSL 2.0, either by allowing 0 as a value, or some other solution.

Allow "0" as a value for the "number-rows-spanned" and "number-columns-spanned" properties, with the same semantics as for HTML 4.01 as described at http://www.w3.org/TR/html4/struct/tables.html#adef-colspan

Open issue: 8862

It would be better to use "all" as a value, but that is not compatible with HTML. Should we allow either?

2.6.3 Columns

XSL-FO 2.0 extends the multi-column facility of XSL-FO 2.1 by adding the ability to have columns of different widths, different colours, etc. and by allowing any fo:block-container to have columns.

See the XSL-FO 2.0 Requirements Document, section 2.2.11.1

Add support for column balancing.

Note:

Not yet addressed.

Requirement:

See the XSL-FO 2.0 Requirements Document, section 2.2.11.2

Add support for spanning over less than the total number of columns.

Note:

Not yet addressed.

Requirement:

See the XSL-FO 2.0 Requirements Document, section 2.2.11.3

Allow the span property to have effect when specified on formatting objects that are not direct children of an fo:flow.

Note:

Not yet addressed.

Requirement:

See the XSL-FO 2.0 Requirements Document, section 2.2.11.4

Give control over how the text flows when spanning columns over the entire page.

Note:

Not yet addressed.

Requirement:

See the XSL-FO 2.0 Requirements Document, section 2.2.11.5

Allow specifying multiple columns of different widths.

Requirement:

See the XSL-FO 2.0 Requirements Document, section 2.2.11.6

Allow specifying multiple columns in all regions and also in block-containers, not just the region-body.

2.6.3.1 column-count

Value:	<number> \| auto \| inherit
Initial:	1
Inherited:	no
Percentages:	Not applicable.
Media:	visual

The column-count property specifies the number of columns in the region, block-container.

<number>: A positive integer greater than zero. It is an error to supply a value that is not a positive integer greater than zero.
auto: The value of the column-count property is calculated from fo:column-definition elements appearing in an fo:column-definitions element, which must be the first element child of this formatting object. If there is no fo:column-definitions element, a default value of 1 MUST be used. If the column-count property is explictly set to a number, that number MUST be used, even in the presence of an fo:column-definitions element. However, if fo:column-definitions is present and the column-count property is set, they must agree with each other about the number of columns.

A value of 1 indicates that this is not a multi-column region or block-container.

Static content that repeats on every page can be formatted into multiple columns by nesting a block-container inside fo:static-content elements in a page master.

2.6.3.2 fo:column-definitions

The fo:column-definitions element is a wrapper around zero or more fo:column-definition elements.

No areas are generated by this element.

The fo:column-definitions element is only permitted as a child of a region of block-container; it must be the first child (disregarding white-space).

The following properties apply to this formatting object:

(fo:column-definition | fo:column-gap)+

Should you be able to set default properties for all columns here?

2.6.3.3 fo:column-definition

Use the fo:column-definition element to set properties that will be inherited by content in column areas, and also to define the number of columns in the corresponding region or block-container.

Columns are arranged in inline order, with the column contents stacked in the block direction inside them. The first column is numbered 1, the second 2, and so on. Properties set on fo:column-definition elements apply to respective columns: properties from the first fo:column-definition element are applied to the first column, properties from the second fo:column-definition element are applied to the second column, and so on.

If a column-number property is set on an fo:column-definition element, it refers to that column.

No areas are generated directly by this element.

The fo:column-definition element is only permitted as a child of a fo:column-definitions element.

If a fo:column-definitions element is used, it MUST contain exactly one fo:column-definition element for each column.

The following properties apply to this formatting object:

EMPTY

id; any style property.

column-number

Implementations that support multiple columns MUST support properties that do not depend on the result of formatting, such as background-color, and SHOULD support properties such as color which do not affect formatting or copy-fitting.

Implementations MAY also support properties that affect copy-fitting and formatting on a per-column basis, such as having column widths that vary, or setting one or more columns in a different font or size.

Properties explicitly set on formatting objects in the flow override values set on fo:column-definition elements.

2.6.3.4 fo:column-gap

The fo:column-gap element represents the space between columns, or before the first column, or after the last column. It can be given a width, a background-color, and may also contain formatting objects to be rendered in the space between columns on each place. Use fo:column-gap if you want to have different gaps between columns, or if you want some columns to have a rule drawn between them and not others, or to specify the style or extent of the rule, or to contain static content.

If there is no fo:column-gap element between two columns, the value of the column-gap property is used to separate them.

No areas are generated directly by this element; areas are generated when the column gap is actually rendered.

The fo:column-gap element is only permitted as a child of a fo:column-definitions element.

The following properties apply to this formatting object:

fo:block*

id; any style property.

column-rule and column-rule-position are not yet included.

2.6.3.5 Example of Columns

Consider a text set in three columns, with the third column being wider, perhaps to give room to illustrations. Figure 25 shows the intended effect.

A text about the architecture of Ancient Greek stone columns is set on a page divided into three columns; the third column is wider, and incorporates a photograph of a modern-era classical revival building with fluted columns.

Figure 25. Text set in three columns, where the third column is wider than the other two.

    <fo:block-container>
      <fo:column-definitions>
        <fo:column-definition column="1" width="25%" />
        <fo:column-definition column="2" width="25%" />
        <fo:column-definition column="3" width="50%" />
      </fo:column-definitions>
      <fo:block>
          The Greek orders, within our recollection,
          were regarded as things which if used,
          could not receive any addition or modification.
          Yet, in the antique, the variety in the small number of examples,
          as in the Ionic capital, was considerable; 
          [ . . . ]
      </fo:block>
    </fo:block-container>

2.6.4 Layout master set

2.6.4.1 Interleaving layout-master set

See the XSL-FO 2.0 Requirements Document, section 2.2.12.1

Be able to define layout-master-sets not only at the top of the FO tree, but also interleaving page-sequences, to allow users to define and change masters, such as simple-page-master and page-sequence master, on the fly instead of having to specify all the masters in the beginning of the FO tree. When traversing the FO tree in pre-order traversal, the master must be defined before it may be referenced by a master-reference property.

Note:

This section is currently worded as a set of changes to XSL-FO 1.1

There are two parts to fulfilling this requirement: modifying allowed contents to allow extra "fo:layout-master-set" elements to appear, and adjusting the wording of the spec to say what happens when it occurs.

Allowed contents

For fo:page-sequence-wrapper, allow fo:layout-master-set where you can now have fo:page-sequence or fo:page-sequence-master:

Change the content model from:

(page-sequence|page-sequence-wrapper)*

to:

(layout-master-set,declarations?,bookmark-tree?,
	    (layout-master-set|page-sequence|page-sequence-wrapper)+)

Changes

The following changes to XSL 1.1 are proposed to satisfy this requirement:

2.6.4.1.1 Formatting Objects Summary

The fo:layout-master-set is a wrapper around all masters used in the document.

The fo:layout-master-set is a wrapper around masters used in the document.

2.6.4.1.2 "Declarations and Pagination and Layout Formatting Objects" introduction

The children of the fo:root formatting object are a single fo:layout-master-set, an optional fo:declarations, an optional fo:bookmark-tree, and a sequence of one or more fo:page-sequences and/or fo:page-sequence-wrapper elements.

The children of the fo:root formatting object are a fo:layout-master-set, an optional fo:declarations, an optional fo:bookmark-tree, and a sequence of one or more fo:layout-master-set and/or fo:page-sequences and/or fo:page-sequence-wrapper elements.

The fo:layout-master-set defines the geometry and sequencing of the pages

The fo:layout-master-sets define the geometry and sequencing of the pages

The children of the fo:layout-master-set are the pagination and layout specifications and flow-map specifications.

The children of the fo:layout-master-sets are the pagination and layout specifications and flow-map specifications.

2.6.4.1.3 fo:root

This is the top node of the formatting object tree. It holds an fo:layout-master-set formatting object (which holds all masters used in the document), an optional fo:declarations, an optional fo:bookmark-tree, and one or more fo:page-sequence or fo:page-sequence-wrapper objects.

This is the top node of the formatting object tree. It holds an fo:layout-master-set formatting object, an optional fo:declarations, an optional fo:bookmark-tree, and one or more of fo:layout-master-set, fo:page-sequence or fo:page-sequence-wrapper objects. An fo:layout-master-set holds masters used in the document.

Change the contents to:

(layout-master-set,declarations?,bookmark-tree?,
	      (layout-master-set|page-sequence|page-sequence-wrapper)+)

2.6.4.1.4 fo:page-sequence

If the flow-map-reference is specified, the flow-map in effect is the one described by the fo:flow-map child of the fo:layout-master-set having a flow-map-name matching the specified value of flow-map-reference on the fo:page-sequence.

If the flow-map-reference is specified, the flow-map in effect is the one described by the closest preceding fo:flow-map (this is a child of a preceding fo:layout-master-set) having a flow-map-name matching the specified value of flow-map-reference on the fo:page-sequence.

2.6.4.1.5 fo:layout-master-set

The fo:layout-master-set is a wrapper around all masters used in the document. This includes page-sequence-masters, page-masters, and flow-maps.

The fo:layout-master-set is a wrapper around masters used in the document. This includes page-sequence-masters, page-masters, and flow-maps.

2.6.4.1.6 'master-name'

Names identify masters, may not be empty and must be unique.

Names identify masters, MUST NOT be empty and must be unique within an fo:layout-master-set.

A master-name must be unique across all page-masters and page-sequence-masters.

A master-name must be unique across all page-masters and page-sequence-masters within an fo:layout-master-set.

2.6.4.1.7 'master-reference'

The names need not be unique, but may not be empty and must refer to a master-name that exists within the document.

The names need not be unique, but MUST NOT be empty and must refer to a master-name that exists within the current or a preceding fo:layout-master-set.

If the name is empty or if a name-conflict is encountered, an error shall be reported. A processor may then continue processing.

If the name is empty, an error shall be reported. A processor may then continue processing.

If a name-conflict is encountered, the last specified master-name is used.

2.6.4.1.8 'flow-name'

No change required.

2.6.4.1.9 'flow-name-reference'

Some difficulties here: 'flow-name-reference' is a "soft" reference; the flows currently always occur after these references; this current constraint is too loose even for XSL 1.1:

The name identifies a flow; it MUST NOT be empty and must refer to a flow-name that exists within the document.

The definition of fo:flow-map at least includes:

The source list is a sequence of flow names whose corresponding fo:flow objects (in the referring fo:page-sequence) are treated as a single fo:flow for composition purposes.

where "(in the referring fo:page-sequence)" seems a more useful constraint than "within the document".

2.6.4.1.10 'region-name'

No change required.

2.6.4.1.11 'region-name-reference'

The name identifies a region; it may not be empty and must refer to a region-name that exists within the document.

The name identifies a region; it MUST NOT be empty and must refer to a region-name that exists within the current or a preceding fo:layout-master-set.

or it may be best to leave it as-is.

2.6.4.2 Change master every n pages

See the XSL-FO 2.0 Requirements Document, section 2.2.12.2

Have sets of pages repeatable within the same page-sequence.

Requirement:

See the XSL-FO 2.0 Requirements Document, section 2.2.12.3

Allow specifying that every n-th page, a different master should be used. This is a specific case of 2.2.12.2 Repeatable sub-sequence-specifier. For example, use master A for page 1, 2, 3, 4, then master B for page 5, then master A again for 6, 7, 8, 9 then master B for page 10, etc...

To address this requirement, three changes to XSL 1.1 are proposed:

Add 'sequence-repeats' to 'fo:repeatable-page-master-alternatives'

Allow numbers in 'page-position'

Adjust 'fo:repeatable-page-master-alternatives' and 'fo:conditional-page-master-reference' definitions accordingly

2.6.4.2.1 sequence-repeats

Specifies the number of pages in a cyclic sub-sequence of pages that may be generated before the cycle repeats.

Value:	<number> \| no-limit \| inherit
Initial:	no-limit
Inherited:	no
Percentages:	Not applicable.
Media:	all

The values are as follows:

no-limit

No constraint is specified.

<number>

The maximum number of pages in the sub-sequence cycle.

The value is an integer greater than or equal to 0.

If a fractional value or a value less than 0 is specified, it will be rounded to the nearest integer greater than or equal to 0.

A value of 0 indicates this sub-sequence-specifier will not be used.

2.6.4.2.2 page-position

This property forms part of a selection rule to determine if the referenced page-master is eligible for selection at this point in the page-sequence or, when the "sequence-repeats" property value is not "no-limit", at this point in the sub-sequence cycle.

Value:	<number> \| only \| first \| last \| rest \| any \| inherit
Initial:	any
Inherited:	no
Percentages:	Not applicable.
Media:	all

The values have the following meanings:

<number>

This master is eligible for selection if the value is equal to the current page number or, when the "sequence-repeats" property value is not "no-limit", at this point in the sub-sequence cycle.

For example: when "sequence-repeats" is 'no-limit', '4' is true for the fourth page in the page-sequence only; when "sequence-repeats" is '4', '4' is true for the fourth, eighth, twelfth, etc. pages in the page-sequence; and when "sequence-repeats" is '6', '4' is true for the fourth, tenth, sixteenth, etc. pages.

The value is an integer greater than or equal to 0.

If a fractional value or a value less than 0 is specified, it will be rounded to the nearest integer greater than or equal to zero.

A value of 0 indicates this master-reference will not be used.

A value greater than the "sequence-repeats" value, when "sequence-repeats" is not 'no-limit', is false.

only

This master is eligible for selection if this is the only page (i.e. the page is both first and last) page in the page-sequence.

first

This master is eligible for selection if this is the first page in the page-sequence.

last

This master is eligible for selection if this is the last page in the page-sequence.

rest

This master is eligible for selection if this is not the first page nor the last page in the page-sequence.

any

This master is eligible for selection regardless of page positioning within the page-sequence.

Several of these values can be true simultaneously; for example, 'any' is always true, 'only' is true when both 'first' and 'last' are true, and 'first' and '1' are both true for the first page in a page-sequence. For that reason, it is necessary to order the fo:conditional-page-master-references so that the least inclusive test is performed before the more inclusive test which are also true.

2.6.4.2.3 fo:repeatable-page-master-alternatives

The fo:repeatable-page-master-alternatives formatting object is the most complex sub-sequence-specifier. It specifies a sub-sequence consisting of repeated instances of a set of alternative page-masters. The number of repetitions may be bounded or potentially unbounded. The repetitions may also be cyclic. Which of the alternative page-masters is used at any point in the sequence depends on the evaluation of a condition on the use of the alternative.

Typical conditions include testing whether the page which is generated using the alternative is:

The first or last page in a page-sequence;
Blank;
The nth page in a page-sequence or a page cycle

The full set of conditions allows different page-masters to be used for the first page, for odd and even pages, for blank pages, etc.

Because the conditions are tested in order from the beginning of the sequence of children, the last alternative in the sequence usually has a condition that is always true and this alternative references the page-master that is used for all pages that do not receive some specialized layout.

Areas:

The fo:repeatable-page-master-alternatives formatting object generates no area directly. This formatting object is used by the fo:page-sequence formatting object to generate pages.

Constraints:

The children of the fo:repeatable-page-master-alternatives are fo:conditional-page-master-references. These children are called alternatives.

The sub-sequence of pages mapped to this sub-sequence-specifier satisfies the constraints of this sub-sequence-specifier if (a) the sub-sequence of pages consists of zero or more pages, (b) each page is generated using the fo:simple-page-master referenced by the one of the alternatives that are the children of the fo:repeatable-page-master-alternatives, (c) the conditions on that alternative are true, (d) that alternative is the first alternative in the sequence of children for which all the conditions are true, and (e) the length of the sub-sequence is less than or equal to the value of maximum-repeats.

Contents:

(conditional-page-master-reference+)

The following properties apply to this formatting object:

maximum-repeats; sequence-repeats

2.6.4.2.4 fo:conditional-page-master-reference

The fo:conditional-page-master-reference is used to identify a page-master that is to be used when the conditions on its use are satisfied. This allows different page-masters to be used, for example, for even and odd pages, for the first page in a page-sequence, for the third page in a page-sequence cycle, or for blank pages. This usage is typical in chapters of a book or report where the first page has a different layout than the rest of the chapter and the headings and footings on even and odd pages may be different as well. Selecting page-masters based on position within a cycle is typical of bulk-mailed correspondence that is to be folded into envelopes by a folding machine.

Areas:

The fo:conditional-page-master-reference formatting object generates no area directly. It is used by the fo:page-sequence formatting object to generate pages.

Constraints:

The fo:conditional-page-master-reference has a reference to the fo:simple-page-master which has the same master-name as the master-reference trait on the fo:conditional-page-master-reference.

There are three traits, page-position, odd-or-even, and blank-or-not-blank that specify the sub-conditions on the use of the referenced page-master. All three sub-conditions must be true for the condition on the fo:conditional-page-master-reference to be true.

Since the properties from which these traits are derived are not inherited and the initial value of all the properties makes the corresponding sub-condition true, only the subset of traits that are derived from properties with specified values must have their corresponding sub-condition be true.

The sub-condition corresponding to the page-position trait is true if the page generated using the fo:conditional-page-master-reference has the specified position in the sequence of pages generated by the referencing page-sequence; namely, "first", "last", "only" (both first and last), "rest" (not first nor last) or "any" (all of the previous) or a number equal to the page number (or the number within the page cycle). The referencing page-sequence is the fo:page-sequence that referenced the fo:page-sequence-master from which this fo:conditional-page-master-reference is a descendant.

The sub-condition corresponding to the odd-or-even trait is true if the value of the odd-or-even trait is "any" or if the value matches the parity of the page number of the page generated using the fo:conditional-page-master-reference.

The sub-condition corresponding to the blank-or-not-blank trait is true, if (1) the value of the trait is "not-blank" and the page generated using the fo:conditional-page-master-reference has areas generated by descendants of the fo:flow formatting objects; if (2) the value of the trait is "blank" and the page generated using the fo:conditional-page-master-reference is such that there are no areas from any fo:flow to be put on that page (e.g., (a) to maintain proper page parity due to (i) a break-after or break-before value of "even-page" or "odd-page" or (ii) at the start or end of the page-sequence or (b) because the constraints on the areas generated by descendants of the fo:flow formatting objects would not be satisfied if they were descendant from this page); or if (3) the value of the trait is "any".

A "blank page" is a page generated under (2) of the sub-condition corresponding to "blank-or-not-blank" above. This has nothing to do with whether the page appears completely blank to the reader.

Contents:

EMPTY

The following properties apply to this formatting object:

master-reference; page-position; odd-or-even; blank-or-not-blank

<fo:page-sequence-master master-name="name">
		  <fo:repeatable-page-master-alternatives sequence-repeats="4">
		    <conditional-page-master-reference page-position="1" master-reference="page-1-of-4"/>
		    <conditional-page-master-reference page-position="2" master-reference="page-2-of-4"/>
		    <conditional-page-master-reference page-position="3" master-reference="page-3-of-4"/>
		    <conditional-page-master-reference page-position="4" master-reference="page-4-of-4"/>
		  </fo:repeatable-page-master-alternatives>
		<fo:page-sequence-master>

2.6.5 Spreads

See the XSL-FO 2.0 Requirements Document, section 2.2.17

Be able to treat two facing pages (a two page spread) as a single unit. For example to allow images to cross the page boundaries.

2.6.5.1 fo:spread-page-master

Used to define a two-page spread consisting of an even and odd page facing each other. The fo:spread-page-master refers to fo:simple-page-masters for the geometries of the pages and the definition of the pages' regions. The fo:spread-page-master may define additional regions that may be generated on one of the pages or may span both pages in the spread.

Picture of a viewport that spans two pages

Figure 26. Example of spread-viewport-area.

Diagram of a viewport that spans two pages

Figure 27. Example of spread-viewport-area, exploded for clarity.

Areas:

The fo:spread-page-master formatting object generates no area directly. It is used in the generation of pages by an fo:page-sequence.

When the fo:spread-page-master is used to generate pages, three viewport/reference pairs are generated, consisting of a spread-viewport-area and a spread-reference-area for the spread plus a page-viewport-area and a page-reference-area for each of the two pages. The page-viewport-areas represents the physical bounds of the output medium. The page-reference-areas represents the portion of the pages on which content is intended to appear; that is, the area inside the page margins.

When the "binding-edge" trait is "top", the two pages are generated such that the after-edge of the even page is adjacent to the before-edge of the odd page.

In addition, when the fo:spread-page-master is used to generate pages, viewport/reference pairs that correspond to the regions that are the children of the fo:spread-page-master are also generated. These regions are placed relative to the page-height and the page-width of the spread-viewport-area.

When a regions that is a child of the fo:spread-page-master has the same "region-name" as a region that is a child of the fo:simple-page-master for the even- or odd-page, only the child of the fo:spread-page-master generates areas.

Regions that are children of the fo:spread-page-master may span the two pages.

When a fo:spread-page-master is used in the generation of a spread, the block-dimension and inline-dimension of the content-rectangle of the spread-viewport-area are determined using the computed values of the "page-height" and "page-width" properties of the page-masters for the two pages and the "binding-edge" property of the fo:root.

If the value of the media-usage trait is bounded-in-one-dimension or unbounded, only the even-page single-page-master-reference is used.

The following properties apply to this formatting object:

(single-page-master-reference, single-page-master-reference, region*)

master-name; writing-mode

2.6.5.1.1 Would also affect text in:

Pagination FOs introduction, Currently http://www.w3.org/TR/xsl11/#pag-intro.

*-master-reference FOs

Depends on:

binding edge.

Note:

"page-viewport-areas" no longer represent the physical bounds of the output medium.

Open issue: 7569

What should retrieve-index-mark do for index hits on a double-page spread?

2.6.6 Bleeds and Trim

See the XSL-FO 2.0 Requirements Document, section 2.2.18

Add support for bleeds. For example, bleeds allow an image to go beyond the page boundaries so that when you print, bind and cut the paper you don’t have any white space showing.

The bleed is expressed at the page level and identifies the amount of content printed outside the page. The design is responsible for creating and placing content that goes into the bleed, for instance a larger background image or an absolutely positioned image. The trim indicates the correct page size after the trimming (cutting) has been applied. It could be the same as the page size but can also be slightly bigger for binding purposes.

Two properties on the fo:simple-page-master control bleed and trim

2.6.6.1 bleed-box, trim-box

The bleed-box property defines the size and position of a notional rectangle around the page in which ink might appear: an implementation should not normally render any content outside the bleed box, although it is not an error conition if content is placed there. The primary purpose of the bleed box is so that when a trimming machine cuts the printed page to size, graphics or other content can go all the way to the edge of the page, by virtue of being printed slightly beyond the place where the blade cuts. Hence, the trim box, whose size and position is specified by the trim-box property, is usually inside the bleed-box.

Value:	x1 y2 x2 y2
Initial:	0 0 0 0
Applies to:	page reference area
Inherited:	no
Percentages:	Not applicable.
Media:	paged

The values are as follows:

x1, y1: A relative offset from the page reference area origin, used to position the origin of the bleed and trim boxes, respectively. The coordinate system is the same as for the page reference area. The numbers are disances, may be negative.
x2, y2: Relative offsets from the corner of the page reference area that is diagonally opposite to its origin; if x1, y1, x2 and y2 are all zero (the default values) the rectangle will thus be the same size as, and in the same position as, the page reference area. The numbers are disances, may be negative.

We also need to add these to "fo:page-master" when that is defined. [no bugzilla entry for this item]

The diagram shows four nested rectangles, and marks them. First (outermost) is the paper edge, so that the diagram is showing a sheet of paper with three rectangles in it. The next rectangle is the bleeds box, and the printing reaches the edge of this box, but does not cover the gaps an all four sides between the bleeds box and the paper edge. The third rectangle in the diagram is the page reference area; the page reference area is inside the bleeds box. The final (innermost) rectangle is the trim box; everything outside the trim rectangle will be cut away (usually with a stamp or guillotine for book produuction, partly after binding). The trim rectangle is shown as innermost here, bit it could be the same as the page reference area or even outside it. The various rectangles are positioned by x1, y1, x2, y2 offsets from the top let and bottom right corners of the page reference area in the diagram.

Figure 28. Showing possible placement of bleeds and trim rectangles relative to the page reference area and the physical medium (paper).

2.7 Side by Side

See the XSL-FO 2.0 Requirements Document, section 2.2.6

Introduce a way to position objects next to each other. Side-by-side includes complex positioning and breaking rules (in some cases similar to the constraints necessary for marginalia).

The approach taken in this draft is to use the flow map to express that multiple separate flows are to be synchronized in layout. A single flow is designated as primary, and contains synchronization regions mrked up to draw content from the other, secondary flow or flows; this secondary content will be rendered alongside the main flow at the synchronization points.

A more general mechanism that supports parallel content from within the same flow is under preparation.

2.7.1 flow-map-dependency-reference

<fo:flow-map>
   <fo:flow-assignment>
      <fo:flow-source-list>
        <fo:flow-name-specifier
           flow-name-reference="Arabic-Flow"/>
      </fo:flow-source-list>
      <fo:flow-target-list>
         <fo:region-name-specifier
         region-name-reference="Region-Middle"/>
      </fo:flow-target-list>
   </fo:flow-assignment>
   <fo:flow-assignment flow-map-dependency-reference=”Arabic-Flow”>
      <fo:flow-source-list>
         <fo:flow-name-specifier
            flow-name-reference="Armenian-Flow"/>
      </fo:flow-source-list>
      <fo:flow-target-list>
         <fo:region-name-specifier
           region-name-reference="Region-Right"/>
      </fo:flow-target-list>
   </fo:flow-assignment>
   <fo:flow-assignment flow-map-dependency-reference="Arabic-Flow">
      <fo:flow-source-list>
         <fo:flow-name-specifier
          flow-name-reference="Syriac-Flow"/>
      </fo:flow-source-list>
   <fo:flow-target-list>
      <fo:region-name-specifier
        region-name-reference="Region-Left"/>
   </fo:flow-target-list>
 </fo:flow-assignment>
 </fo:flow-map>

Example: Modified Flow-Map to support flow types.

2.7.1.1 flow-map-dependency-reference

Value:	<number> \| <distance>
Initial:	none
Inherited:	no
Applies to:	fo:flow-assignment
Percentages:	N/A
Media:	all

The given name must exist as the flow-name attribute of a flow in the same flow-map; the property indicates that content in the named flow will be extracted and positioned alongside content in the flow being defined.

<name>: The name of a flow.

The name specified in the flow-map-dependency-reference attribute will normally not be referenced in a flow-source-list in the same flow-assignment, but this is not forbidden, and in that case some or all of the flow content will be duplicated.

2.7.2 Common Dependencies Properties for Formatting Objects

The dependency-content-begin dependency-content-end properties are used to identify spans of separate flows that are to be synchronized, in a manner similar to that used to mark change bars. These properties can be applied to any objects, including in particular fo:block and fo:inline; the indicated spans can start and end in different elements, and the two end-points of a span do not both have to be block or inline; the spans are treated as being asynchronous with respect to the formatting.

In the example in figure 29, taken from a parallel-text edition of a text for which there are manuscripts in three different languages, corresponding sections from each manuscript are formatted side by side, with the start of each on the same line, even if the section does not start at the beginning of the line.

Figure 29. Dependent Content on non-block boundaries.

The following markup might be used:

<fo:flow flow-name=”Arabic-Flow”>
   …
   <fo:block dependency-content-begin=”Key_A”>
       And Nadan went to Haiqâr, and said to him, 
       ‘W’allah, O my uncle! The king verily 
       rejoiceth in thee for having done what he 
       commanded thee.
   </fo:block>
   <fo:block>
       And now he hath sent me to thee that thou 
       mayst dismiss the soldiers to their duties 
       and come thyself to him with thy handsbound 
       behind thee, and thy feet chained, that the 
       ambassadors of Pharaoh may see this, and 
       that the king may be feared by them and by 
       their king’.
   </fo:block> 
   <fo:block>
       And Nadan took him and went with him to the 
       king.
   </fo:block>
   <fo:block dependency-content-end=”Key_A”>
       Then answered Haiqâr and said, ‘To hear is 
       to obey.’
   </fo:block>
   …
 </fo:flow>

Example 4: dependency-content-start and -end properties

2.7.2.1 dependency-content-start

Value:	<name>
Initial:	none
Inherited:	no
Applies to:	All fo flow elements
Percentages:	N/A
Media:	all

An arbitrary identifer used to correlate content placed in separate flows. It allows references to this formatting object by other objects.

<name>

For the purpose of parallel formatting in the block direction, the start of the generated area is used as the alignment point. If there is no generated area, the point at which the element with this property occurred within its container is used.

There must be a corresponding dependency-content-end later in the same flow (that is, later in XML document order).

The dependency-content-start is set on an element to mark the start of a region in one flow to be synchronized with a similarly-named region in another flow.

2.7.2.2 dependency-content-end

Value:	<name>
Initial:	none
Inherited:	no
Applies to:	All fo flow elements
Percentages:	N/A
Media:	all

An arbitrary identifer used to correlate content placed in separate flows. It allows references to this formatting object by other objects.

<name>

For the purpose of parallel formatting in the block direction, the end of the generated area is used as the alignment point. If there is no generated area, the point at which the element with this property occurred within its container is used.

The given name must match value of a dependency-content-start earlier in the same flow (that is, earlier in XML document order).

The dependency-content-start is set on an element to mark the end of a region in one flow that is to be synchronized with a similarly-named region in another flow.

2.7.2.3 Content Boundaries Stacking Control

Once the synchronized content has been composed in the non-synchronized and synchronized flows; the flow composition in the non-synchronized flow is resumed until new synchronization content is identified.

2.7.2.4 dependency-content-stacking-strategy

Value:	none \| non-dependent \| dependent \| all
Initial:	none
Inherited:	no
Applies to:	All fo flow elements
Percentages:	N/A
Media:	all

The dependency-content-stacking-strategy property controls how content in a flow is treated when it is between to regions that are synchronized.

The following example shows the the keep-with-dependent-content property used together with synchronized flow content:

none: None of the content can be stacked.
non-dependent: Only the content that does not generate dependency boundaries can be stacked.
Figure 30. dependency-content-stacking-strategy="non-dependent"
dependent: Only the content that generates dependency boundaries can be stacked.
Figure 31. dependency-content-stacking-strategy="dependent"
all: all the content can be stacked.
Figure 32. dependency-content-stacking-strategy="all"

2.7.3 Widow and Orphan Management

Synchronization of flows is generally implemented in a formatter by leaving space between blocks, as can be seen in the left and right columns in Figure 29. Widow and Orphan management is a mechanism for specifying how content between synchronized spans should be treated: it can be kept with a block or moved to the start of the next synchronized spam, or the synchronization gap can be suppressed entirely. If the gap is suppressed, the alignmnent of synchronized spans may not be correct, or the formatter may use other copyfitting techniques to achieve alignment.

Figure 33. illustrates the case where widows and orphans are generated.

Figure 33. Dependent Content: Formation of Widows and Orphans.

<fo:block keep-with-dependent-content=”widows” 
          dependent-content-begin=”Key_A”>
    Text text text …
   <fo:inline dependent-content-end=”Key_A”>
       Text text … 
   </fo:inline>
    Text text text …
 </fo:block>
 <fo:block keep-with-dependent-content=”all”>
     Text text text …
     <fo:block dependent-content-begin=”Key_B”>
         Text text … 
     </fo:inline>
     Text text text …
 </fo:block>

Using this example as the document structure equivalent for the schematic representation in Figure 33, the result of applying the keeps is illustrated in Figure 34.

Figure 34. Dependent Content: Widow and Orphan Management Using Keep.

2.7.3.1 keep-with-dependent-content

The keep-with-dependent-content determines how inline content is treated at the boundaries of synchronized spans of flow.

Value:	none \| all \| widows \| orphans
Initial:	none
Inherited:	yes
Applies to:	All fo flow elements
Percentages:	N/A
Media:	all

none: No keep is applied, and the non dependent content is forced to be moved outside the dependency boundaries.
all: Forces all the non dependent content to be included in the dependency boundaries.
widows: Forces all the generated widows to be included in the dependency boundaries.
orphans: Forces all the generated orphans to be included in the dependency boundaries.

2.8 Numbering

See the XSL-FO 2.0 Requirements Document, section 2.2.7

Add support for line number, column number and region number. For example number only every fifth line, etc.

2.8.1 fo:number

fo:number creates a number sequence to be processed by the XSL-FO processor and generate a list of sequences in varies of area in the XSL-FO area tree.

The following properties apply to this formatting object:

Empty.

name = [ string ]

number-area-extend = width

level = "line" | "footnote" | "column" | "none"

reset-level = [ "block" | "block-container" | "column" | "page" ]

initial-value = [ expression ]

interval = [ expression ]

reset-value = [ expression ]

display-when = [ expression ]

display-position = [ "start" | "end" | "before" | "after" ]

number-align = [ "start" | "end" | "center" | "decimal" ]

text-decoration = [ "none" | "underline" | "no-underline" | "overline" | "no-overline" | "line-through" | "no-line-through" | "blink" | "no-blink" || "inherit" ]

font-family = [ string ]

font-size = [ absolute-size | relative-size | length | percentage | "inherit" ]

font-style = [ "normal" | "italic" | "oblique" | "backslant" | "inherit" ]

font-weight = [ "normal" | "bold" | "bolder" | "lighter" | "100" | "200" | "300" | "400" | "500" | "600" | "700" | "800" | "900" | "inherit" ]

color = [ color ]

background-color = [ color ]

format = [ string ]

decimal-format = [ string ]

letter-value = [ "alphabetic" | "traditional" | <implementater extension> ]

ordinal = [ string ]

country = [ "none" | country | "inherit" ]

language = [ "none" | language | "inherit" ]

grouping-separator = [ char ]

grouping-size = [ number ]

2.8.2 name

The name identifies an fo:number object for use with level="none" or cross-references.

Required:	yes for level=”none”, no for all other levels.
Type:	string
Default Value:	none

An fo:number without a name cannot be referenced. There’s no imperative state for an fo:number, i.e. it’s not a counter or an variable. Instead, it provides a reference and display properties for a number series.

2.8.3 level

The level determines whether an fo:number is to count lines, columns, footnotes or some other type of object.

Required:	Yes
Type:	Enumeration of string
Default Value:	none
Note:	the property indicates the position that the fo:number object applies to in a page-sequence. Single fo:number object doesn’t apply to multiple page-sequence.
Values:	line \| column \| footnote

Values for the property have the following meaning:

line

line numbering, the fo:number is set under the fo:page-sequence, indicating that in this page sequence every line is numbered.

column

column numbering, the fo:number is set under the fo:page-sequence, indicating that in this page sequence every column is numbered.

footnote

footnote numbering, the fo:number is set under the fo:page-sequence, indicating that in this page sequence every footnote is numbered.

none

expression based numbering, when this value is used, the "name" property needs to be set and we use fo:retrieve-number to retrieve the presentation of the number judged by the fo:number’s display properties. And, fo:retrieve-number use "value" property to provide an expression to evaluate a actually number value for this presentation. fo:retrieve-number is a inline object.

If fo:retrieve-number retrieves a fo:number whose level property is not set to be "none", the expression is not ignored.

2.8.4 reset-level

The reset-level determines the level that the fo:number’s internal state in FO processor needs to be reset to its reset-value.

Required:	No
Type:	enumeration of string
Default Value:	none
Value:	block \| block-container \| column \| page \| none

The reset-value is not necessarily the same as the initial-value.

Values for the property have the following meaning:

block: reset when a new fo:block starts; this applies to level=”line” only.
block-container: reset when a new fo:block-container start; this applies to level="line" only.
column: Reset when a new column starts; this applies to level=”line”, level=”paragraph”, and level=”footnote”
page: reset when a new page starts; this applies to level=”line”, level=”paragraph”, level=”column”, and level=”footnote”
none: not resetting

The default value of reset-level is none, i.e. not resetting.

2.8.5 initial-value

The initial-value provides an initial value for a fo:number object. Notice that it’s an expression, and reference could be across a page sequence boundary. For example, an fo:number level=”line” object in the second page sequence can set the initial value to be continued for the last page sequence.

Required:	No
Type:	Expression
Default Value:	1

2.8.6 interval

The interval property on an fo:number object determines the amount by which the number increses (or decreases) on each occurrence of the measured unit (lines, blocks, columns, and so forth).

Required:	No
Type:	Expression
Default Value:	1
Note:	this is an increment value for the number.

2.8.7 reset-value

The reset-value property gives the value (an expression) used for an fo:number series when a it is reset according to its reset-level.

Required:	No
Type:	Expression
Default Value:	initial-value if its set or 1 otherwise

2.8.8 display-when

The display-when display property is an expression: each number generated by the fo:number object is displayed only when the expression given for this property has a true or non-zero value.

Required:	No
Type:	Expression
Default:	true()

For a level=”line” object, “value() = 1 or (value() mod 5 = 0)” indicates the number will display every 5 lines and always for first line.

The default value of display-if is “true()”, i.e. always shows.

2.8.9 display-position

Values for the property have the following meaning:

Required:	No
Type:	Enumeration of string
Default Value:	start
Note:	this property indicates the position of the number. For example the object start, object end, object top, object bottom, extra
Value:	before \| after \| start \| end

before: before the body of the content flow
after: after the body of the content flow
start: left or right of the content flow according to the writing-direction
end: right or left of the content flow according to the writing-direction

The display-position property of an fo:number object determines where the generated areas will be placed.

2.8.10 number-align

Values for the property have the following meaning:

Required:	No
Type:	Enumeration of string
Default Value:	start
Note:	indicate the alignment of the displayed number.
Value:	start \| center \| end \| decimal

start: align the number to the start point based on the writing-direction.
center: align the number to the center of an area large enough to contain the lagest generated number.
end: align the number to the end point based on the writing-direction.
decimal: align the number to the decimal separator, if increment-by value is not an integer, or to end otherwise.

The number-align property of a fo:number object determines how numbers are aligned with respect to one another.

This property was called display-align in the internal editor's draft, but that property already exists in XSL-FO 1.x with a slightly different meaning.

2.8.11 number-area-extend

The number-area-extend property determines the size of the area to be extended towards the "area before", "area after", "area start" and "area end" to display the number.

Required:	Yes
Type:	Length
Default Value:	none
Reference:	[http://www.w3.org/Style/XSL/Group/FO/wiki/index.php?title=Talk:2.2.7_Numbering#Property:_display-position Property:display-position]

2.8.12 text-align

Note:	XSL-FO 1.1 Chapter [http://www.w3.org/TR/xsl/#text-align 7.16.9]

2.8.13 text-decoration

Note:	XSL-FO 1.1 Chapter [http://www.w3.org/TR/xsl/#text-decoration 7.17.4]

2.8.14 font-family

Note:	XSL-FO 1.1 Chapter [http://www.w3.org/TR/xsl/#font-family 7.9.2]

2.8.15 font-size

Note:	XSL-FO 1.1 Chapter [http://www.w3.org/TR/xsl/#font-size 7.9.4]

2.8.16 font-style

Note:	XSL-FO 1.1 Chapter [http://www.w3.org/TR/xsl/#font-style 7.9.4]

2.8.17 font-weight

Note:	XSL-FO 1.1 Chapter [http://www.w3.org/TR/xsl/#font-weight 7.9.9]

2.8.18 color

Note:	XSL-FO 1.1 Chapter [http://www.w3.org/TR/xsl/#color 7.18.1]

2.8.19 background-color

Note:	XSL-FO 1.1 Chapter [http://www.w3.org/TR/xsl/#background-color 7.8.1]

2.8.20 format

Required:	No
Type:	String
Default Value:	none
Note:	indicates the format picture of the number, XSLT 2.0 Chapter [http://www.w3.org/TR/xslt20/#convert 12.3]

2.8.21 decimal-format

The decimal-format property indicates the name of the fo:decimal-format element that defines the format of a decimal number: decimal values in the generated fo:number sequence eill be formatted using the properties from the named deciaml-format element.

Required:	No
Type:	String
Default Value:	none

2.8.22 letter-value

The letter-value property disambiguates between numbering sequences that use letters, such as Roman (i, ii, iii) and Alphabetic (i, j, k).

Required:	No
Type:	Enumeration of string value
Default Value:	none

In many languages there are two commonly used numbering sequences that use letters. One numbering sequence assigns numeric values to letters in alphabetic sequence, and the other assigns numeric values to each letter in some other manner traditional in that language. In English, these would correspond to the numbering sequences specified by the format tokens a and i. In some languages, the first member of each sequence is the same, and so the format token alone would be ambiguous. A value of alphabetic specifies the alphabetic sequence; a value of traditional specifies the other sequence. If the letter-value attribute is not specified, then it is implementation-dependent how any ambiguity is resolved.

2.8.23 ordinal

The ordinal property determined the ordinal format (1st, 2nd, 3rd, etc.) as described in XSLT 2.0.

Required:	No
Type:	string
Default Value:	none

The ordinal property, if given a value, indicates that fo:number should generate ordinal rather than cardinal numbers (for example, 1st, 2nd, 3rd, 4th and so on, for English) rather than ordinal numbers (1, 2, 3, 4...).

When ordinal is used with the format token w, the corresponding sequence (e.g. in English, first second third fourth ...) is generated. In some languages, ordinal numbers vary depending on the grammatical context: for example they may have different genders and may decline with the noun that they qualify. In such cases the value of the ordinal attribute may be used to indicate the variation of the ordinal number required. The way in which the variation is indicated will depend on the conventions of the language. For inflected languages that vary the ending of the word, the preferred approach is to indicate the required ending, preceded by a hyphen. For example, in German, appropriate values are -e, -er, -es and -en. It is implementation-defined what combinations of values of the format token, the language, and the ordinal attribute are supported. If ordinal numbering is not supported for the combination of the format token, the language, and the actual value of the ordinal attribute, the request is ignored and cardinal numbers are generated instead.

2.8.24 country

Required:	No
Type:	ISO 3166 country code in string
Default Value:	inherited
Note:	XSL-FO 1.1 Chapter [http://www.w3.org/TR/xsl/#country 7.10.1]

2.8.25 language

Required:	No
Type:	ISO 639 or [http://www.loc.gov/standards/iso639-2/php/code_list.php\|ISO 639-2] language code in string
Default Value:	inherited
Note:	XSL-FO 1.1 Chapter [http://www.w3.org/TR/xsl/#language 7.10.2]

2.8.26 grouping-separator

Required:	No
Type:	character
Default Value:	none
Note:	the grouping separator for the number, same semantics as xsl:number.

2.8.27 grouping-size

Required:	No
Type:	number
Default Value:	none
Note:	the grouping size for the number, same semantics as xsl:number.

2.8.28 Arbitrary Object Numbering

We have received requirement about adding numbering support for paragraphs and other arbitrary elements in the XSL formatting objects, for example fo:inline for Bible verses, fo:instream-foreign-object for figures and illustrations in the book. Here is our current proposal towards the solution that is still under consideration and we'd like to hear public's feedback on the proposal.

The idea is to add attribute "number-ref-id" in any formatting object that needs to count the occurences. For example if we defined two fo:number objects as following:

<!-- the level needs to be set as "none" -->
<fo:number name="p1" level="none"/>
<fo:number name="f1" level="none"/>

Then we can set every fo:block that marks a new paragraph as this:

<fo:block number-ref-id="p1">Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<fo:block>

<fo:block>Ut wisi enim ad minim veniam, 
quis nostrud exerci tation
<fo:instream-foreign-object number-ref-id="f1">...</fo:instreaem-foreign-object>
ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</fo:block>

<fo:block number-ref-id="p1">Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.</fo:block>

<fo:block>Duis autem vel eum iriure dolor in hendrerit in vulputate 
velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis 
at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit</fo:block>

<fo:block>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
<fo:instream-foreign-object number-ref-id="f1">...</fo:instreaem-foreign-object>
sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.</fo:block>

<fo:block number-ref-id="p1">Ut wisi enim ad minim veniam, quis nostrud exerci tation 
ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</fo:block>

<fo:block number-ref-id="p1">Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.</fo:block>

<fo:block>In above <fo:retrieve-number name="f1"/> in <fo:retrieve-number name="p1"> paragraphs,
we demonstrated the new attribute
&quot;number-ref-id&quot;</fo:block>

Notice that, in above example, the attribute "number-ref-id" is added to only four different fo:block object, which means we marked FOUR distinguish paragraphs, instead of SEVEN according to the number of all the fo:block object in total.

The definition of attribute "number-pref-id" is as following:

2.8.28.1 format

The value indicates the name of an fo:number object that applies to current formatting object.

Required:	No
Type:	List of String
Default Value:	none
Applies To:	fo:block, fo:inline, fo:instream-foreign-object, fo:table-row, and fo:table-cell

If a non-leveled fo:number is used, the layout properties for the fo:number will be ignored. I.e. user needs to use fo:retrieve-number to retrieve the current value of fo:number.

2.9 fo:retrieve-number

fo:retrieve-number retrieves the current value of a fo:number sequence correspondent to the context where the fo:retrieve-number locates. By default the output number format is the format set by the original fo:number properties. Or fo:retrive-number can use its own properties to override the original fo:number's property setting.

<fo:retrieve-number
  name = string
  value = [ expression ]
  format = [ string ]
  decimal-format = [ QName ]
  letter-value = [ "alphabetic" | "traditional" | <implementater extension> ]
  ordinal = [ string ]
  country = [ "none" | country | "inherit" ]
  language = [ "none" | language | "inherit" ]
  grouping-separator = [ char ]
  grouping-size = [ number ]
/>

2.9.1 name

The name property identifies the name of the fo:number to which the fo:retrieve-number is referring.

Required:	Yes
Type:	character
Default Value:	none

2.9.2 value

The value property is an expression that can be used to generate an actual displayed value based on the retrieved value.

Required:	No
Type:	Expression
Default Value:	value()

if (value() - current-page-number() > 1) string(concat('Page ', value())
else if (value() - current-page-number() = 1) 'next page'
else if (value() = current-page-number()) 'later this page'

Can we generalize the fo:retrieve-number to be fo:retrieve-value or fo:value-of?

2.9.3 Other Properties

Please refer to other properties in the fo:number section

2.10 fo:decimal-format

fo:decimal-format defines a decimal format that could be used by either fo:number or fo:retrieve-number.

<fo:decimal-format
  name = [ string ]
  decimal-separator = [ char ]
  grouping-separator = [ char ]
  infinity = [ string ]
  minus-sign = [ char ]
  NaN = [ string ]
  percent = [ char ]
  per-mille = [ char ]
  zero-digit = [ char ]
  digit = [ char ]
  pattern-separator = [ char ]
/>

The name property contains the name of the fo:decimal-format to be referred by fo:number or fo:retrieve-number. If this property is not specified, it defines the default decimal format for the XSL-FO document in the the scope containing the fo:decimal-format.

The fo:decimal-format property is the same as xsl:decimal-format; please refer to XSLT 2.0 chapter [http://www.w3.org/TR/xslt20/#defining-decimal-format 16.4.1] for detailed syntax and symantics.

This section will be moving from XSLT 2 to the shared Functions and Operators document for the next revision of XSLT; at that time, this sectin is to be revised accordingly.

2.11 Examples

  <fo:page-sequence master-reference="Letter8">

  <fo:number
    number-area-extend="72pt"
    level="line"
    initial-value="1"
    reset-value="1"
    display-when="(value()=1) or (value() mod 5 = 0)"
    number-align="start"
    text-align="center"
    text-decoration="none"
    font-family="Arial"
    font-style="normal"
    font-size="12pt"
    font-weight="normal"
    color="black"
    background-color="white"
    />
    <fo:flow flow-name="xsl-region-body">

    <fo:block>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
    sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<fo:block>

    <fo:block>Ut wisi enim ad minim veniam, quis nostrud exerci tation 
    ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</fo:block>

    <fo:block>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
    sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.</fo:block>

    <fo:block>Duis autem vel eum iriure dolor in hendrerit in vulputate 
    velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis 
    at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit</fo:block>

    <fo:block>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
    sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.</fo:block>

    <fo:block>Ut wisi enim ad minim veniam, quis nostrud exerci tation 
    ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</fo:block>

    <fo:block>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
    sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.</fo:block

    <fo:block>Duis autem vel eum iriure dolor in hendrerit in vulputate 
    velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis 
    at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril.</fo:block>

    <fo:block>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
    sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.</fo:block>

    <fo:block>Ut wisi enim ad minim veniam, quis nostrud exerci tation 
    ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</fo:block>

    <fo:block>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
    sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.</fo:block>

    <!-- flow continues -->

    </fo:flow>

    </fo:page-sequence>

3 Expressions

[not done yet]

4 Inheritance

[not done yet]

5 Composition

5.1 Improved font support

See the XSL-FO 2.0 Requirements Document, section 5.1.1

This may include SVG font capabilities, such as referring to an external font pointed to with a URI, or being able to define fonts like SVG fonts.

In preparation. The XSL-FO Subgroup wants to align with CSS, SVG and with the emerging consensus on Web fonts for downloadable font support, and to see what font properties will be available. A future draft of this document is likely to contain a more detailed section here.

5.2 Force line justification

See the XSL-FO 2.0 Requirements Document, section 5.2

Allow users to force line justification when the line length is within a certain range. For example, normally the last line of a paragraph would not be justified, but if the last line is longer than a certain threshold, justify it anyway.

5.2.1 last-line-minimum-deficit

The last-line-minimum-deficit property specifies a length (x) for the minimum line length deficit for the last line-area of a block-area. More precisely, it specifies a constraint on the last line-area child of the last block-area L generated and returned by the formatting object, such that the inline L is either equal to the available width (w) in the inline-dimension (as the term is used in the "justify" value of "text-align"), or is less than or equal to w minus x.

Value:	<length> \| <percentage> \| inherit
Initial:	0pt
Applies to:	fo:block
Inherited:	yes
Percentages:	refer to width of containing block
Media:	visual

Values for the property have the following meaning:

<length>: The minimum line length deficit is a fixed length.
<percentage>: The minimum line length deficit is a percentage of the containing block width.

The value must not be negative.

5.2.2 hyphenation-permitted-minimum-deficit

This property specifies a length (x) for the hyphenation margin for a block. More precisely, it specifies a limitation on the effect of a "hyphenate" value of "true"; hyphenation may be used in the line-breaking algorithm within a given line-area when otherwise the inline-dimension of the line area would be less than the available width in the inline-dimension by an amount greater than x.

Value:	<length> \| <percentage> \| inherit
Initial:	100%
Applies to:	all elements
Inherited:	yes
Percentages:	refer to width of containing block
Media:	visual

The value must not be negative.

<length>: The permitted minimum deficit is a fixed length.
<percentage>: The permitted minimum deficit is a percentage of the containing block width.

5.3 Alignment around breaks

See the XSL-FO 2.0 Requirements Document, section 5.3

Add properties to specify what the alignment should be for the 'last line before a break' and the 'first line after a break'.

5.3.1 text-align-before-break

This property describes how inline content of the last line before a break is aligned.

Value:	relative \| start \| center \| end \| justify \| inside \| outside \| left \| right \| inherit
Initial:	relative
Applies to:	all elements
Inherited:	yes
Percentages:	N/A
Media:	visual

Values have the same meanings as in the definition of "text-align-last".

5.3.2 text-align-after-break

This property describes how inline content of the first line after a break is aligned. Values have the same meanings as in the definition of "text-align-last".

Value:	relative \| start \| center \| end \| justify \| inside \| outside \| left \| right \| inherit
Initial:	relative
Applies to:	all elements
Inherited:	yes
Percentages:	N/A
Media:	visual

5.4 hanging-punctuation

See the XSL-FO 2.0 Requirements Document, section 5.4

Add support for hanging punctuation, both for western [and] non-western languages.

XSL Definition:

Value:	none \| <list of characters>
Initial:	none
Applies to:	all elements
Inherited:	yes
Percentages:	N/A
Media:	visual

This property describes which characters are allowed to hang outside the margins.

Note:

This should refer to a "list of characters" datatype, which we have not yet defined.

5.5 Tabs and tab stops

See the XSL-FO 2.0 Requirements Document, section 5.4

Add support for tabs and tab stops that people are used to from word processors. The main requirement for this seems to be compatibility with other formats, mainly word processor formats.

5.5.1 tab-stops

This property specifies a sequence of tab stop locations relative to the content-rectangle of the closest ancestor reference-area.

Value:	list of pairs of { left \| right \| center \| decimal } and <length>
Initial:	empty list
Applies to:	all elements
Inherited:	yes
Percentages:	refer to width of nearest ancestor reference-area
Media:	visual

Need to specify overflow and interaction between wide content and tab stops.

How to invoke tab stops? fo:inline with start-tab and end-tab properties, or a new empty element marker? or a tab-character property?

Each symbol, length pair in the list has the following meaning:

left <length>: A left tab stop is set at the given location.
right <length>: A right tab stop is set at the given location.
center <length>: A center tab stop is set at the given location.
decimal <length>: A decimal tab stop is set at the given location. The character value to be aligned is specified by the tab-alignment-character property.

The lengths must not be negative.

Decimal/character alignment needs to be the same as proposed for tables.

At this stage of work, we are using the terms left and right rather than start and end.

5.5.2 tab-alignment-character

This property specifies the character used for alignment for a decimal tab.

Value:	<character>
Initial:	. (period character)
Applies to:	all elements
Inherited:	yes
Percentages:	N/A
Media:	visual

5.6 Word and letter spacing

5.6.1 word-spacing-critical-length

See the XSL-FO 2.0 Requirements Document, section 5.6.3

Allow users to specify the priority between word and letter spacing.

XSL Definition:

Value:	<length>
Initial:	0pt
Applies to:	all elements
Inherited:	yes
Percentages:	N/A
Media:	visual

This property specifies a length (x) for the word spacing to allow before invoking letterspacing. More precisely, it specifies a limitation on the effect of a "letterspacing" value; letterspacing may be used in the line-breaking algorithm within a given line-area when otherwise the word-spacing value would be greater than x.

Values have the following meanings:

<length>: The permitted minimum deficit is a fixed length.

The value must not be negative.

5.7 Hyphenation and line breaking

5.7.1 hyphenation-push-syllable-count

See the XSL-FO 2.0 Requirements Document, section 5.7.1

Allow specifying the number of syllables in addition to the number of characters to control hyphenation.

XSL Definition:

Value:	<number>
Initial:	1
Applies to:	all elements
Inherited:	yes
Percentages:	N/A
Media:	visual

The "hyphenation-push-syllable-count" property specifies the minimum number of syllables permitted in a hyphenated word after the hyphenation character. Formatters must not insert hyphens during line breaking in places that would result in word fragments violating this proerty.

Values have the following meanings:

<number>: A positive integer. If a non-positive or non-integer value is provided, the value will be rounded to the nearest integer value greater than or equal to 1.

5.7.2 hyphenation-remain-syllable-count

The hyphenation-remain-syllable-count specifies the minimum number of syllables in a hyphenated word before the hyphenation character. This is the minimum number of syllables in the word left on the line ending with the hyphenation character.

Value:	<number>
Initial:	1
Applies to:	all elements
Inherited:	yes
Percentages:	N/A
Media:	visual

<number>: A positive integer. If a non-positive or non-integer value is provided, the value will be rounded to the nearest integer value greater than or equal to 1.

5.7.3 syllable-widows

See the XSL-FO 2.0 Requirements Document, section 5.7.2

Add syllable level widow and orphan controls

XSL Definition:

Value:	<number>
Initial:	1
Applies to:	all elements
Inherited:	yes
Percentages:	N/A
Media:	visual

The "syllable-widows" property specifies the minimum number of syllables in the last line-area of a block-area.

Values have the following meanings:

<number>

A positive integer. If a non-positive or non-integer value is provided, the value will be rounded to the nearest integer value greater than or equal to 1.

The syllable-widows specifies the minimum number of syllables in the last line-area of the block-area for which it is in effect.

5.7.4 hyphenation-exceptions

See the XSL-FO 2.0 Requirements Document, section 5.7.3

Allow users to specify language-specific hyphenation exceptions.

XSL Definition:

Value:	<uri-specification> \| none \| inherit
Initial:	none
Applies to:	all elements
Inherited:	no
Percentages:	N/A
Media:	visual

This property specifies a set of hyphenation-exception words to be used by the hyphenation algorithm.

Values for this property are as follows:

none: No exceptions are used.
<uri-specification>: A URI specification giving a reference to the resource containing the exception words.

Note:

We have not defined a format for this resource.

5.7.5 word-widows

See the XSL-FO 2.0 Requirements Document, section 5.7.5

Add word level widow and orphan control.

XSL Definition:

Value:	<number>
Initial:	0
Applies to:	all elements
Inherited:	yes
Percentages:	N/A
Media:	visual

The "word-widows" property specifies the minimum number of words or partial words in the last line-area of a block-area.

When a word is hyphenated, the remaining portion, a partial word, brought down onto the next line, is to be considered to be a whole word for the purpose of counting words.

Values have the following meanings:

<number>: A positive integer. If a non-positive or non-integer value is provided, the value will be rounded to the nearest integer value greater than or equal to 1.
<percentage>: The permitted minimum deficit is a percentage of the containing block width.

The "word-widows" property specifies the minimum number of words in the last line-area of the block-area for which it is in effect.

5.7.6 min-length-of-last-line

See the XSL-FO 2.0 Requirements Document, section 5.7.6

Be able to specify the minimum length of the last line.

XSL Definition:

Value:	<length>
Initial:	1
Applies to:	all elements
Inherited:	yes
Percentages:	refer to width of containing block
Media:	visual

The min-length-of-last-line property specifies the minimum inline-dimension of the the last line-area in a block-area.

Values have the following meanings:

<length>: Specifies a fixed minimum line length.
<percentage>: The minimum line length is a percentage of the containing block width.

The value must not be negative

6 Further improved non-Western language support

See the XSL-FO 2.0 Requirements Document, section 6

Improve support for non-Western languages, such as Mongolian, Indic languages, Thai, Japanese, Chinese, etc. The working group invites language experts to identify language specific features that are currently not yet supported by XSL.

Specifically, the Japanese Layout Taskforce has published a document about requirements for general Japanese layout realized with This draft, then, technologies like CSS, SVG and XSL-FO [Requirements for Japanese Text Layout]. This document is being used as an input to the XSL Working Group as a source of requirements, and is currently being discussed within the Group.

6.1 Ruby

Ruby is a small-sized, supplementary text attached to a character or a group of characters in the main text. This section is generally written for Japanese text, although ruby can also be used with other languages and writing systems.

In Japanese, then, a run of ruby text, usually attached to the right of the characters in vertical writing mode or immediately above them in horizontal writing mode, indicates the reading or the meaning of those characters. The characters in the main text that are annotated by ruby are called "base characters". Kana characters are often used for ruby to indicate how to read kanji characters; this is known as ruby annotation or as "furigana".

see http://www.w3.org/TR/jlreq/#en-subheading2_3_1

6.1.1 Ruby and Areas

Modify Section 4.2.1, Area Types (http://www.w3.org/TR/xsl11/#d0e723) to define annotation-area.

An annotation-area is for ruby and emphasis dots.

Modify Section 4.7.2, Line-building (http://www.w3.org/TR/xsl11/#area-linebuild) to include annotation-areas.

Modify Section 4.7.3, Inline-building (http://www.w3.org/TR/xsl11/#area-inlinebuild) to include annotation-areas.

6.1.2 Ruby Formatting Objects

6.1.2.1 fo:ruby

Common usage:

The fo:ruby formatting object is used to contain a string of text that has ruby annotations.

The fo:ruby formatting object generates one or more normal inline-area areas. The fo:ruby returns these areas, together with any page-level-out-of-line areas, and reference-level-out-of-line areas returned by the children of the fo:ruby.

No area may have more than one normal child area returned by the same fo:ruby formatting object.

The children of each normal area returned by an fo:ruby must satisfy the constraints specified in 4.7.3 Inline-building.

In addition the constraints imposed by the traits derived from the properties applicable to this formatting object must be satisfied. The geometric constraints are rigorously defined in 4 Area Model.

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

((fo:ruby-base, (fo:ruby-text |
(fo:ruby-parenthesis, fo:ruby-text, fo:ruby-parenthesis)) |
(fo:ruby-base-container, fo:ruby-text-container, fo:ruby-text-container?))

The following properties apply to this formatting object:

7.5 Common Accessibility Properties

7.7 Common Aural Properties

7.8 Common Border, Padding, and Background Properties

7.9 Common Font Properties

7.12 Common Margin Properties-Inline

7.13 Common Relative Position Properties

7.14.1 alignment-adjust

7.14.2 alignment-baseline

7.14.3 baseline-shift

7.15.3 block-dimension

7.18.1 color

7.14.5 dominant-baseline

7.15.7 inline-dimension

7.20.3 keep-together

7.20.4 keep-with-next

7.20.5 keep-with-previous

7.16.4 line-height

7.17.4 text-decoration

6.1.2.2 fo:ruby-base

The fo:ruby-base formatting object is used to contain a string of text that has ruby annotations.

The fo:ruby-base formatting object generates and returns one or more normal inline-areas.

No area may have more than one normal child area returned by the same fo:ruby-base formatting object.

The children of the normal area returned by an fo:ruby-base must satisfy the constraints specified in 4.7.3 Inline-building.

The following properties apply to this formatting object:

(#PCDATA|%inline;)*

7.7 Common Aural Properties
7.9 Common Font Properties
7.13 Common Relative Position Properties
7.18.1 color
7.30.8 id
7.24.1 index-class
7.24.2 index-key
7.17.2 letter-spacing
7.16.4 line-height
7.30.15 score-spaces
7.17.8 word-spacing

6.1.2.3 fo:ruby-text

The fo:ruby-text formatting object is used to contain a string of text that is a ruby annotation.

The fo:ruby-text formatting object generates one normal annotation-area. The fo:ruby-text returns this area.

No area may have more than one normal child area returned by the same fo:ruby-text formatting object.

The children of each normal area returned by an fo:ruby-text must satisfy the constraints specified in 4.7.3 Inline-building.

In addition the constraints imposed by the traits derived from the properties applicable to this formatting object must be satisfied. The geometric constraints are rigorously defined in 4 Area Model.

The following properties apply to this formatting object:

#PCDATA

7.9 Common Font Properties
7.18.1 color
7.17.2 letter-spacing
7.30.15 score-spaces
7.17.4 text-decoration
7.17.5 text-shadow
7.17.6 text-transform
7.17.8 word-spacing
ruby-size
ruby-proportion

6.1.2.4 fo:ruby-parenthesis

The fo:ruby-parenthesis formatting object is used to contain a string of text that is used to denote the beginning or end of ruby text when user agents do not have other ways to present ruby text distinctively from the base text. Parentheses (or similar characters) can provide an acceptable fallback. In this situation, ruby text will only degrade to be rendered inline and enclosed in the fallback parentheses. This is the least inappropriate rendering under the condition that only inline rendering is available. The fo:ruby-parenthesis formatting object cannot be used with complex ruby formatting objects.

When generating annotation areas for ruby is not possible, the fo:ruby-parenthesis formatting object generates one or more normal inline-areas. The fo:ruby-parenthesis returns these area.

No area may have more than one normal child area returned by the same fo:ruby-parenthesis formatting object.

The children of each normal area returned by an fo:ruby-parenthesis must satisfy the constraints specified in 4.7.3 Inline-building.

In addition the constraints imposed by the traits derived from the properties applicable to this formatting object must be satisfied. The geometric constraints are rigorously defined in 4 Area Model.

The following properties apply to this formatting object:

(#PCDATA)

7.9 Common Font Properties
7.18.1 color
7.17.2 letter-spacing
7.30.15 score-spaces
7.17.4 text-decoration
7.17.5 text-shadow
7.17.6 text-transform
7.17.8 word-spacing
ruby-size
ruby-proportion

6.1.2.5 fo:ruby-base-container-text

The fo:ruby-base formatting object is used to contain one or more strings of text that have ruby annotations.

The fo:ruby-base-container formatting object does not generate any areas. The fo:ruby-base-container formatting object returns the sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:ruby-base-container.

No area may have more than one normal child area returned by the same fo:ruby-base-container formatting object.

The children of each normal area returned by an fo:ruby must satisfy the constraints specified in 4.7.3 Inline-building.

(fo:ruby-base)+

6.1.2.6 fo:ruby-text-container

The fo:ruby-text-container formatting object is used to contain one or more strings of text that are ruby annotations.

The fo:ruby-text-container formatting object does not generate any areas. The fo:ruby-text-container formatting object returns the sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:ruby-text-container.

No area may have more than one normal child area returned by the same fo:ruby-text formatting object.

The children of each normal area returned by an fo:ruby-text must satisfy the constraints specified in 4.7.3 Inline-building.

In addition the constraints imposed by the traits derived from the properties applicable to this formatting object must be satisfied. The geometric constraints are rigorously defined in 4 Area Model.

The following properties apply to this formatting object:

(fo:ruby-text)+

7.9 Common Font Properties
7.18.1 color
7.17.2 letter-spacing
7.30.15 score-spaces
7.17.4 text-decoration
7.17.5 text-shadow
7.17.6 text-transform
7.17.8 word-spacing
ruby-overhang
ruby-position

6.1.3 Ruby Properties

6.1.3.1 ruby-position

Based on http://www.w3.org/TR/2003/CR-css3-ruby-20030514/#rubypos

Value:	auto \| before \| bopomofo \| inline \| inherit
Initial:	auto
Inherited:	yes
Percentages:	N/A
Media:	visual

This property specifies the position of ruby annotations with respect to their corresponding base glyphs.

Same as before for fo:ruby-text and the first fo:ruby-text-container, and same as after for the second fo:ruby-text-container. This is the initial value.

before

The ruby text appears before the base. This is the most common setting used in ideographic East Asian writing systems.

Figure 35. ruby-position="before" in lr writing-mode applied to Japanese text

When writing-mode is tb-rl, the ruby appears on the right side of the base and is rendered in the same layout mode as the base.

small ruby text to the right of normal-size ruby base characters

Figure 36. ruby-position="before" in tb-rl writing-mode layout applied to Japanese text

after

The ruby text appears after the base. This is a relatively rare setting used in ideographic East Asian writing systems, most often found in educational text.

small ruby text beneath normal-size ruby base characters

Figure 37. ruby-position="after" in lr writing-mode applied to Japanese text

If the base appears in a tb-rl writing-mode, the bottom ruby appears on the left side of the base and is rendered in the same layout mode as the base (i.e. vertical)

small ruby text to the left of normal-size ruby base characters

Figure 38. ruby-position="after" in tb-rl writing-mode applied to Japanese text

bopomofo

The ruby text appears on the right of the base. Unlike 'before' and 'after', this value is not relative to the inline-direction.

This value is provided for the special case of traditional Chinese as used especially in Taiwan: ruby (made of bopomofo glyphs) in that context appears vertically along the right side of the base glyph, whether the layout of the base characters is vertical or horizontal.

small bopomofo ruby characters arranged vertically to the rihtof larger Chinese characters

Figure 39. "Bopomofo" ruby in traditional Chinese (ruby text shown in blue for clarity) in horizontal layout

The bopomofo transcription is written in the normal way as part of the ruby text. The user agent is responsible for ensuring the correct relative alignment and positioning of the glyphs, including those corresponding to the tone marks, when displaying. Tone marks are spacing characters that are present at the end of the ruby text for each base character. They are usually displayed in a separate column to the right of the bopomofo characters, and the height of the tone mark depends on the number of characters in the syllable. One tone mark, however, is placed above the bopomofo, not to the right of it.

To make bopomofo annotations appear before or after the base text, like annotations for most other East Asian writing systems, use the "before" and "after" values of ruby-position.

Handling of ruby text that is not bopomofo when the value of ruby-position is set to "bopomofo" is not defined by this specification.

inline

Ruby text follows the ruby base with no special styling. The value can be used to disable ruby text positioning.

If the author has used the XHTML rp element [RUBY] they should set the display value for that element to inline, so that the ruby text is distinguishable from the base text. If no rp element has been used, the author can use the content property with the :before and :after pseudo-elements to set off the ruby text.

6.1.3.2 ruby-alignment

Based on http://www.w3.org/TR/2003/CR-css3-ruby-20030514/#rubyalign

This property specifies alignment of a ruby annotation with respect to its base text.

Value:	auto \| start \| center \| end \| inherit
Initial:	auto
Inherited:	yes
Percentages:	N/A
Media:	visual

Based on http://www.w3.org/TR/2003/CR-css3-ruby-20030514/#rubyalign

auto: The user agent determines how the ruby contents are aligned. This is the initial value.
start: The ruby text content is aligned with the start edge of the base.
Figure 40. Glyph layout in left aligned ruby when ruby text is shorter than base.
Figure 41. Glyph layout in left aligned ruby when ruby text is longer than base.
center: The ruby text content is centered within the width of the base. If the length of the base is smaller than the length of the ruby text, then the base is centered within the width of the ruby text.
Figure 42. Glyph layout in center aligned ruby when ruby text is shorter than base.
Figure 43. Glyph layout in center aligned ruby when ruby text is longer than base.
end: The ruby text content is aligned with the end edge of the base.
Figure 44. Glyph layout in right (end)-aligned ruby when ruby text is shorter than base.
Figure 45. Glyph layout in right (end)-aligned ruby when ruby text is longer than base.

6.1.3.3 ruby-group-distribution

This property specifies how the space between the ruby characters or the base characters (whichever is shortest) is distributed.

Value:	auto \| distribute-letter \| distribute-space \| inherit
Initial:	auto
Inherited:	yes
Percentages:	N/A
Media:	visual

distribute-letter: If the width of the ruby text is smaller than that of the base, then the ruby text contents are evenly distributed across the width of the base, with the first and last ruby text glyphs lining up with the corresponding first and last base glyphs. If the width of the ruby text is at least the width of the base, then the letters of the base are evenly distributed across the width of the ruby text.
Figure 46. Glyph layout in distribute-letter aligned ruby when ruby text is shorter than base
Figure 47. Glyph layout in distribute-letter aligned ruby when ruby text is longer than base.
distribute-space: If the width of the ruby text is smaller than that of the base, then the ruby text contents are evenly distributed across the width of the base, with a certain amount of white space preceding the first and following the last character in the ruby text. That amount of white space is normally equal to half the amount of inter-character space of the ruby text. If the width of the ruby text is at least the width of the base, then the same type of space distribution applies to the base. In other words, if the base is shorter than the ruby text, the base is distribute-space aligned. This type of alignment is sometimes referred to as the "1:2:1" alignment [JIS4051].
Figure 48. Glyph layout in distribute-space aligned ruby when ruby text is shorter than than its base.
Figure 49. Glyph layout in distribute-space aligned ruby when ruby text is longer (or wider) than than the corresponding base.

6.1.3.4 ruby-alignment-edge

Based on http://www.w3.org/TR/2003/CR-css3-ruby-20030514/#rubyalign

This property specifies what the formatter must do when ruby annotations occur at the start of end of lines.

Value:	auto \| normal \| line-edge \| inherit
Initial:	auto
Inherited:	yes
Percentages:	N/A
Media:	visual

Based on http://www.w3.org/TR/2003/CR-css3-ruby-20030514/#rubyalign

auto: The user agent determines how the ruby contents are aligned at the edges of lines. This is the initial value.
normal: When the line head starts with ruby annotated text where the ruby text length is longer than that of the base characters, compose the text so that the first ruby character which overhangs the base text is aligned with the line head, and vice versa.
Figure 50. Example of normal positioning of ruby characters at the line head and at the line end.
line-edge: If the ruby text is not adjacent to a line edge, it is aligned as in 'normal'. Where the ruby text length is longer than that of the base characters and it is adjacent to a line edge, then it is still aligned as in 'normal', but the side of the ruby text that touches the end of the line is lined up with the corresponding edge of the base. In the other scenarios, this is just 'normal'.
Figure 51. Example of line-edge positioning of ruby characters at the line head and at the line end.

6.1.3.5 ruby-align

This property is a shorthand for the "ruby-alignment", "ruby-group-distribution", and "ruby-alignment-edge" properties and maps.

Value:	auto \| start \| left \| center \| end \| right \| distribute-letter \| distribute-space \| line-edge \| inherit
Initial:	0
Applies to:	fo:inline
Inherited:	yes
Percentages:	refer to inherited font size
Media:	visual

ruby-alignment = "auto"
ruby-distribution = "auto"
ruby-alignment-edge = "auto"

start

ruby-alignment = "start"
ruby-distribution = "auto"
ruby-alignment-edge = "auto"

left

ruby-alignment = "start" or "end" depending on writing mode
ruby-distribution = "auto"
ruby-alignment-edge = "auto"

center

ruby-alignment = "center"
ruby-distribution = "auto"
ruby-alignment-edge = "auto"

end

ruby-alignment = "end"
ruby-distribution = "auto"
ruby-alignment-edge = "auto"

right

ruby-alignment = "end" or "start" depending on writing mode
ruby-distribution = "auto"
ruby-alignment-edge = "auto"

distribute-letter

ruby-alignment = "auto"
ruby-distribution = "distribute-letter"
ruby-alignment-edge = "auto"

distribute-space

ruby-alignment = "auto"
ruby-distribution = "distribute-space"
ruby-alignment-edge = "auto"

line-edge

ruby-alignment = "auto"
ruby-distribution = "auto"
ruby-alignment-edge = "line-edge"

inherit

ruby-alignment = "auto"
ruby-distribution = "auto"
ruby-alignment-edge = "auto"

6.1.3.6 ruby-overhang

This property specifies whether, and on which side, ruby text is allowed to partially overhang any adjacent text in addition to its own base, when the ruby text is wider than the ruby base.

Value:	auto \| start \| end \| none \| inherit
Initial:	none
Inherited:	yes
Percentages:	N/A
Media:	visual

Ruby text is never allowed to overhang glyphs belonging to another ruby base. Also the user agent is free to assume a maximum amount by which ruby text may overhang adjacent text. The user agent MAY use the JIS4051 [JIS4051] recommendation of using one ruby text character length as the maximum overhang length.

auto: The ruby text can overhang text adjacent to the base on either side. [JIS4051] specifies the categories of characters that ruby text can overhang. The user agent is free to follow the [JIS4051] recommendation or specify its own classes of characters to overhang. This is the initial value.
Figure 52. Glyph layout in overhanging ruby.
start: The ruby text can overhang the text that precedes it. That means, for example, that ruby can overhang text that is to the left of it in horizontal LTR layout, or it can overhang text that is above it in vertical-ideographic layout.
Figure 53. Diagram of glyph layout when ruby overhangs the preceding glyphs only
end: The ruby text can overhang the text that follows it. That means, for example, that ruby can overhang text that is to the right of it in horizontal LTR layout, or it can overhang text that is below it in vertical-ideographic layout.
Figure 54. Glyph layout when ruby overhangs the following glyphs only.
none: This is the default behavior.
Figure 55. Glyph layout in non-overhanging ruby.

6.1.3.7 ruby-overhang-length

This property specifies the maximum distance that ruby may overhang adjacent characters, when it is possible and necessary for the ruby to overhang.

Value:	<length> \| auto
Initial:	1em
Inherited:	yes
Percentages:	Font-size of ruby
Media:	visual

auto: The user agent determines the maximum overhang.
<length>: The maximum distance the ruby may overhang adjacent characters.

6.1.3.8 ruby-span

This property controls the spanning behavior of ruby annotation elements.

Value:	<number> \| none \| inherit
Initial:	none
Inherited:	no
Percentages:	N/A
Media:	visual

<number>: The number of ruby base elements to be spanned by the annotation element. If the <number> is ‘0’, it is replaced by ‘1’. The <number> is the computed value.
none: No spanning. The computed value is ‘1’

6.1.3.9 ruby-size

This property specifies the size of ruby text.

Value:	<number> \| inherit
Initial:	0.5
Inherited:	yes
Percentages:	font-size of base characters
Media:	visual

In Japanese layout, when ruby is attached to twelve point or larger base characters (usually used for headings), the size of the ruby letter is generally smaller than half the size of the base characters.

Examples of ruby at a size smaller than half the size of the base characters; the text is vertical, and, because the ruby is soamler than half-size, when there are two ruby characters per base character, there is space between the ruby characters.

Figure 56. Examples of ruby at a size smaller than half the size of the base characters.

<number>: The ratio of the size of ruby characters to base characters.

6.1.3.10 ruby-proportion

This property controls the aspect ratio of ruby text.

Value:	normal \| narrow \| inherit
Initial:	normal
Inherited:	yes
Percentages:	N/A
Media:	visual

normal: The ruby characters have normal proportions.
Figure 57. Examples of ruby with normal proportions.
narrow: The ruby characters are narrower in the inline-direction so that more ruby characters can fit alongside a base character.
Figure 58. Examples of ruby with narrow proportions.

6.1.3.11 ruby-mode

This property specifies whether adjacent fo:ruby-text can intrude on each other.

Value:	mono \| compound \| inherit
Initial:	mono
Inherited:	yes
Percentages:	N/A
Media:	visual

mono: Ruby characters do not intrude upon each other:
Figure 59. Example of mono-ruby method. Ruby letters are attached to each base kanji character in a compound word.
compound: Adjacent fo:ruby-text are treated as being part of one compound word and may intrude upon each other.
Figure 60. Example of jukugo-ruby method. Ruby letters are attached to groups of kanji characters in compound words.
yyy: yyy

6.1.4 Block and Line-related Properties

6.1.4.1 line-stacking-annotation

Value:	include-annotation \| exclude-annotation \| inherit
Initial:	exclude-annotation
Inherited:	yes
Percentages:	N/A
Media:	visual

This property determines the line stacking method for block elements containing annotation areas such as from ruby or emphasis dots. In all cases the areas returned by fo:ruby-base or fo:annotation-base (tbd) are considered for line stacking.

exclude-annotation: The annotation areas are ignored for line stacking.
include-annotation: The annotation areas are considered for line stacking.

7 Images

Open issue: 7570

Should there be a list of image formats that MUST be supported, e.g. PNG?

All XSL-Formatters must support the PNG image format for included input images.

7.1 Images

See the XSL-FO 2.0 Requirements Document, section 7.3

Allow rotating images over arbitrary angles.

7.1.1 Rotate an image by arbitrary amounts

XSL-FO can already do this for multiples of 90 degrees; other angles are awaiting completion of the shaped areas work in this document, because if you rotate a rectangle by an angle that is not a multiple of 90 degrees, you get a diamond, and this specification does not (yet) handle non-rectangular inline objects.

7.1.2 Callouts

See the XSL-FO 2.0 Requirements Document, section 7.4

Add support for callouts. Callouts are labels in a picture, overlaying text on top of a graphic (which typically needs to be translatable). Allow users to make live links from the image or map to the text and vice versa.

For callouts, e.g. adding captions to an image, with arrows pointing to the text, one approach that makes sense here is to use SVG, remembering that allowing fo:blocks inside the SVG may fall out of the work with SVG.

7.1.3 Multi-page images

See the XSL-FO 2.0 Requirements Document, section 7.5

Add support for access to individual images in multi-page image formats such as TIFF, PDF or SVG 1.2.

This may be a case of wanting a URI fragment identifier for a specific page of a PDF, or layer of TIFF; for SVG this is a liaison item. If a media type doesn't define a fragment type, we could add an extra property.

Open issue: 7571

What if you don't know in advance how many layers there are in advance in, say, a TIFF image, and want to print them all as pages?

8 Color Support

See the XSL-FO 2.0 Requirements Document, section 9.6

Improved color support including things that SVG Print does. For example add device-specific CMYK color. Add support for the color names that are supported in SVG. Fills/Shading/Vignettes.

A function is added to support calibrated CMYK colors:

color cmyk-ICC-color(r, g, b, NCName, cyan, magenta, yellow, black)

Two functions are added to support the direct specification of the cartesian and polar forms of the CIE L*ab color space:

color cie-lab-color(r, g, b, Lightness, a-value, b-value)
	  color cie-lchab-color(r, g, b, Lightness, chroma, hue)

A function is introduced to support named-icc-colors (e.g. Pantone™).

color rgb-named-color(r, g, b, NCName, namedColor)

Four new functions are added to support device-dependent (uncalibrated) color (e.g. calibration swatches, registration marks).

color gray-device-color (r,g,b, devGray)
	  color rgb-device-color (r,g,b, devR, devG, devB)
	  color cmyk-device-color (r,g,b, devC, devM, devY, devK)

A conformance class is introduced for implementations which correctly process color managed colors (i.e. do not rely on the fallback colors).

A conformance class is introduced for implementations which correctly process color managed images (i.e. apply, or pass through to a formatter, any embedded ICC profile).

9 Collaboration with SVG

See the XSL-FO 2.0 Requirements Document, section 10

For XSL-FO 2.0 we want to have a close collaboration between the XSL and SVG working groups. Wherever possible we will try to use SVG functionality rather than reinventing our own.

9.1 Masks

See the XSL-FO 2.0 Requirements Document, section 10.1

Add support for applying a mask (or clip shape) to an object.

Masks in SVG are only applied to viewports. It would be a good practice to do the same and apply it only to block-containers or regions. Masks are declared in the defs space in SVG and then referenced. This enables re-use and complex effects (e.g. Mask with Gradient and so on...)

The approach is to introduce an fo:mask object inside the fo:declarations that contains a valid SVG document providing the mask definition. An XSL-FO renderer can then use an SVG agent to compute the mask and then apply it to the FO rendering result.

<fo:root
	    xmlns:svg="http://www.w3.org/2000/svg"
	    xmlns:xlink="http://www.w3.org/1999/xlink">
	    <fo:declarations>
	    <fo:mask mask-name="myFOMask" content-type="image/svg"
	    content-reference-id="svg:mask[@id='svgMask']">
	    <svg:svg width="8cm" height="3cm" viewBox="0 0 800 300" version="1.1">
	    <svg:desc>Example mask01 - content masked with gradient against red background</svg:desc>
	    <svg:defs>
	    <svg:linearGradient id="Gradient" gradientUnits="userSpaceOnUse"
	    x1="0" y1="0" x2="800" y2="0">
	    <svg:stop offset="0" stop-color="white" stop-opacity="0" />
	    <svg:stop offset="1" stop-color="white" stop-opacity="1" />
	    </svg:linearGradient>
	    <svg:mask id="svgMask" maskUnits="userSpaceOnUse"
	    x="0" y="0" width="800" height="300">
	    <svg:rect x="0" y="0" width="800" height="300" fill="url(#Gradient)"  />
	    </svg:mask>
	    </svg:defs>
	    ...
	    </svg:svg>
	    </fo:mask>
	    </fo:declarations>
	    ...
	    <fo:block-container mask-reference-name="myFOMask">
	    ...
	    </fo:block-container>
	    ...
	    </fo:root>

9.2 Rotation and Transformations