[xep-support] linefeed normalization

[Nikolai Grigoriev]

Victor, Ken,

the question of U+2028 is a complicated one. The XSL-FO spec 
does not constrain its processing in any way. There is no mention
that it is subject to normalization, but equally no indication that it 
is expected to produce a line break at all. The effects of this 
character are therefore not well-defined: I doubt whether it can 
be considered a valid linefeed.

In XEP, we treat U+000A, U+000D, and U+2028 as complete 
equivalents. (This refers to the data that come to the formatter,
after linefeed normalization in the processor). The logic is
straightforward: a character is either a linefeed or not;
linefeeds terminate lines and are subject to the effects of 
linefeed-treatment; non-linefeeds do neither of these.

One can argue if this is a correct behaviour. However, 
I believe that it is inherently unsafe to rely on Unicode
text flow control characters in systems that have their own
markup to express the same semantics. There is no reason
to use U+2028 or U+2029 if you have explicit paragraph
structure set by <fo:block>s; it is risky to mix LRO/RLO/LRE/RLE
with fo:bidi-override. If you need explicit line breaks 
inside non-preformatted text, set a <br/> element in the
input XML vocabulary and match it to <fo:block/>
in the stylesheet. In this way, your intent  is clear to
everybody.

One additional consideration: in XML 1.1, U+2028 will 
be subject to parser-side linefeed  normalization. It implies 
that you never get it from user text; and if you generate 
an entity just to make it appear after the normalization, 
why not generate a piece of markup instead?

Regards,
Nikolai Grigoriev
RenderX

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo at renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html