Multimarkdown -> FODT generates XML for images wrapped in draw:frame text frames. In the first release candidate of LibreOffice, all images subsequent to the first one on MMD --> FODT output were not shown. I posted this bug:
https://bugs.documentfoundation.org/show_bug.cgi?id=96245
Making a simplified test case it turns out LO made a change so that text frames needed a unique text:name property. You can see this comparing broken vs working XML here, see e.g. line 5:
https://gist.github.com/iandol/99469b06863faf0d84a3
The LO bug has been fixed, but with the following comment:
you should set a unique name on each frame, that's the best course of action. I'll relax the current test to continue to allow empty frames for now though.
e.g.:
<draw:frame text:anchor-type="as-char" draw:z-index="1" >
should be (where XXX is a unique number or name):
<draw:frame draw:name="XXX" text:anchor-type="as-char" draw:z-index="1" >
Therefore I suspect it would be good for MMD to generate unique names for all draw:frame elements. The draw:frame element insertion occurs on line 510 and 527 here:
https://github.com/fletcher/MultiMarkdown-5/blob/master/src/odf.c#L510
Multimarkdown -> FODT generates XML for images wrapped in draw:frame text frames. In the first release candidate of LibreOffice, all images subsequent to the first one on MMD --> FODT output were not shown. I posted this bug:
https://bugs.documentfoundation.org/show_bug.cgi?id=96245
Making a simplified test case it turns out LO made a change so that text frames needed a unique text:name property. You can see this comparing broken vs working XML here, see e.g. line 5:
https://gist.github.com/iandol/99469b06863faf0d84a3
The LO bug has been fixed, but with the following comment:
e.g.:
should be (where XXX is a unique number or name):
Therefore I suspect it would be good for MMD to generate unique names for all draw:frame elements. The draw:frame element insertion occurs on line 510 and 527 here:
https://github.com/fletcher/MultiMarkdown-5/blob/master/src/odf.c#L510