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

11. Supplemental objects
[> 12.][< 10.6.2][^^^]
11.0 Specialty constructs
[> 11.1][> 12.][< 11.][^^][^^^]
The objects described here are not typically used very often but can provide useful functionality to those with specific formatting requirements in three areas:
[[1] - [F1.1]change bars
[[2] - lines associated with the flow typically used to indicate changed content
][1] - character-level processing outside of the default behaviors
[[2] - managing the bi-directionality inherent in the Unicode properties of characters
 [2] - instantiating formatting objects explicitly in the formatting object tree
][1] - constructs of a global nature
[[2] - specifying a color system recognized by an XSL-FO processor
 [2] - accommodating a home in the XSL-FO instance for color system specifications
]]
The XSL-FO objects covered in this chapter are:
[[1] - [F1.1]<[change-bar-begin]> ([6.13.2])
[[2] - indication of the starting of change bar rendering
][1] - [F1.1]<[change-bar-end]> ([6.13.3])
[[2] - indication of the completion of change bar rendering
][1] - <[color-profile]> ([6.4.4])
[[2] - the declaration of a profile of candidate color values from which color specifications can be made by formatting objects
][1] - <[declarations]> ([6.4.3])
[[2] - a global-scope repository of formatting object constructs for an XSL-FO instance
[[3] - the collection of available color profiles
 [3] - any collections of extended formatting objects supported by an XSL-FO processor
[[4] - must use a processor-recognized namespace URI other than the XSL-FO namespace URI
]]][1] - <[bidi-override]> ([6.6.2])
[[2] - specifies how to manage and override the inherent Unicode text direction for a sequence of characters
][1] - <[character]> ([6.6.3])
[[2] - both the abstract formatting object implied by a simple character in an XSL-FO instance and the concrete formatting object available to be used in place of a simple character
]]
11.1 Specialty vocabulary
[> 11.2][< 11.0][^^][^^^]
11.1.1 Change bars
[> 11.1.2][> 11.2][> 12.][< 11.0][^^][^^^]
[F1.1]Change bars visually indicate content of note to the reader
[[1] - perhaps the content indicated is different content from the content of a previous edition
 [1] - different appearances may be used to indicate the different natures of the content
 [1] - e.g. dashed, dotted and solid lines to the left and right of the content would indicate different aspects about the content
 [1] - [F1.1]<[change-bar-begin]/>
[[2] - the beginning of the named drawn line is aligned with the point in the flow at which this formatting object is used
 [2] - properties govern the style, width, color, offset and placement of the line
][1] - [F1.1]<[change-bar-end]/>
[[2] - the beginning of the named drawn line is aligned with the point in the flow at which this formatting object is used
][1] - [change-bar-class]= indicates the name of the line
]
Don't be prejudiced by the name of the construct
[[1] - the visual bars can be used for many purposes other than marking changes
 [1] - e.g. denoting sections pertaining to different responsible readers
 [1] - e.g. marking the presence of particular constructs such as definitions
 [1] - e.g. marking security levels of content
]
11.1.2 <change-bar-begin> Object
[> 11.1.3][> 11.2][> 12.][< 11.1.1][^][^^][^^^]
Purpose:
[[1] - mark the beginning of the named drawn line shown to indicate some specific nature of the content
]
Content:
[[1] - [F1.1]([6.13.2]) EMPTY
]
Property sets:
[[1] - [Common Accessibility Properties]([7.5];[Section D.1.2 Common Accessibility Properties])
 [1] - [Common Aural Properties]([7.7];[Section D.1.3 Common Aural Properties])
]
Other required property:
[F1.1][change-bar-class=]([7.30.1];[Section D.3.3 Property summary])
Other optional properties:
[F1.1][change-bar-color=]([7.30.2];[Section D.3.3 Property summary])
[F1.1][change-bar-offset=]([7.30.3];[Section D.3.3 Property summary])
[F1.1][change-bar-placement=]([7.30.4];[Section D.3.3 Property summary])
[F1.1][change-bar-style=]([7.30.5];[Section D.3.3 Property summary])
[F1.1][change-bar-width=]([7.30.6];[Section D.3.3 Property summary])
[z-index=]([7.30.18];[Section D.3.3 Property summary])
Property of interest:
[[1] - [change-bar-class]= must indicate a name for which there is a paired ending formatting object
]
11.1.3 <change-bar-end> Object
[> 11.1.4][> 11.2][> 12.][< 11.1.2][^][^^][^^^]
Purpose:
[[1] - mark the end of the named drawn line shown to indicate some specific nature of the content
]
Content:
[[1] - [F1.1]([6.13.3]) EMPTY
]
Property sets:
[[1] - [Common Accessibility Properties]([7.5];[Section D.1.2 Common Accessibility Properties])
 [1] - [Common Aural Properties]([7.7];[Section D.1.3 Common Aural Properties])
]
Other required property:
[F1.1][change-bar-class=]([7.30.1];[Section D.3.3 Property summary])
Property of interest:
[[1] - [change-bar-class]= must indicate a name for which there is a paired beginning formatting object
]
11.1.4 Color system specification
[> 11.1.5][> 11.2][> 12.][< 11.1.3][^][^^][^^^]
Alternative color specifications may be needed by rendering requirement
[[1] - <[color-profile]/>
 [1] - formalized color definition provides for alternatives to built-in color granularity
 [1] - the stylesheet writer is always obliged to provide an RGB fallback color to accommodate formatters that do not support the requested color profile
]
Constructs out of line of the pagination need a home in an XSL-FO instance
[[1] - <[declarations]>
 [1] - a home location is required in the XSL-FO instance for referenced constructs that do not exist in any flow or repeatable construct
 [1] - for XSL-FO vocabulary purposes
[[2] - e.g. <[color-profile]>
][1] - may also be used for extension and other future vocabulary purposes
]
11.1.5 <color-profile> Object
[> 11.1.6][> 11.2][> 12.][< 11.1.4][^][^^][^^^]
Purpose:
[[1] - the declaration of a profile of candidate color values from which color specifications can be made by formatting objects
]
Content:
[[1] - ([6.4.4]) EMPTY
 [1] - Referring object:
[[2] - <[declarations]>([6.4.3];[Section 11.1.6 <declarations> Object])
]]
Required properties:
[color-profile-name=]([7.18.2];[Section D.3.3 Property summary])
[src=]([7.30.16];[Section D.3.3 Property summary])
Optional property:
[rendering-intent=]([7.18.3];[Section D.3.3 Property summary])
Function of interest:
[[1] - [src]= is a URI recognized by the processor to represent the desired color system
[[2] - same url() constraints as for image references
 [2] - see [Non-textual information - Section 5.2.1]
][1] - [rgb-icc]() is used for a color property value to reference the named color profile according to numeric arguments specific to the profile definition
[[2] - note the function requires fallback RGB specification in the case the formatter does not recognize the desired color system
]]
11.1.6 <declarations> Object
[> 11.1.7][> 11.2][> 12.][< 11.1.5][^][^^][^^^]
Purpose:
[[1] - a repository of global formatting object constructs including the collection of available color profiles and any collection of extended formatting objects supported by an XSL-FO processor
]
Content:
[[1] - [F1.0]([6.4.3]) ([​color-profile])+
 [1] - [F1.1]([6.4.3]) ([​color-profile])*
 [1] - Child object:
[[2] - <[color-profile]>([6.4.4];[Section 11.1.5 <color-profile> Object])
][1] - Referring object:
[[2] - <[root]>([6.4.2];[Section 3.3.8 <root> Object])
]]
No properties are defined for this formatting object.
This is an optional child of <[root]>.
11.1.7 Characters and bi-directional text
[> 11.1.8][> 11.2][> 12.][< 11.1.6][^][^^][^^^]
Character formatting objects govern the presentation of glyphs associated with coded characters
[[1] - <[character]>
 [1] - implicitly created by the presence of text nodes (#PCDATA) in the XSL-FO instance
[[2] - see [Figure 3.1]
][1] - explicitly created using an element in the XSL-FO vocabulary
[[2] - prevents the need to represent the character as a coded character
 [2] - provides for specifying properties on a single character in the flow
]]
Overriding the inherent behavior of characters as defined by Unicode
[[1] - <[bidi-override]>
 [1] - most uses of characters require no special handing
[[2] - most Unicode characters have an intrinsic writing-direction property utilized by the formatter
[[3] - some characters have a weak or neutral writing direction
][2] - the processor is supposed to respect the writing direction of all characters so that the stylesheet writer does not have to accommodate any combination used by the author of the XML document being formatted
][1] - special formatting requirements may require behavior different than intrinsically defined
[[2] - e.g. to protect left-to-right presentation from being influenced by the presence right-to-left characters
 [2] - e.g. to display right-to-left characters in a left-to-right fashion
]]
11.1.8 <character> Object
[> 11.2][> 12.][< 11.1.7][^][^^][^^^]
Purpose:
[[1] - both the abstract formatting object implied by a simple text-node character in an XSL-FO instance and the concrete formatting object available to be used in place of a simple character
]
Content:
[[1] - ([6.6.3]) EMPTY
]
Property sets:
[[1] - [Common Aural Properties]([7.7];[Section D.1.3 Common Aural Properties])
 [1] - [Common Border, Padding, and Background Properties]([7.8];[Section D.1.4 Common Border, Padding, and Background Properties])
 [1] - [Common Font Properties]([7.9];[Section D.1.5 Common Font Properties])
 [1] - [Common Hyphenation Properties]([7.10];[Section D.1.6 Common Hyphenation Properties])
 [1] - [Common Margin Properties-Inline]([7.12];[Section D.1.8 Common Margin Properties-Inline])
 [1] - [Common Relative Position Properties]([7.13];[Section D.1.9 Common Relative Position Properties])
]
Other required property:
[character=]([7.17.1];[Section D.3.3 Property summary])
Other optional properties:
[alignment-adjust=]([7.14.1];[Section D.3.3 Property summary])
[alignment-baseline=]([7.14.2];[Section D.3.3 Property summary])
[baseline-shift=]([7.14.3];[Section D.3.3 Property summary])
[color=]([7.18.1];[Section D.3.3 Property summary])
[dominant-baseline=]([7.14.5];[Section D.3.3 Property summary])
[glyph-orientation-horizontal=]([7.29.2];[Section D.3.3 Property summary])
[glyph-orientation-vertical=]([7.29.3];[Section D.3.3 Property summary])
[id=]([7.30.8];[Section D.3.3 Property summary])
[F1.1][index-class=]([7.24.1];[Section D.3.3 Property summary])
[F1.1][index-key=]([7.24.2];[Section D.3.3 Property summary])
[keep-with-next=]([7.20.4];[Section D.3.3 Property summary])
[keep-with-previous=]([7.20.5];[Section D.3.3 Property summary])
[letter-spacing=]([7.17.2];[Section D.3.3 Property summary])
[line-height=]([7.16.4];[Section D.3.3 Property summary])
[score-spaces=]([7.30.15];[Section D.3.3 Property summary])
[suppress-at-line-break=]([7.17.3];[Section D.3.3 Property summary])
[text-altitude=]([7.29.4];[Section D.3.3 Property summary])
[text-decoration=]([7.17.4];[Section D.3.3 Property summary])
[text-depth=]([7.29.5];[Section D.3.3 Property summary])
[text-shadow=]([7.17.5];[Section D.3.3 Property summary])
[text-transform=]([7.17.6];[Section D.3.3 Property summary])
[treat-as-word-space=]([7.17.7];[Section D.3.3 Property summary])
[visibility=]([7.30.17];[Section D.3.3 Property summary])
[word-spacing=]([7.17.8];[Section D.3.3 Property summary])
Shorthands influencing the above properties:
[font=]([7.31.13];[Section D.3.3 Property summary])
[page-break-after=]([7.31.16];[Section D.3.3 Property summary])
[page-break-before=]([7.31.17];[Section D.3.3 Property summary])
[vertical-align=]([7.31.22];[Section D.3.3 Property summary])
11.2 Bidirectional writing support
[> 12.][< 11.1.8][^^][^^^]
11.2.1 The importance of bidirectional text
[> 11.2.2][> 12.][< 11.1.8][^^][^^^]
Some international formatting requirements must accommodate mixing text of different writing directions
[[1] - the presentation of right-to-left scripts (e.g. Hebrew, Arabic, Thaana, and Syriac) may be embedded in the middle of presenting left-to-right scripts
 [1] - the stylesheet is mixing its boilerplate text with authored content of either possible direction from many different sources to produce the combined result
 [1] - the formatter is responsible for placement and interpretation of glyphs on the page based on the character code points in the XSL-FO instance
 [1] - the stylesheet writer is responsible for protecting text, where possible, from being influenced in the XSL-FO instance being formatted
]
Three aspects of writing direction influence the presentation of information on a line
[[1] - a line has an inline progression direction determined by the writing direction of the closest ancestral reference area
[[2] - information is flowed onto lines in the inline progression direction, independent of the visual order of the characters in the information
][1] - a group of adjacent characters may have semantic affinity and would thus be required to be flowed onto the lines in groups
[[2] - groups are ordered in the inline progression direction
 [2] - e.g. in a right-to-left progression direction there may be groups of left-to-right characters
[[3] - the groups are rendered from the right to the left on the line, but the characters in each group are rendered from the left to the right
 [3] - without grouping, adjacent strings of the same direction would be rendered as a whole, losing the semantic affinity in the characters
][2] - e.g. boilerplate information from the stylesheet is often semantically distinct from source file information, needing insulation from undue influence from the content
][1] - characters from different scripts have inherent writing directions that may differ from the inline progression direction
[[2] - usually necessary to respect the character direction while accommodating the inline progression direction (responsibility of the formatter)
 [2] - may be necessary to override the inherent direction for a special effect
 [2] - many characters are not associated with any language and are influenced by their proximity to characters from different scripts
][1] - stylesheet writers can specify the progression direction of the information, the grouping of characters and the respect or override of the inherent Unicode direction in characters
]
11.2.2 The mechanics of mixing text of different writing directions
[> 11.2.3][> 12.][< 11.2.1][^][^^][^^^]
Evolving rendering needs are being documented by Unicode and are influenced by XSL-FO
[[1] - rendering algorithm governed primarily by the Unicode Bidirectional Algorithm
[[2] - [http://www.unicode.org/unicode/reports/tr9]
][1] - nuances are described by XSL-FO 1.0 Recommendation - Unicode BIDI Algorithm (Section [5.8]) in conjunction with the CSS definition
[[2] - XSL-FO slightly modifies the CSS definition, such as assuming an unspecified [direction]= property is assumed to be that of the [writing-mode]= in effect
][1] - these materials do not attempt to repeat the detailed algorithms described in the above documents, but only to give a general overview of the algorithm
]
There are three categories of direction strength for Unicode characters
[[1] - strong characters are from language groups with well defined left-to-right or right-to-left character progression directions
[[2] - includes "marks" that are non-spacing invisible characters with strong direction
[[3] - &#x200e; - LRM - left-to-right mark
 [3] - &#x200f; - RLM - right-to-left mark
][2] - includes embedding and directional controls that are interpreted by the rendering algorithm
[[3] - &#x202a; - LRE - left-to-right embed begin
 [3] - &#x202b; - RLE - right-to-left embed begin
 [3] - &#x202d; - LRO - left-to-right override begin
 [3] - &#x202e; - RLO - right-to-left override begin
]][1] - weak characters are digits, currency symbols and some punctuation characters
[[2] - includes mirroring characters whose presentation on the canvas may be different than their representation in the data
[[3] - e.g. "(", ")", "[", "]", "<", ">", "{", "}", "«", "»", etc.
 [3] - a mirrored character is rendered in the writing direction of adjacent text, which may require it to be flipped in presentation by the formatter
 [3] - the stylesheet writer doesn't have any responsibility for doing the flipping
][2] - includes &#x202c; - PDF - Pop Directional Formatting - for embedding levels
][1] - neutral characters are white space characters and some separator characters
]
The embedding algorithm is based on isolating groups of sequences in "embedding levels"
[[1] - an embedded sequence has a progression direction for the members of the sequence
[[2] - members are characters or other embedded sequences
][1] - the stylesheet writer may need to introduce embedding levels to keep a sequence of characters together
[[2] - the stylesheet would need to recognize or predict the semantic affinity of the group to know where to embed a new level
][1] - using <[bidi-override]> will create an embedding level
[[2] - the progression direction of the level is either the specified [direction]= or the current writing-mode direction if not specified
 [2] - using a [unicode-bidi]= value of "embed" doesn't change the inherent writing direction of the individual characters in the embedding level
 [2] - using a [unicode-bidi]= value of "bidi-override" forces the characters to render in the direction of the embedding level, ignoring the inherent properties of the characters
[[3] - all characters are assigned the overriding direction as if they were strongly directed and their original nature is forgotten
]][1] - embedding levels are indicated in the resulting stream using LRE, RLE, LRO, RLO and PDF Unicode characters
]
The resulting stream of characters is grouped according to the Unicode directionality controls
[[1] - the grouping of characters crosses boundaries of embedding levels
 [1] - the act of grouping weak characters with strong characters gives direction to the weak characters
[[2] - weak characters are influenced by their proximity to strong characters to become strongly directed themselves
 [2] - weak characters between two strong characters of the same direction adopt that direction
 [2] - weak characters preceding a strong character without white space interruption adopt the strong character's direction
 [2] - weak characters following a strong character and any intervening white space adopt the strong character's direction
][1] - the characters are rendered after all of the characters have been assigned a direction
]
11.2.3 Illustration of bidirectional embedding
[> 11.2.4][> 12.][< 11.2.2][^][^^][^^^]
Examples in this book include sequences of right-to-left language text
[[1] - &hebrew-test; is "Hebrew test" in Hebrew
 [1] - &arabic-test; is "Arabic test" in Arabic
]
[Example 11-1: Sample Unicode sequences of right-to-left language text
01  <!ENTITY hebrew-test  "&#x05D1;&#x05D3;&#x05D9;&#x05E7;&#x05D4;
02   &#x05E2;&#x05D1;&#x05E8;&#x05D9;&#x05EA;">
03  <!ENTITY arabic-test1 "&#x0625;&#x062e;&#x062a;&#x0628;&#x0627;">
04  <!ENTITY arabic-test2 "&#x0631; &#x0639;&#x0631;&#x0628;&#x064a;">
05  <!ENTITY arabic-test "&arabic-test1;&arabic-test2;">
]
Consider a detailed example of mixing sequences of different directions in bidimech.fo:
[[1] - lines in the test are grouped differently to illustrate how groups are ordered in the writing direction for rendering before the characters found in the group are rendered
[[2] - test "12" is left-to-right with embedded sequences of right-to-left text
 [2] - test "23" is right-to-left with the identical content as test "12"
 [2] - test "34" is almost identical to test "23" except for an introduced space after "89"
 [2] - test "45" is right-to-left but the language text inside is in groups without overriding direction
 [2] - test "56" is left-to-right but the language text inside is in groups that override direction
 [2] - test "67" is right-to-left but the language text inside is in groups that override direction
 [2] - note where the direction isn't specified, it is inferred by the writing mode
[[3] - this is different than CSS that assumes left-to-right when not specified
]][1] - weak punctuation characters separate the strong script characters
[[2] - the first three tests illustrate the differences in assignment of direction to weak characters
 [2] - note the introduction of a space at the end of the "34" test changes the direction assignment to the "89" characters from the "89" characters in the "23" test
][1] - embedding groups arrange the groups of left-to-right sequences
[[2] - in test "34" the English text is shown to the left of the French text
 [2] - in test "45" the French text is shown to the left of the English text
][1] - overriding the direction results in improper presentation of language text
[[2] - in test "56" the Hebrew and Arabic sequences are inappropriately presented
 [2] - in test "67" the English and French sequences are inappropriately presented
]]
[Example 11-2: Controlling bi-directionality using grouping
01    <block-container>
02   <block>12 - English Test 13 , Test Français 14
03   + &hebrew-test; 15 = &arabic-test; 16 / 89end</block>
04   </block-container>
05   <block-container writing-mode="rl-tb">
06   <block>23 - English Test 13 , Test Français 14
07   + &hebrew-test; 15 = &arabic-test; 16 / 89end</block>
08   </block-container>
09   <block-container writing-mode="rl-tb">
10   <block>34 - English Test 13 , Test Français 14
11   + &hebrew-test; 15 = &arabic-test; 16 / 89 end</block>
12   </block-container>
13   <block-container writing-mode="rl-tb">
14   <block>45 - <bidi-override unicode-bidi="embed"
15   >English Test 13</bidi-override>
16   , <bidi-override unicode-bidi="embed"
17   >Test Français 14</bidi-override>
18   + <bidi-override unicode-bidi="embed"
19   >&hebrew-test; 15</bidi-override>
20   = <bidi-override unicode-bidi="embed"
21   >&arabic-test; 16</bidi-override>
22   / 89 end</block></block-container>
23   <block-container>
24   <block>56 - <bidi-override unicode-bidi="bidi-override"
25   >English Test 13</bidi-override>
26   , <bidi-override unicode-bidi="bidi-override"
27   >Test Français 14</bidi-override>
28   + <bidi-override unicode-bidi="bidi-override"
29   >&hebrew-test; 15</bidi-override>
30   = <bidi-override unicode-bidi="bidi-override"
31   >&arabic-test; 16</bidi-override>
32   / 89 end</block></block-container>
33   <block-container writing-mode="rl-tb">
34   <block>67 - <bidi-override unicode-bidi="bidi-override"
35   >English Test 13</bidi-override>
36   , <bidi-override unicode-bidi="bidi-override"
37   >Test Français 14</bidi-override>
38   + <bidi-override unicode-bidi="bidi-override"
39   >&hebrew-test; 15</bidi-override>
40   = <bidi-override unicode-bidi="bidi-override"
41   >&arabic-test; 16</bidi-override>
42   / 89 end</block></block-container>
]
This figure illustrates the on-screen interpretation of the bidimech.fo file:
[[1] - the line annotations are only for illustrative purposes regarding the groupings of characters and the character writing directions
 [1] - this test does not incorporate explicit use of Unicode directionality characters
[[2] - the use of <[bidi-override]> introduces these characters into the rendering stream
][1] - note how the grouping of characters for strength purposes goes over the bounds of embedded levels
]
[Figure 11.1: Example of bi-directionality
Six lines of text are shown illustrating the six tests in the associated fragment of formatting objects.
The first line is aligned to the left and the characters seen from left to right as the sequences "12 - English Test 13 , Test Français 14 +89 / 16 ", a sequence of properly-ordered Arabic characters (right-to-left), " = 15 ", a sequence of properly-ordered Hebrew characters (right-to-left), "end".
The second line is aligned to the right and the characters seen from left to right as the sequences "89end / 16 ", a sequence of properly-ordered Arabic characters (right-to-left), " = 15 ", a sequence of properly-ordered Hebrew characters (right-to-left), " + English Test 13 , Test Français 14 - 23".
The third line is aligned to the right and the characters seen from left to right as the sequences "end 89 / 16 ", a sequence of properly-ordered Arabic characters (right-to-left), " = 15 ", a sequence of properly-ordered Hebrew characters (right-to-left), " + English Test 13 , Test Français 14 - 34".
The fourth line is aligned to the right and the characters seen from left to right as the sequences "end 89 / 16 ", a sequence of properly-ordered Arabic characters (right-to-left), " = 15 ", a sequence of properly-ordered Hebrew characters (right-to-left), " + Test Français 14 , English Test 13 - 45".
The fifth line is aligned to the left and the characters seen from left to right as the sequences "56 - English Test 13 , Test Français 14 ", a sequence of improperly-ordered Hebrew characters (left-to-right), " = 15 ", a sequence of improperly-ordered Arabic characters (right-to-left), " 16 / 89 end".
The sixth line is aligned to the right and the characters seen from left to right as the sequences "end 89 / 61 ", a sequence of properly-ordered Arabic characters (right-to-left), " = 51 ", a sequence of properly-ordered Hebrew characters (right-to-left), " + 41 siaçnarF tseT , 31 tseT hsilgnE - 67".
]
11.2.4 The bidirectional support challenge
[> 11.2.5][> 12.][< 11.2.3][^][^^][^^^]
The challenge for the stylesheet writer is to recognize when it is necessary to add marks or add embedding levels in the flow
[[1] - always using a single stream of character information will only work if all of the text is in the same direction as the inline progression direction
[[2] - a stylesheet used internationally would need to respect the possibility of lines mixing weak and neutral characters with both directions of strongly directed characters
][1] - e.g. consider mixing boilerplate text with authored text
[[2] - authored text could be assumed to be presented to the author correctly while being entered, thus the content as entered could be formatted without special concerns
 [2] - if English boilerplate text is to be abutted to language text of an arbitrary language, weak characters in the boilerplate text might be inadvertently influenced by the strong characters of the authored text
[[3] - the influence could rearrange characters or flip the rendering of mirrored characters found in the boilerplate
][2] - use <[bidi-override]> to embed authored text at a separate embedding level than surrounding text
]]
Be aware when formatting generated content such as table of contents entries
[[1] - mixing authored title content with stylesheet boilerplate content
[[2] - leaders and page numbers follow the arbitrary title text
 [2] - the content of the title is abutted to the leaders and page numbers
][1] - wrapping the authored text in a different embedding level will protect the text characters from influencing the leaders, page numbers and other surrounding text
]
The sample file biditest.xml includes titles utilizing text of different writing directions, each section with a title and a number of subsections.
[Example 11-3: A test file with mixed character directions
01  <!DOCTYPE doc [
02  <!ENTITY hebrew-test "&#x05D1;&#x05D3;&#x05D9;&#x05E7;&#x05D4;
03   &#x05E2;&#x05D1;&#x05E8;&#x05D9;&#x05EA;">
04  <!ENTITY arabic-test1 "&#x0625;&#x062e;&#x062a;&#x0628;&#x0627;">
05  <!ENTITY arabic-test2 "&#x0631; &#x0639;&#x0631;&#x0628;&#x064a;">
06  <!ENTITY arabic-test "&arabic-test1;&arabic-test2;">
07  ]>
08  <doc>
09   <section>
10   <title>English Test</title>
11   <subsection>Sub 1 in English</subsection>
12   ...
13   <subsection>Sub 15 in English</subsection>
14   </section>
15   <section>
16   <title>&hebrew-test;</title>
17   <subsection>Sub 1 in Hebrew</subsection>
18   ...
19   <subsection>Sub 14 in Hebrew</subsection>
20   </section>
21   <section>
22   <title>&arabic-test;</title>
23   <subsection>Sub 1 in Arabic</subsection>
24   ...
25   <subsection>Sub 14 in Arabic</subsection>
26   </section>
27   <section>
28   <title>Test Fran&#xe7;ais</title>
29   <subsection>Sub 1 in French</subsection>
30   ...
31   <subsection>Sub 12 in French</subsection>
32   </section>
]
The file biditest.xsl formats three tables of content, the first without protection, the second protecting the boilerplate of the entries from the arbitrary text directions of the characters obtained from the titles, and the third making the punctuation group follow in the text direction of the title by being isolated from the leader and following text.
[Example 11-4: Adding marks
01    <block space-after=".5cm">
02   This is a table of contents without using embed:
03   </block>
04   <xsl:for-each select="/doc/section">
05   <block text-align-last="justify">
06   <xsl:value-of select="position()"/>.
07   <xsl:value-of select="title"/>
08   (<xsl:value-of select="count(subsection)"/>)
09   <leader leader-pattern="dots"/>
10   <page-number-citation ref-id="{generate-id(.)}"/>
11   </block>
12   </xsl:for-each>
13   <block space-before="1.5cm" space-after=".5cm">
14   This is a table of contents using embed:
15   </block>
16   <xsl:for-each select="/doc/section">
17   <block text-align-last="justify">
18   <xsl:value-of select="position()"/>.
19   <bidi-override unicode-bidi="embed">
20   <xsl:value-of select="title"/>
21   </bidi-override>
22   (<xsl:value-of select="count(subsection)"/>)
23   <leader leader-pattern="dots"/>
24   <page-number-citation ref-id="{generate-id(.)}"/>
25   </block>
26   </xsl:for-each>
27   <block space-before="1.5cm" space-after=".5cm">
28   This is a table of contents using two embeds:
29   </block>
30   <xsl:for-each select="/doc/section">
31   <block text-align-last="justify">
32   <xsl:value-of select="position()"/>.
33   <bidi-override unicode-bidi="embed">
34   <xsl:value-of select="title"/>
35   <bidi-override unicode-bidi="embed">
36   (<xsl:value-of select="count(subsection)"/>)
37   </bidi-override>
38   </bidi-override>
39   <leader leader-pattern="dots"/>
40   <page-number-citation ref-id="{generate-id(.)}"/>
41   </block>
42   </xsl:for-each>
]
The formatted result illustrates the impact of including the marks for protection from the characters of the titles:
[Figure 11.2: Example of using marks
Two tables of contents are shown with entries numbered 1 through 4, the entry's title, a parenthesized number, a dot leader, and a number indicating the page the entry is found.
In the first of the two examples, the parenthesized numbers have been influenced by the two titles utilizing right-to-left sequences, and the display is unacceptable.
The second of the two examples is rendered in a logical and expected fashion.
]
Note the behavior when protection is not used in the top rendering:
[[1] - the right-to-left text influences the following weak characters " (14" and makes them all part of a right-to-left group
[[2] - the "(" character is displayed as ")" because it is a mirror character being displayed right-to-left
][1] - the "14" still renders left-to-right because the grouping isn't powerful enough to override the inherent writing direction of the digits
 [1] - the original ")" and following space is influenced by the <[leader]>and the writing direction of the line, which is left to right, so the mirroring character doesn't change
]
11.2.5 <bidi-override> Object
[> 12.][< 11.2.4][^][^^][^^^]
Purpose:
[[1] - specifies how to manage and override the inherent Unicode text direction for a sequence of characters
 [1] - this is not needed for standard processing of a mixture of writing-mode characters, as the processor will recognize the inherent text direction and act accordingly
]
Content:
[[1] - ([6.6.2]) (#PCDATA|[​%inline;]|[​%block;])*
 [1] - Child objects (alphabetical):
[[2] - [%block;]([6.2];[Section 3.4.2 Block-level objects])
 [2] - [%inline;]([6.2];[Section 3.4.3 Inline-level objects])
]]
[[1] - may begin with any number of <[marker]> children
]
Property sets:
[[1] - [Common Aural Properties]([7.7];[Section D.1.3 Common Aural Properties])
 [1] - [Common Font Properties]([7.9];[Section D.1.5 Common Font Properties])
 [1] - [Common Relative Position Properties]([7.13];[Section D.1.9 Common Relative Position Properties])
]
Other optional properties:
[color=]([7.18.1];[Section D.3.3 Property summary])
[direction=]([7.29.1];[Section D.3.3 Property summary])
[id=]([7.30.8];[Section D.3.3 Property summary])
[F1.1][index-class=]([7.24.1];[Section D.3.3 Property summary])
[F1.1][index-key=]([7.24.2];[Section D.3.3 Property summary])
[letter-spacing=]([7.17.2];[Section D.3.3 Property summary])
[line-height=]([7.16.4];[Section D.3.3 Property summary])
[score-spaces=]([7.30.15];[Section D.3.3 Property summary])
[unicode-bidi=]([7.29.6];[Section D.3.3 Property summary])
[word-spacing=]([7.17.8];[Section D.3.3 Property summary])
Shorthand influencing the above properties:
[font=]([7.31.13];[Section D.3.3 Property summary])
Properties of interest:
[[1] - [unicode-bidi]=
[[2] - use "embed" to wrap groups of characters where the groups are to progress in the writing direction of the parent construct
[[3] - preserves the inherent writing direction of the characters in the group
][2] - use "bidi-override" to force the wrapped characters to progress in the writing direction of the parent construct
[[3] - overrides the inherent writing direction of the characters in the group
]][1] - [direction]=
[[2] - use "ltr" and "rtl" for the nature of the embedded behavior
 [2] - the default direction is that of the parent construct
]]


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

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

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