Re: [xep-support] linefeed normalization

From: Nikolai Grigoriev (
Date: Mon Apr 05 2004 - 07:29:24 PDT

  • Next message: Victor Mote: "RE: [xep-support] linefeed normalization"

    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

    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?

    Nikolai Grigoriev

    (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    in the body of the message to from the address
    you are subscribed from.
    (*) By using the Service, you expressly agree to these Terms of Service

    This archive was generated by hypermail 2.1.5 : Mon Apr 05 2004 - 07:38:52 PDT