ISSUE-106: XSL linebreaking not specified

Linebreaking

XSL linebreaking not specified

XSL:FO Section 4.7.2 is somewhat vague as to what constitutes a legal line breaking algorithm.

"The partitioning occurs at legal line-breaks. Specifically, if A is the last area of Si and B is the first area of Si+1, then the rules of the language, script and hyphenation constraints (7.10 Common Hyphenation Properties, 7.16.1 hyphenation-keep, and 7.16.2 hyphenation-ladder-count) in effect must permit a line-break between A and B, within the context of all areas in Si and Si+1"

As we refer to this via Section 9.4 this means timed text is also similarly vague. While we would not want to constrain implementations to any specific line breaking algorithm (this would likely be impossible anyway), we should clarify this situation by defining that any such an algorithm respect Unicode line breaking opportunities, and refer to Unicode for those opportunities (e.g. UAX #14 : http://www.unicode.org/unicode/reports/tr14/tr14-17.html)

Note however that Unicode line breaking opportunities are not compatible with the so called 'snake mode' for multiline dynamic flow, and so to support that mode we would need to provide authorial override.

Related notes:

Changelog:

Created issue 'XSL linebreaking not specified' nickname Linebreaking owned by Sean Hayes on product DFXP 1.0, description 'XSL:FO Section 4.7.2 is somewhat vague as to what constitutes a legal line breaking algorithm.

"The partitioning occurs at legal line-breaks. Specifically, if A is the last area of Si and B is the first area of Si+1, then the rules of the language, script and hyphenation constraints (7.10 Common Hyphenation Properties, 7.16.1 hyphenation-keep, and 7.16.2 hyphenation-ladder-count) in effect must permit a line-break between A and B, within the context of all areas in Si and Si+1"

As we refer to this via Section 9.4 this means timed text is also similarly vague. While we would not want to constrain implementations to any specific line breaking algorithm (this would likely be impossible anyway), we should clarify this situation by defining that any such an algorithm respect Unicode line breaking opportunities, and refer to Unicode for those opportunities (e.g. UAX #14 : http://www.unicode.org/unicode/reports/tr14/tr14-17.html)

Note however that Unicode line breaking opportunities are not compatible with the so called 'snake mode' for multiline dynamic flow, and so to support that mode we would need to provide authorial override.' non-public