[xep-support] linefeed normalization

[Victor Mote]

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 at 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 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