RE: [xep-support] linefeed normalization

From: Victor Mote (vic@portagepub.com)
Date: Mon Apr 05 2004 - 08:58:10 PDT

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

    Ken Holman wrote:

    > >but that it is
    > >passing through to XEP properly, but that XEP is treating it as
    > >equivalent to a linefeed character for purposes of the
    > >linefeed-treatment property. So this is probably an XEP bug
    > (unless I
    > >have overlooked some other property that is relevant here).
    >
    > It isn't a bug in XEP because the XSL-FO spec specifically
    > refers to linefeed-treatment= addressing the U+000A character
    > and no other character.
    > (ref XSL 7.15.7).

    This was my point exactly. If linefeed-treatment affects *only* U+000A, then
    why would changing *only* the linefeed-treatment property affect whether
    U+2028 creates or does not create a new line in the output?

    > This would be an issue you would want to bring "up a level"
    > to the specification writers, not the implementers. Use
    > mailto:xsl-editors@w3.org to send your XSL processing
    > requirements to the specification writers because if you
    > don't they won't know what to consider in future versions to
    > address what you need from the Specification.

    I am not trying to recommend a change in standards at all, although I may
    not fully understand how they all fit together yet. The Unicode standard
    seems to indicate that the purpose of U+2028 is to make an unambiguous
    statement that a line break is intended at this location. This would be in
    contradistinction to a normal CR, LF, or CR/LF combination, which could, and
    often does, simply mean that I wanted to make a break here in my source
    document to make it more readable. I haven't found anything in the XML or
    XSL-FO standards that seems to contradict or override that. The
    linefeed-treatment and related properties all seem to be bent on giving the
    user flexibility with interpreting the meaning of the potentially ambiguous
    CR, LF, and CR/LF characters, but do *not* seem to affect U+2028.

    Victor Mote

    -------------------
    (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    in the body of the message to majordomo@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



    This archive was generated by hypermail 2.1.5 : Mon Apr 05 2004 - 09:08:13 PDT