What's happening
Documents containing EMF+ (Enhanced Metafile Plus) images show a placeholder SVG with "Unable to render EMF+ image" instead of the actual image. Standard EMF conversion to SVG works, but EMF+ uses GDI+ drawing records that the converter explicitly skips.
This is a follow-on to (). The classic EMF/WMF work landed, but EMF+ is still not truly rendered.
Codebase verification
The current import/render path does support classic EMF/WMF conversion.
- packages/super-editor/src/core/super-converter/v3/handlers/wp/helpers/encode-image-node-helpers.js converts metafiles during import via convertMetafileToSvg(...).
- packages/super-editor/src/tests/extensions/image.test.js documents that EMF/WMF are rendered like normal images after conversion.
- packages/super-editor/src/tests/import-export/emf-wmf-conversion.test.js asserts EMF/WMF are converted to svg/bmp/png for display while preserving original files for DOCX round-trip export.
But EMF+ is explicitly detected and downgraded to a placeholder today.
- packages/super-editor/src/core/super-converter/v3/handlers/wp/helpers/metafile-converter.js scans EMR_COMMENT records for the EMF+ signature 0x2B464D45.
- In that same file, convertEmfToSvg(...) returns a placeholder SVG labeled "Unable to render EMF+ image" instead of rendering the image when EMF+ is detected.
Why it's happening
The current EMF renderer path is built around the extracted rtf.js EMF/WMF converter and standard EMF records. EMF+ payloads use GDI+ drawing commands, so the current path deliberately avoids attempting full conversion and renders a placeholder instead.
Suggested fix
- Check for an embedded bitmap fallback in EMF+ files and render that when present.
- Extend or replace the current converter with EMF+ / GDI+ record support.
- Add a WASM or server-side conversion path for EMF+ to a browser-safe format.
Acceptance criteria
- EMF+ images render actual document content instead of the placeholder SVG.
- Existing classic EMF/WMF rendering behavior is preserved.
- DOCX round-trip export continues to preserve the original metafile asset.
- Add targeted test coverage for at least one EMF+ sample document.
Reproduction
File: m3 proposal.docx
Page 1: Cover page shows "Unable to render EMF+ image" instead of branded cover design.
m3 proposal.docx
Want to work on this? Check the Contributing Guide to get started. Comment on this issue to let us know you're picking it up.
Ref: SD-2503
What's happening
Documents containing EMF+ (Enhanced Metafile Plus) images show a placeholder SVG with "Unable to render EMF+ image" instead of the actual image. Standard EMF conversion to SVG works, but EMF+ uses GDI+ drawing records that the converter explicitly skips.
This is a follow-on to (). The classic EMF/WMF work landed, but EMF+ is still not truly rendered.
Codebase verification
The current import/render path does support classic EMF/WMF conversion.
But EMF+ is explicitly detected and downgraded to a placeholder today.
Why it's happening
The current EMF renderer path is built around the extracted rtf.js EMF/WMF converter and standard EMF records. EMF+ payloads use GDI+ drawing commands, so the current path deliberately avoids attempting full conversion and renders a placeholder instead.
Suggested fix
Acceptance criteria
Reproduction
File: m3 proposal.docx
Page 1: Cover page shows "Unable to render EMF+ image" instead of branded cover design.
m3 proposal.docx
Want to work on this? Check the Contributing Guide to get started. Comment on this issue to let us know you're picking it up.
Ref: SD-2503