Created attachment 203066 [details] Sample DOCX with WMF The attached DOCX is a minimized version of attachment 68209 [details] from bug 55728 (test file name fdo55728-1.docx). It only contains the embedded WMF (EMF?) from the original, and as can be seen, the images in three cells (all within a single WMF file) aren't displayed. This started with the following commit in 26.2: https://git.libreoffice.org/core/commit/0200a718af66ec1e8d2e41e937aaebcd337a147e author Andras Timar <andras.timar@collabora.com> Tue Sep 09 15:09:59 2025 +0200 committer Andras Timar <andras.timar@collabora.com> Wed Sep 10 10:23:44 2025 +0200 tdf#137833 Always respect EXIF Orientation tag when importing a JPEG
Created attachment 203067 [details] Comparison screenshot (Word vs. Writer)
Reproducible Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b86c16870251877962e986ec9d1418e1f376241f CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Latest version that works on the ones I have installed. Version: 25.8.3.0.0+ (X86_64) / LibreOffice Community Build ID: 5442778d975c1a6146ce6ff0c66a13c64dcab904 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
The WMF in the DOCX opens with all illustrations visible in Inkscape. But - this doesn't really seem to be a FILEOPEN issue - it's whatever we use to render WMF's/EMF's - which we can't edit anyway. Also, it's not about the DOCX; you can just open the (separate) WMF, itself, in LO Draw - and see the same thing. Observed with: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0d986755e4153230670c820dc52cc40cd72dfa87 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US
Created attachment 203069 [details] The misrendered WMF
Code pointer: https://opengrok.libreoffice.org/xref/core/vcl/source/filter/jpeg/Exif.cxx?r=c9da81db9684cc3d83bd25fcae5ed2bed5401550#82 The problem is Exif::processJpeg not restoring the stream endianness.
(In reply to Eyal Rozenberg from comment #3) > But - this doesn't really seem to be a FILEOPEN issue - it's whatever we use > to render WMF's/EMF's - which we can't edit anyway. Even when you suspect something, and comment about it, it's possibly useful to refrain from editing bug title based on the suspicion, until you are sure.
https://gerrit.libreoffice.org/c/core/+/191713
Andras Timar committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bae6c3ac004111965754e71dbb0a97adc034b0d9 tdf#168634 Exif::processJpeg unhelpfully changes the endianness of the stream It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c15f5d20714214d6e6fd6c213b7f2d056b6c0ef0 Related: tdf#168634 Make Exif::processJpeg restore endianness It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Version: 25.8.3.0.0+ (X86_64) / LibreOffice Community Build ID: 58f7ecbcf486672bc5c1dddd25cd0097113a8d51 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded