Images in OOXML documents render as "Error: image not found or unsupported"

[andiwand]

Every image in a .docx / .xlsx document comes out as the core's broken-image placeholder. ODF documents are fine, which is what makes it easy to miss.

Found by sweeping OpenDocument.core's input corpus on a Pixel 9 Pro (#550). Roughly 23 of 225 documents are affected — every OOXML file in the corpus that contains an image.

Cause

CoreLoader publishes the translated document on the core's http server under /file/<prefix>/, but asks for absolute resource paths:

https://github.com/opendocument-app/OpenDocument.droid/blob/main/app/src/main/java/app/opendocument/droid/background/CoreLoader.kt#L209-L212

htmlConfig.embedImages = false
htmlConfig.embedShippedResources = true
htmlConfig.relativeResourcePaths = false

For OOXML the core then emits the path as it appears in the container, rooted:

<img alt="Error: image not found or unsupported" src="/word/media/image1.jpeg"/>

The WebView resolves that against the server root, not against /file/odr/, so it misses either way. Both 404 (checked against the running app over adb forward):

/word/media/image1.jpeg            HTTP 404
/file/odr/word/media/image1.jpeg   HTTP 404

ODF documents work because the core emits their paths relative, and those resolve under the service mount point:

<img src="Pictures/1000000000000303000001E0ABAD3FD0DB2BBAE0.png"/>

/file/odr/Pictures/10000000...png  HTTP 200, 434353 bytes, image/jpg

So the server serves document resources correctly; only the absolute form misses. relativeResourcePaths = true looks like the one-line fix, but mounting the service at the server root would work too — worth deciding which is intended before changing it.

Repro

Any of these from the public corpus, all with --filter on the sweep tool or just opened by hand:

• docx/file-sample_100kB.docx (also _500kB, _1MB)
• docx/physics.docx
• docx/sample2.docx, sample3.docx, sample4.docx
• xlsx/sample.xlsx

Note

These lines arrived in #515, the odrcore JNI bindings migration, so this looks like an unintended regression rather than a deliberate setting.

Two things are separate from this and not fixed by it: the core also emits src="" for a few images (4 of 219 documents in its own reference output), and vector images (SVM/WMF) show the same placeholder for their own reasons.