From: Nikolai Grigoriev (email@example.com)
Date: Mon Apr 05 2004 - 07:29:24 PDT
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
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?
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to firstname.lastname@example.org 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
This archive was generated by hypermail 2.1.5 : Mon Apr 05 2004 - 07:38:52 PDT