[OASIS Issue Tracker] Commented: (OFFICE-3706) Possibleclarification in office/v1.2/cos01/part1/6.1.2 about whitespace...

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/OFFICE-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=26521#action_26521 ] 

Dennis Hamilton commented on OFFICE-3706:
-----------------------------------------

Yes, my observation of implementations is that is the left-most space (in XML sequence, not writing direction) that survives the white-space reduction process.  It is the case that white space from contiguous elements having text content collapses to the one on the left.  This matters in terms of the user interface when selections are done, of course, and it matters for deletions too.  It also indicates what element it is in for the purposes of style application, as noted.

In one of my change-tracking deletion tests, there was a space on the left of the deletion and a space on the right.  In the XML, post-deletion, the space on the right was preserved by changing it into a <text:space> element, the way that &nbsp; would be used in HTML.  Except all of the HTML I've ever seen puts the &bnsp; on the left of the breakable space, not on the right.  That way the &nbsp; doesn't usually end up at the beginning of a new line after an unfortunate line-wrapping occurs.  I don't know how that case works in ODF consumers.  I also don't know if the <text:space> is correctly restored to a normal space when the deletion is rejected [;<).

I note, however, that Part 1 section 6.1.2 is *not* specific about which element the surviving space is considered to be governed by.  The only clue is in 6.1.3 about where one would put explicit spaces with <text:s>.  Of course, there can be spaces on each side of a <text:s> sequence, because collapsing has to not cross that sequence.  And it is not much of a clue.



> Possible clarification in office/v1.2/cos01/part1/6.1.2 about whitespace...
> ---------------------------------------------------------------------------
>
>                 Key: OFFICE-3706
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3706
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Text
>            Reporter: Ben Martin 
>            Priority: Minor
>
>   I was recently hacking on some ODT import code an was clarifying white
> space handling with respect to text:p in the spec. 
> Looking at the steps shown in 6.1.2:
> 2) The character data of the paragraph element and of all descendant
> elements for which the OpenDocument schema permits the inclusion of
> character data for the element itself and all its ancestor elements up
> to the paragraph element, is concatenated in document order.
> 4) Sequences of " " (U+0020, SPACE) characters are replaced by a single
> " " (U+0020, SPACE) character.
> Consider the following contrived example:
> <text:p>Hi there <text:span>foo </text:span> bar</text:p>
> This would seem to mean that (2) would give
> "Hi there foo  bar"
> and the application of (4) would then make
> "Hi there foo bar"
> If so, logically is the space in the text:span to be removed or the one
> before the "bar". It seems OpenOffice 3.3.0 removes the second of the
> two spaces. That is, if the span containing foo is bold, then the single
> remaining space is bold too in an ODT file saved out of OO again.
> I assume this is the desired behaviour?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira