Created attachment 200062 [details] FixedCellHeight_affectingShape_LiberationAutofitB.pptx: example file After saving this example file using LO 7.6.5 (and still with 25.8 master), MS PowerPoint is unable to cleanly open the document. This started with 24.8 commit bff76421e234df7246a7f49c71a11432f86e09d1 Author: Balazs Varga on Sun Dec 3 23:41:01 2023 +0100 tdf#157740 FILESAVE PPTX: fix explosion of the number of master slides Steps to reproduce: 1.) verify that MS Office can cleanly open FixedCellHeight_affectingShape_LiberationAutofitB.pptx. 2.) open it in LO, and resave it. 3.) open the resaved file in MS Office. A dialog complains that the file needs to be repaired. (This is a minimized unit test example that I made with MSO 2010.) It seems to not like it when notesMaster1.xml has an id="0" for <p:cNvPr id="0" name="PlaceHolder 1"/>
If we can't just initialize mnMaxDocId as 1 in oox/source/core/xmlfilterbase.cxx, then just check in ShapeExport::WriteNonVisualDrawingProperties to just ask for another UniqueId if it gets 0.
proposed patch at https://gerrit.libreoffice.org/c/core/+/183464
(In reply to Justin L from comment #1) > If we can't just initialize mnMaxDocId as 1 in > oox/source/core/xmlfilterbase.cxx, then just check in > ShapeExport::WriteNonVisualDrawingProperties to just ask for another > UniqueId if it gets 0. Yeah thats also one solution. Also wonder why the mnMaxDocId returns 0 at the first time with the first "Placeholder 1" in the WriteNonVisualDrawingProperties and why it wasn't increased by one after we exported a groupshape before the first Placeholder. Because it looks like in the exported xml a groupshape got the id="1" and the next shape "Placeholder 1" got the id="0" and the next one "Placeholder 2" got the id="1" again and the next one "Placeholder 3" got the id="2" and so on. In the original file the order is: groupshape --> id="1" "Placeholder 1" -> id="2" "Placeholder 2" -> id="3" "Placeholder 3" -> id="4" See attached screenshot. Btw Its weird that the regression caused by this patch bff76421e234df7246a7f49c71a11432f86e09d1 since I didn't change anything related to the shape ID numbers, but only changed the file ID numbers to avoid duplicated masterslides file.
Created attachment 200068 [details] xml_screenshot
(In reply to Balázs Varga (allotropia) from comment #3) > Because it looks like in > the exported xml a groupshape got the id="1" That's just from a hard-coded string. #define MAIN_GROUP \ "<p:nvGrpSpPr>\ <p:cNvPr id=\"1\" name=\"\"/>\ <p:cNvGrpSpPr/>\ <p:nvPr/>\ </p:nvGrpSpPr>\ <p:grpSpPr>\ <a:xfrm>\ <a:off x=\"0\" y=\"0\"/>\ <a:ext cx=\"0\" cy=\"0\"/>\ <a:chOff x=\"0\" y=\"0\"/>\ <a:chExt cx=\"0\" cy=\"0\"/>\ </a:xfrm>\ </p:grpSpPr>" My theory seems to be somewhat bogus though, because we see the identical situation in slideMaster1.xml in around-trip of sd/qa/unit/data/pptx/tdf106867.pptx, and PowerPoint doesn't complain then. P.S. I think the only reason your commit came up is because it reduced the number of unnecessary shapes, so when it notesMaster began to export, it was now the first to try to export a shape. In the before/after comparison, the first notesMaster shape was id 36, not 0.
Fixed by https://git.libreoffice.org/core/commit/210c89a34bda429fe7e0b8f0e63ce5bb5add9d8b related tdf#165521 oox: ShapeExport::GetNewShapeID of at least 2