From: Victor Mote (vic@portagepub.com)
Date: Mon Apr 05 2004 - 08:58:10 PDT
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