[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=26555#action_26555 ] 

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

No, I think it would be written to ODF again as 

bar^<text:s>^<text:s>^foo

because the <text:s> might have material impact on how layout is done.  I suppose it might be the same as 

bar^<text:s text:c="4">foo

and even bar<text:s text:c="5">foo

depending on whether the semantics of those spaces is simply that they are spaces and they can't be collapsed further.  I could be convinced of that unless there is an existing case that breaks under that assumptiion.  One consequence is that <text:s> is not equivalent to U+00A0 (&nbsp;) which I have probably been assuming that it is but without any justification for that.

The interesting question is whether the sequence can be broken by a soft page break, or would the soft page break always be at the end (that is, before "foo").   And if a hard line break is inserted in the middle, does it really keep the following spaces on the start of the new line?

Now here's a puzzle for you.

<text:s text:c="0"> is a legitimate occurrence.  Interesting how that might be used, huh?

> 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