Description: A document contains a frame with a border having roundings in its corners. When loading in Writer the corners are sharp, not rounded. Steps to Reproduce: Load a document with a frame with rounded borders (a sample will be attached) Actual Results: No rounding Expected Results: Rounded borders Reproducible: Always User Profile Reset: No Additional Info: -
Created attachment 160578 [details] Sample file where this behavior appears
Created attachment 160579 [details] Comparison of MSWord vs Writer rendering Look at the blue box in the first page: rounded in Power Point, not rounded in Writer
If I'm not wrong, this have just implemented https://cgit.freedesktop.org/libreoffice/core/commit/?id=5952331844450dad93e21d2e329d51841ae1700e *** This bug has been marked as a duplicate of bug 49247 ***
(In reply to m.a.riosv from comment #3) No, this is about rounded corners, while bug 49247 is about blurry effect on edges.
This is a VML shape v:roundrect with text inside it. Converting to DML in Word makes the rounded shape import correctly.
The borders are rounded after the following commit, but the shape is now smaller than the text box, which is a regression. https://cgit.freedesktop.org/libreoffice/core/commit/?id=bda05ba17362222b74727872579b65b3fa14e3d8 author Regényi Balázs <regenyi.balazs@nisz.hu> 2020-12-01 12:16:12 +0100 committer László Németh <nemeth@numbertext.org> 2020-12-10 10:27:33 +0100 tdf#41466 DOCX import: fix VML v:shape/v:textbox
Created attachment 169741 [details] Rendering it LO 7.1.1 This is what the original sample file looks like in LO Writer 7.1.1. Probably what Aron mentions. Not only is the border too small for the content, but also the rounding seems to have a radius too small.
*** Bug 141658 has been marked as a duplicate of this bug. ***
Dear Alvaro Segura, 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
The problem still exists in Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL threaded The shape is imported as legacy rounded rectangle according to v:roundrect element in the file. But the file has in addition a v:textbox element. Such shape should be imported as drawing object 'text box'. Otherwise the attribute "mso-fit-shape-to-text:t" cannot be translated. The drawing object 'text box' has rounded corners too, so that is not a problem. The radius of the rounding is half as large as it should be.
It seems the description in https://learn.microsoft.com/en-us/windows/win32/vml/msdn-online-vml-arcsize-attribute: "Defines the rounded corners of a rounded rectangle as a percentage of half the smaller dimension of the length and width of a rectangle. 0% would have square corners, and 100% would form circular corners. A square with an ArcSize value of 1.0 would be a circle. The default value is 0.2 (20%)." does not fit to the reality. When the handle in the shape is dragged to its maximum, creating a circular rounding, then MS Office writes arcsize="0.5". So in reality the reference value is not "half the smaller dimension" but the "smaller of height and width".
I just tried the sample document with the latest LO 25.8.3 and the problem persists. The autoshape rectangle is too small vertically (text overflows) and the corners rounding is too small. Now some more info after more analysis: The style says: "width:375.75pt;height:57.35pt" so the size is correct. But in Word the shape has *Adjust size to text* checked, so Word is expanding the shape for the text to fit. The XML indicates <v:textbox style="mso-fit-shape-to-text:t"> and LO seems to ignore this flag. Regarding the rounding, I've learned that the radius (arcsize="6981f" attribute) is expressed as a fraction of the smallest size (height or width). So, if the height was too short then the radius appeared too small. After fixing the height so that the rectangles look the same, the rounding is still a little smaller. The "f" suffix in arcsize means the fraction is scaled by 65536 ("6981f" -> 6981/65536 = 0.106 -> r = 10.6% of height). By comparing Word and LO with different roundings, it appears that LO is making the radius *half of what it should*.
Additional problem is, that the shape gets a text box attached although that is only implemented for custom shapes. But the imported shape is not a custom shape but a legacy rectangle. Thus the textbox is lost, when you save it as odt. And as it is not a text box, the command "Fit height to text" does not exist.