Lost: images, drawings (shapes), list numbered order, list hierarchy indent

[Disonantemus]

Lost in conversion

• image: placeholder space removed
• drawings (shapes): placeholder space is maintained
• list numbered order
• list hierarchy indent

Visual comparison

Libreoffice (png output)	rdocx (png output)

Test file

office2pdf_test.docx.zip

[mantissaman]

Thanks for the test file and the side by side comparison. That made this straightforward to reproduce, and sorry it took so long to get to.

I ran your office2pdf_test.docx through the current build and confirmed all four problems. They turn out to be four unrelated bugs in three different parts of the code, so I have split them out and I am keeping this issue as the tracker.

Images, #10. The image is anchored, and we position anchored images by taking the raw offset and treating it as an absolute page coordinate. Your file says:

<wp:positionH relativeFrom="column"><wp:posOffset>60325</wp:posOffset></wp:positionH>
<wp:positionV relativeFrom="paragraph"><wp:posOffset>635</wp:posOffset></wp:positionV>

Those offsets are relative to the column and the paragraph, and they are small, about 4.75pt and 0.05pt. We ignore relativeFrom completely, so the image gets drawn in the very corner of the sheet and effectively vanishes. We already parse the relativeFrom values, we just never use them.

Shapes, #11. Your five shapes are each wrapped in mc:AlternateContent, which is how Word writes a modern shape with a VML fallback. Our run parser does not know that element, so it keeps the whole block as raw XML and never looks inside. The shapes survive a load and save, but layout never sees them, which is why nothing is drawn.

List numbering, #12. Confirmed, every item renders as 1..

List indent, #13. Confirmed, your level 1 bullets come out at the same left position as the level 0 items above them.

One correction to your report. You noted that the image loses its placeholder space while shapes keep theirs. From what I see it is the other way round in the current build. The paragraph holding the anchored image still takes up its space, and the image is drawn elsewhere on the page, while the shapes reserve nothing at all. Not important for the fix, but worth saying so we are describing the same thing.

On timing, #10 overlaps with PR #2, which is rewriting anchored image positioning right now. I would rather not have two people editing the same function, so #10 will likely wait for that to land. The two list bugs are independent and can be picked up on their own.

[mantissaman]

All four of these are fixed on main now. Thanks again for the test file, it is what made every one of them findable.

what you reported	cause	fix
image lost	the anchor offset was read as an absolute page coordinate, ignoring relativeFrom, so the image landed in the corner of the sheet. It was also a palette PNG, which the decoder rejected outright	#10, #17
drawings lost	the shapes sit in mc:AlternateContent, which the run parser did not know, so they were kept as raw XML and never reached layout	#11
list numbered order	counters were keyed on the numbering instance rather than the abstract definition, so your two items were two separate lists that each started at 1	#12
list hierarchy indent	a numbering level carries its own indent and we parsed it and then never applied it	#13

Rendering your office2pdf_test.docx on main now gives the numbered items counting 1 and 2, the bullets stepped in a level, the wizard image in place with its transparency, and all five shapes including the two labelled boxes and the connector between them.

One correction to the record. You noted that the image lost its placeholder space while the shapes kept theirs. It was the other way round in the build you tried. Not important now that both draw, but worth saying so the report is accurate for anyone reading it later.

These land in 0.4.0. Closing.