Created attachment 180604 [details] The left, yellow shape is faulty The behavior for draw:path-stretchpoint-x is specified in 19.204 ODF 1.3 (see URL) as "If specified, and if the x/y aspect ratio of the svg:viewBox 19.574 is lower than the x/y aspect ratio of the shape size then the whole path is stretched horizontally at draw:path-stretchpoint-x." The attached document contains a yellow, a blue, a green and a red custom shape. The yellow and green shapes have an attribute draw:path-stretchpoint-x set. The blue and red shape have the same coordinates, but they have no draw:path-stretchpoint-x attribute. The yellow shape has the attributes svg:width="6cm", svg:height="3cm" and svg:viewBox="0 0 21600 10800". So its x/y aspect ratio of the svg:viewBox is 21600/10800=2 and the x/y aspect ratio of its size is 6cm/3cm=2. So the values are equal and therefore there should be no stretching. That means it should look the same as the blue shape. The green shape has the attributes svg:width="6cm", svg:height="6cm" and svg:viewBox="0 0 21600 21600". So its x/y aspect ratio of the svg:viewBox is 21600/21600=1 and the x/y aspect ratio of its size is 6cm/6cm=1. Here it works. The error is in method EnhancedCustomShape2d::SetPathSize() 689 fXRatio = static_cast<double>(aLogicRect.GetWidth()) / static_cast<double>(aLogicRect.GetHeight()); 690 if ( fXRatio > 1 ) 691 fXScale /= fXRatio; 692 else 693 fXRatio = 1.0; Here it tests whether the shape width of the shape is larger than the shape height. But being ODF conform the ratio viewBoxWidht/viewBoxHeight has to be compared to ratio shapeWidth/shapeHeight. Variable aLogicRect has the size of the shape and variables nCoordWidth and nCoordHeight have the size of viewBox. https://opengrok.libreoffice.org/xref/core/svx/source/customshapes/EnhancedCustomShape2d.cxx?r=0a1bfe1e#690
There are more things wrong than the faulty condition, therefore it might be an easyHack, but not with difficultyBeginner.
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
Rendering is still not ODF conform in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 35b9371acf5a1295ef7c12bbfa285efb7ea4b485 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 A main underlying problem is, that the value of attribute draw:path-stretchpoint-x is not evaluated at all, but only the fact, that the attribute exists is evaluated. More about this problem is in my talk 'Introduction to feature "limo-stretch" of shapes' at LibreOffice Conference 2023 (Milano).