Created attachment 205360 [details] bookmarkCorrupts_runSdt.docx: MS Word already considers this document to be corrupt This first comment actually describes a situation where LO current works well. It even takes this corrupt document and round-trips it as a valid document... MS Word easily complains that a document is corrupt, if a content control ends in a bookmark. A w:sdt is very particular about where a bookmarkEnd is placed. (bookmarkStart doesn't seem to be a problem - it can start anywhere...). Interestingly, bookmarkEnd can be placed OK in lots of strange places (inside SdtPr, rPr), but it cannot be placed as the last item inside of the content control. Note that this is NOT universally true. Anywhere is fine with richText and group. Tests as corrupt for w:text and w:checkbox. <w:p> <w:sdt> <w:sdtContent> <w:r> <w:t> some content </w:t> </w:r> <w:r> w:bookmarkEnd is OK here <w:t> ending content </w:t> w:bookmarkEnd MUST NOT be here </w:r> w:bookmarkEnd MUST NOT be here </w:sdtContent> w:bookmarkEnd MUST NOT be here <w:sdt> w:bookmarkEnd is OK here </w:p> At the moment, we seem to be OK with these paragraph-wrapped runSdt's. I think we are outputting an empty w:r for the end marker, so our bookmark gets written before the empty w:r. Or, if the bookmarkEnd was originally after the /w:sdt, it gets written back to that spot again.
Created attachment 205361 [details] bookmarkCorrupts_blockSdt.docx: MS Word already considers this document to be corrupt This comment actually describes a situation where LO current works well. It even takes this second corrupt document and round-trips it as a valid document... Surprisingly, content controls that contain a paragraph (blockSdt) are more restrictive in this aspect than are runSdts. <w:sdt> <w:sdtContent> <w:p> w:bookmarkEnd OK up to this point <w:r> w:bookmarkEnd MUST not occur from this point onwards <w:rPr/> <w:t> some content </w:p> </w:r> <w:r> <w:t> ending content </w:p> </w:r> </w:p> w:bookmarkEnd OK from here onwards </w:sdtContent> </w:sdt> P.S. Where the bookmark starts doesn't matter. For example, even if the bookmark starts in the Sdt, it still is not allowed to end in the Sdt. (Microsoft's UI blocks the 'Insert - Bookmark' option while inside a content control). P.P.S. LO tends to avoid this situation often, because it converts blockSdt's into runSdt's (which are more lenient). Once again, these restrictions do not apply to richText or w:group.
Created attachment 205362 [details] forum-mso-en-4699.docx: example document that is corrupt after round-tripped by LO I suppose by this point you would like to have a file that DOESN'T work in LO. Here you go. Steps to reproduce: 1.) open forum-mso-en-4699.docx in LO and save as DOCX 2.) try to open the file is MS Word. MS Word reports the file as corrupt. In this case, during import the checkbox is not imported as a content control. On export, grabBag properties restore it as a blockSdt - along with the offending bookmarks inside the paragraph.
Restriction also applies to w:comboBox, w:dropDownList, w:picture, and w:date.
(In reply to Justin L from comment #0) > we are outputting an empty w:r because of the bookmarkEnd attr, so our bookmark > gets written before the empty w:r. I'm pretty sure this was just lucky. Having a bookmark at the end of the paragraph stops the run at the content control end marker. So we get an extra run containing only the end marker - which of course results in an empty w:r. (Otherwise the last run also contains the end marker OK - take that as a lucky win.