Case in hand: we had a customer copy and paste something into a web form and run an export into ODS format and discovered the file was corrupted. We investigated and found the text blob that the customer copied and pasted was a completely messed-up text blob due to multiple bad encoding transforms before it ever reached us, and it appears that rather than clean it up, the user intended to archive it as-is. The text blob contained a 0x06 codepoint, and lo and behold the exported ODS file contained the same 0x06 codepoint.
There’s some internal debate as to whether or not we should even try to do something rational with such input, but in any case it would seem the most faithful representation of the input is an invalid ODS document, but that’s not good for the user.
So I suppose there’s two parts to the question. 1) Is there any hope in encoding that codepoint into an ODS document without it being thrown out as invalid, and 2) what’s a sensible response. We’re pretty sure that codepoint started life as a glyph not a cursor control codepoint.
We note that such characters can be encoded into an XML document if the XML version is changed to 1.1; however I’m not sure if changing the XML version to 1.1 would result in a non-conformant ODS file. I’m not too concerned with somebody sending a 0, because 0’s never had a non-blank glyph but several cases where a space would have been a correct interpretation.