DOCX filter: fix <w:id> creating both grab-bag and content control for <w:sdt>

Exporting the DOCX bugdoc back to DOCX resulted in a document that can't
be opened in Word.

Examining the output, the problem is that the document had 2 inline
<w:sdt> elements with <w:id>, and we mapped such <w:sdt> elements to
both grab-bags and content controls, leading to duplicate <w:sdt>
elements on export. This is schema-valid, but it goes against the
intention of the spec and Word can't open it.

The initial fix was just a writerfilter/ tweak to avoid grab-bagging
<w:id> for inline <w:sdt>, but CppunitTest_sw_ooxmlexport4's
testSimpleSdts points out that in other cases we already require
preserving <w:id>. Fix the problem by storing <w:id> in the content
control, which is essentially a subset of
<https://gerrit.libreoffice.org/c/core/+/142818>.

Thanks to Justin Luth! - he prototyped the DOCX filter for <w:id>.

Change-Id: I9f002b770049ce8be30253d0b39410d9a58981dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143117
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

1 files changed, 6 insertions, 0 deletions

diff --git a/offapi/com/sun/star/text/ContentControl.idl b/offapi/com/sun/star/text/ContentControl.idl
index 7bdb39fa5101..6abcc79fd204 100644
--- a/offapi/com/sun/star/text/ContentControl.idl
+++ b/offapi/com/sun/star/text/ContentControl.idl
@@ -121,6 +121,12 @@ service ContentControl
         @since LibreOffice 7.5
     */
     [optional, property, readonly] string DateString;
+
+    /** A unique numeric id, used by macros to identify a specific control.
+
+        @since LibreOffice 7.5
+    */
+    [optional, property] long Id;
 };