PSS case opened… I’ll update here with the results if/when…
OK. Thanks. Sounds like it is a bug, then. I may open a PSS case to push on this.
Cheers,
Paul
Hi Eric,
I’m confused about the JavaScript reference here. We are using VSTO, C#, and the COM Interop Word automation interfaces to access the WordOpenXML property of a Range. We’re not (directly) using any JavaScript. Are you saying that, internally, the Interop components implement JavaScript as a wrapper around the COM components?
Thanks,
Paul
After a bit more investigation, it’s looking like this behavior only affects three cases in Word 2013:
Single leading space before non-whitespace at the very beginning of the range.
Single trailing space after non-whitespace at the very end of the range.
And the even more special case: a range that consists of only a single space. In this case, the w:r and w:t elements are omitted entirely.
If you have a range that includes non-text data, like images, at the beginning and end, and the text in the middle of the range includes single leading, and/or single trailing, spaces, these spaces will be preserved in the WordProcessingML output.
One thing I’ve noticing while researching this, is that the behavior seems to have changed a bit over time.
According to an article Brian Jones wrote about WordOpenXML in Word 2003, white space at formatting change boundaries used to be lost as well. https://blogs.msdn.microsoft.com/brian_jones/2005/07/18/intro-to-word-xml-part-2-simple-formatting/ When I try the same test in 2013, I do not lose the white space within the range… I only lose it when it’s a single leading or trailing space for the whole range, or when there’s a trailing CR for the whole range.
If MS changed this behavior, does that mean that the original behavior was incorrect? How about the current behavior? Seems like a bug to me… is there some good reason for it?
