docx -> typst silently failing to extract media when shape present

[RayBB]

Explain the problem.
Command: pandoc --extract-media=. image_bug.docx -o image_bug.typ
Input file: image_bug.docx

Edit: here's a second example file: image_bug2.docx

I would expect the output to be a image_bug.typ containing some text with an image and a media folder with one image in it.
Unfortunately, it doesn't output the media folder or have a link to the image. It just shows some text.

I'm not sure what's going on with this Word document. I isolated the issue down the to smallest reproducible bug which was just the text and the image. If the text is removed the image seems to work fine. Also, this is an extract from a document I did not create so I cannot explain why the text is inside the shape like that. However, it's probably a case that should cause an error or be handled appropriately.

As always, thanks for taking the type to help with this!

Pandoc version?
pandoc 3.9 on macOS

[RayBB]

Ah it even seems to be causing some text to disappear. That's not good.

image_bug_3.docx

[jgm]

Closing as a dup of #11053.

[RayBB]

@jgm in this case are you also sure it's because of the shape element that text is disappearing?

[RayBB]

@jgm I opened a PR to address the issue you linked above.

That said, it doesn’t seem to fix the issue I’m reporting here.

From discussing it with AI, my understanding is that there’s a fundamental difference between the two cases: the original issue involves images embedded inside textboxes, whereas in the case I’m reporting here, the image is not in a textbox — it’s a standard <w:drawing> element.

[jgm]

OK, in this doc you have an mc:AlternateContent with two children, one mc:Choice Requires="wps", one with mc:Fallback. The current pandoc code just looks at the fallback. The problem is that the jpg image is used in the other branch only; the fallback seems to have a v:shape element with some binary data, and pandoc doesn't know what to do with that.

That's as far as I got so far. I'm not actually sure what mc:Choice Requires="wps" means. Perhaps pandoc should be looking at this instead of the fallback, in general.

[RayBB]

That's good info.

I tried to dig in a bit further and found some relevant links:
https://wiki.openoffice.org/wiki/OOXML/Markup_Compatibility_and_Extensibility
https://learn.microsoft.com/en-us/dotnet/api/documentformat.openxml.office2010.word.drawingshape.wordprocessingshape?view=openxml-3.0.1
https://c-rex.net/samples/ooxml/e1/Part5/OOXML_P5_Markup_Compatibility_and_Extensibility_Choice_topic_ID0EYQBG.html

mc:Choice Requires="wps" means the branch should be selected only by consumers that understand the wps namespace. OOXML’s MC rules say to select the first matching Choice; Fallback is only for consumers that don’t understand any matching Choice. So Pandoc probably should not always prefer Fallback in general; it should prefer the first Choice it understands. For this bug, if Pandoc can add support for wps (or enough to extract the image rel), that seems like the better branch to use than the fallback.

I think it would be reasonable to add support for extracting images/text from shapes. Adding broader support for shapes would be nice but it's not clear what level of work that is or how many features are really baked in there that pandoc could easily support.

[RayBB]

Now that I understand the underlying issue more I see a few related issues:

• Images with caption + number are not extracted when converting .docx to Markdown #11412
• Docx conversion ignoring inside of AlternateContent tag #5394
• docx to latex: images and captions are not being converted properly #6893
• Pandoc produces 0 length PDF from docx #8970
• Regression when image is in a Shape Format #9633

[jgm]

#6893 also has a fallback with binary data on the shape attribute, and a caption in a textbox which was previously lost but now is parsed. (But the structure is different; the image comes before the AlternateContent.)

#11412 is not really the same. There the fallback contains all the necessary information. And it is already partially fixed (image extracted but caption lost).

#5394 - this has the same weird image format in the fallback (maybe we should just teach pandoc how to read that?). But unlike this issue, the wps section doesn't contain a bitmapped image; it just has drawing instructions. So looking at the wps part there wouldn't help anyway.

#8970 - also about content in a textbox which is missing - it is already fixed by changes we've made.

#9633 - might already be fixed, unless you really want the words "Homme Nature" which are in the wps part and not the fallback.

In the Fallback on this issue, we have

