Created attachment 185033 [details] SlantUp Fontwork shape Open attached document and save it to docx format. Open the docx document in Microsoft Word and save it without changes. Open the saved document in LibreOffice. Error: LibreOffice does not show the shape. When you look in the Navigator you see, that the shape exists. The whole process has two main errors: (1) LibreOffice does not write the markup in a way, that Word detects, that it is one of the preset WordArt shapetypes. (2) When Word saves the file it writes the shape as having a custom geometry. But LibreOffice is not able to import custom geometry. This bug report will track problem (1). The shapetype "SlantUp" was chosen, because it will be exported as VML shape and not as DML shape even in released LibreOffice.
Created attachment 185035 [details] ArchUpCurve Open attached file in a current LO daily. Because it has a bitmap fill it will be written as VML shape, when the file is saved to docx. Save the file to docx and open the saved file in Word. Error: There is no WordArt but a rectangle. This is the same problem as (1). But here it is so, that no WordArt shape is written at all. Root cause is the same. The file "vml-shape-types" (located in the installation directory of LO in share/filter folder) which is used for export of shapes to VML, is not suitable for Fontwork shapes. In case of 'ArchUpCurve' the markup is simply missing in that file. It is " 144 - textArchUp " in that file. The file is likely neither suitable for other shapes with handles, but I have not tested that. Other shapes than Fontwork shapes are saved as DML shape and use the VML only as Fallback. And because current MS Word is able to read DML shapes, it ignores the Fallback. Errors in the Fallback are only detected, when you use a version before MS Word 2010.
Work has started in https://gerrit.libreoffice.org/c/core/+/146311.
Reproduced with: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ec4babad021218b75dfe8534985d7db525edde69 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded and: Microsoft® Word for Microsoft 365 MSO (Version 2212 Build 16.0.15928.20196) 64-bit
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b1fda9b2c4986ad44245020b98ddcc2e81c299bf tdf#153296 improved markup for VML shapetype of Fontwork It will be available in 7.6.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.
The problem noticed with Fontwork shapes exists the same way for other types of custom shapes too. Only that for other shape types the VML Fallback is usually not used. The patch adds a map with the correct markup for Fontwork shapes. That is not a complete fix. For other types of custom shapes still a not suitable markup is used. I think the basic idea for the "vml-shape-types" file is wrong. It generates the markup from the definitions of preset shapes in OOXML. Instead the markup should be used, that Word generates, when it saves a doc or rtf file to docx in compatibility mode. Minus the 48 types now handled, there are still 154 types that would have to be fixed. Since the VML fallback is not used for other than Fontwork shapes, I think it is not worth the effort. Therefore, I do not set the bug to 'Fixed', but will not work on it any further.
The actual adjustment values are calculated based on the geometry in svx/source/customshapes/EnhancedCustomShapeGeometry.cxx in VML export. Those geometries belong to MS binary file formats. The geometries in OOXML presets which are used in "vml-shape-types" file sometimes differ. The "right-arrow" shape has two handles in OOXML and one handle in MS binary format, for example. Thus the calculated adjustment values do not fit to the geometry in the <v:shapetype> element.
Dear Regina Henschel, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
It is OK in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 85c8901dc2710e91bccb64cd7d8068441f42f65b CPU threads: 32; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded