-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: ODF 1.2 COS 1
-
Fix Version/s: ODF 1.2 Errata 01, ODF 1.3, ODF 1.3 CSD 02
-
Component/s: Paragraph, Part 3 (Schema) [1.2: 1]
-
Labels:None
-
Proposal:
If whitespace inside of text
is to be collapsed as OpenOffice currently does then perhaps mentioning this explicitly would be best. Also making it explicit that the first space is retained and subsequent once ignored so that in the context of the text:span it is explicit where the retained space will be during a document save.6.1.3 mentions that text:s is to be used to represent the second and subsequent U+0020 SPACE chars.
Perhaps 6.1.2 should explicitly mention that spaces represented in the input document as text:s are not to be collapsed? In any case it might be a good idea to make how text:s is handled with respect to whitepsace explicit in 6.1.2.If whitespace inside of text is to be collapsed as OpenOffice currently does then perhaps mentioning this explicitly would be best. Also making it explicit that the first space is retained and subsequent once ignored so that in the context of the text:span it is explicit where the retained space will be during a document save. 6.1.3 mentions that text:s is to be used to represent the second and subsequent U+0020 SPACE chars. Perhaps 6.1.2 should explicitly mention that spaces represented in the input document as text:s are not to be collapsed? In any case it might be a good idea to make how text:s is handled with respect to whitepsace explicit in 6.1.2. -
Resolution:
I was recently hacking on some ODT import code an was clarifying white
space handling with respect to text 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>Hi there <text:span>foo </text:span> bar</text>
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?