Created attachment 180571 [details] Examples of lines and shadows going past positioning region The attachment demonstrates the problem. Basic issue. For shapes, it is possible to add a "line" or a "shadow" For images, it is possible to add a "border" or a "shadow" Actual: When positioning shapes and images, which are anchored "to paragraph" and positioned horizontally with Horizontal: Left to: Entire Paragraph Area (or Paragraph Text Area), then line and shadow for shape are positioned outside of the Entire Paragraph Area/Paragraph Text Area while for images, they are "inside". Expected: Images and Shapes behave the same. Expected: Shapes would follow the behavior of Images. Question: Is this difference in behavior by design, in which case this ticket is a documentation report, or is this an implementation bug? Additional information: The attachment only looked at "Left" and "Entire Paragraph Area" and "Paragraph Text Area". There are many other variations that could be checked, but there are enough examples in the attachment to show that there is an issue. Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: bbec710bd25fc5da27636cde73fe4ab23c76904f CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL
Reason is, that Writer images are treated as frames and not as shapes. This has a lot of other consequences too, see https://wiki.documentfoundation.org/Development/Budget2022#Unify_Writer_and_Draw_Images The border problem is already tracked in bug 90070. I do not find a similar report for shadow. Therefore I suggest to take this report for the shadow problem.
see also discussion https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00486.html
(In reply to Regina Henschel from comment #1) > The border problem is already tracked in bug 90070. But 90070 is about "image shrinking" when a border is added. comment 1 and comment 2 imply that the intention is to make "Shape" (Draw-Image) be the "default" (expected) behavior. In relation to the OP -- the issue is about positioning (not shrinking). I would consider "Shape" (Draw-Image) to "violate" the positioning dialog, because it places "Line" and "Shadow" outside of the positioning regions. Have now also tested/confirmed same problem with: Horizontal: Left to: {Page text area, Entire page} This issue is especially visible with "to: Entire page" because the line (on the left side of the shape) and the shadow (on the left side) are not shown on the canvas. Have made bug summary more general.
Maybe bug 90070 is not the same but essentially asks for exactly the opposite. If you expect borders and shadows to become cut off at the area boundary it would be the same for borders around the object. And as always, we wont make everybody happy. To me the implemented solution is more natural and easier to deal with (you can cover the extended objects). My take => NAB/DUP (removing the confirmation for now)
(In reply to Heiko Tietze from comment #4) > As always, we wont make everybody happy. fwiw, the OP is not promoting any particular solution, just noting a difference between Shapes (Draw-Images) and Frames (Writer-Images), and suggesting either consistency or a good documented reason for the difference in positioning behavior. > To me the implemented solution > is more natural and easier to deal with (you can cover the extended objects). Two or more different issues may be conflated here -- so just to lay them out a little more explicitly. Issue 1. Whether a shape/image is shrunk when it is positioned at the edge of a region AND a border is added. (n.b., bug 90070 is about image, where, iiuc, it does not necessarily have to shrink, so that issue could be addressed independently of the OP here (by not shrinking the image). (comment 4 seems to imply that shape should not get the shrinking behavior, with which I agree.) Issue 2. Whether the line and shadow of a shape should be positioned within the region selected in the Position and Size dialog (independent of shrinking). (comment 4 does not address that issue).
Topic was on the agenda of the design meeting but didn't receive further input. Writer images are treated as frames and not as shapes, which is unfortunate. Let's keep this ticket open for reference.
Dear sdc.blanco, 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