<v:shape id="Text Box 1" o:spid="_x0000_s1026" type="#_x0000_t202" style="position:absolute;margin-left:0;margin-top:495.55pt;width:441.4pt;height:.05pt;z-index:487595008;visibility:visible;mso-wrap-style:square;mso-wrap-distance-left:9pt;mso-wrap-distance-top:0;mso-wrap-distance-right:9pt;mso-wrap-distance-bottom:0;mso-position-horizontal:absolute;mso-position-horizontal-relative:text;mso-position-vertical:absolute;mso-position-vertical-relative:text;v-text-anchor:top" o:gfxdata="UEsDBBQABgAIAAAAIQC2gziS/gAAAOEBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF&#xD;&#xA;90jcwfIWJU67QAgl6YK0S0CoHGBkTxKLZGx5TGhvj5O2G0SRWNoz/78nu9wcxkFMGNg6quQqL6RA&#xD;&#xA;0s5Y6ir5vt9lD1JwBDIwOMJKHpHlpr69KfdHjyxSmriSfYz+USnWPY7AufNIadK6MEJMx9ApD/oD&#xD;&#xA;OlTrorhX2lFEilmcO2RdNtjC5xDF9pCuTyYBB5bi6bQ4syoJ3g9WQ0ymaiLzg5KdCXlKLjvcW893&#xD;&#xA;SUOqXwnz5DrgnHtJTxOsQfEKIT7DmDSUCaxw7Rqn8787ZsmRM9e2VmPeBN4uqYvTtW7jvijg9N/y&#xD;&#xA;JsXecLq0q+WD6m8AAAD//wMAUEsDBBQABgAIAAAAIQA4/SH/1gAAAJQBAAALAAAAX3JlbHMvLnJl&#xD;&#xA;bHOkkMFqwzAMhu+DvYPRfXGawxijTi+j0GvpHsDYimMaW0Yy2fr2M4PBMnrbUb/Q94l/f/hMi1qR&#xD;&#xA;JVI2sOt6UJgd+ZiDgffL8ekFlFSbvV0oo4EbChzGx4f9GRdb25HMsYhqlCwG5lrLq9biZkxWOiqY&#xD;&#xA;22YiTra2kYMu1l1tQD30/bPm3wwYN0x18gb45AdQl1tp5j/sFB2T0FQ7R0nTNEV3j6o9feQzro1i&#xD;&#xA;OWA14Fm+Q8a1a8+Bvu/d/dMb2JY5uiPbhG/ktn4cqGU/er3pcvwCAAD//wMAUEsDBBQABgAIAAAA&#xD;&#xA;IQADqogtFQIAADgEAAAOAAAAZHJzL2Uyb0RvYy54bWysU8Fu2zAMvQ/YPwi6L046JCuMOEWWIsOA&#xD;&#xA;oC2QDj0rshQbkEWNUmJ3Xz9KtpOt22nYRaZF6lF872l51zWGnRX6GmzBZ5MpZ8pKKGt7LPi35+2H&#xD;&#xA;W858ELYUBqwq+Kvy/G71/t2ydbm6gQpMqZARiPV56wpeheDyLPOyUo3wE3DKUlIDNiLQLx6zEkVL&#xD;&#xA;6I3JbqbTRdYClg5BKu9p975P8lXC11rJ8Ki1V4GZgtPdQloxrYe4ZqulyI8oXFXL4RriH27RiNpS&#xD;&#xA;0wvUvQiCnbD+A6qpJYIHHSYSmgy0rqVKM9A0s+mbafaVcCrNQuR4d6HJ/z9Y+XDeuydkofsMHQkY&#xD;&#xA;CWmdzz1txnk6jU380k0Z5YnC1wttqgtM0uZ8MZ1/uqWUpNzi4zxiZNejDn34oqBhMSg4kiaJKnHe&#xD;&#xA;+dCXjiWxkwdTl9vamPgTExuD7CxIv7aqgxrAf6syNtZaiKd6wLiTXeeIUegO3TDcAcpXmhmht4N3&#xD;&#xA;cltTo53w4Ukg6U+zkKfDIy3aQFtwGCLOKsAff9uP9SQLZTlryU8F999PAhVn5qslwaL5xgDH4DAG&#xD;&#xA;9tRsgEac0WtxMoV0AIMZQ43QvJDV17ELpYSV1KvgYQw3oXc1PRWp1utURBZzIuzs3skIPRL63L0I&#xD;&#xA;dIMcgVR8gNFpIn+jSl+bdHHrUyCKk2SR0J7FgWeyZxJ9eErR/7/+p6rrg1/9BAAA//8DAFBLAwQU&#xD;&#xA;AAYACAAAACEAkuaELeMAAAANAQAADwAAAGRycy9kb3ducmV2LnhtbEyPMU/DMBCFdyT+g3VILIg6&#xD;&#xA;CVWVpnGqqsAAS0XowubG1zgQ25HttOHfc3SB5aS7p/fufeV6Mj07oQ+dswLSWQIMbeNUZ1sB+/fn&#xD;&#xA;+xxYiNIq2TuLAr4xwLq6viplodzZvuGpji2jEBsKKUDHOBSch0ajkWHmBrSkHZ03MtLqW668PFO4&#xD;&#xA;6XmWJAtuZGfpg5YDbjU2X/VoBOzmHzt9Nx6fXjfzB/+yH7eLz7YW4vZmelzR2KyARZzinwN+Gag/&#xD;&#xA;VFTs4EarAusFEE0UsFymKTCS8zwjnMPlkgGvSv6fovoBAAD//wMAUEsBAi0AFAAGAAgAAAAhALaD&#xD;&#xA;OJL+AAAA4QEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA&#xD;&#xA;CAAAACEAOP0h/9YAAACUAQAACwAAAAAAAAAAAAAAAAAvAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA&#xD;&#xA;CAAAACEAA6qILRUCAAA4BAAADgAAAAAAAAAAAAAAAAAuAgAAZHJzL2Uyb0RvYy54bWxQSwECLQAU&#xD;&#xA;AAYACAAAACEAkuaELeMAAAANAQAADwAAAAAAAAAAAAAAAABvBAAAZHJzL2Rvd25yZXYueG1sUEsF&#xD;&#xA;BgAAAAAEAAQA8wAAAH8FAAAAAA==&#xD;&#xA;" stroked="f">
<v:textbox style="mso-fit-shape-to-text:t" inset="0,0,0,0">
<w:txbxContent>
<w:p w14:paraId="5D1CB342" w14:textId="5E3B556E" w:rsidR="00B25E02" w:rsidRPr="003A736D" w:rsidRDefault="00B25E02" w:rsidP="00B25E02">
<w:pPr>
<w:pStyle w:val="Caption"/>
<w:rPr>
<w:rFonts w:ascii="Helvetica" w:hAnsi="Helvetica"/>
<w:sz w:val="22"/>
<w:szCs w:val="22"/>
<w:lang w:val="en-US"/>
</w:rPr>
</w:pPr>
<w:r>
<w:t xml:space="preserve">Figure
</w:t>
</w:r>
<w:r>
<w:fldChar w:fldCharType="begin"/>
</w:r>
<w:r>
<w:instrText xml:space="preserve"> SEQ Figure \* ARABIC
</w:instrText>
</w:r>
<w:r>
<w:fldChar w:fldCharType="separate"/>
</w:r>
<w:r>
<w:rPr>
<w:noProof/>
</w:rPr>
<w:t>6
</w:t>
</w:r>
<w:r>
<w:fldChar w:fldCharType="end"/>
</w:r>
</w:p>
</w:txbxContent>
</v:textbox>
<w10:wrap type="topAndBottom"/>
</v:shape>

The actual image seems to be contained in the binary data on the o:gfxdata attribute of the shape element. If we could figure out how to extract this, that could be one solution. Pandoc seems to be getting the caption out of the textbox all right.

[jgm]

Claude says:
it's a Base64-encoded ZIP archive — specifically a mini Office Open XML package.
It contains:

File	Purpose
[Content_Types].xml	Declares MIME types for the package parts
_rels/.rels	Relationships file linking the parts together
drs/e2oDoc.xml	The DrawingML shape definition (geometry, style, text)
drs/downrev.xml	Revision/version metadata for the drawing

Why it exists: This is a VML + DrawingML hybrid pattern used in Word documents. The outer <v:shape> element is VML (Vector Markup Language), a legacy drawing format from the pre-OOXML era. The o:gfxdata attribute carries the modern DrawingML equivalent of the same shape, embedded as a self-contained package, so applications that support DrawingML can use the richer representation instead of the VML fallback.

So, I don't think we can get an image out of this.