Description: Text layout, multitude an outcomes Steps to Reproduce: 1. Open the attached file 2. Delete the colored paragraph blocks one by one.. from bottom to top 3. Notice how the image is pressed down (when deleting the yellow 4. The Heading gets to first page when deleting purple 5. The heading drops back to second page when select the green 6. How undo everything walks back 7. How redo generates a different result 8. How Save & file reload changes it again (with the cat over the Actual Results: Unpredictable outcome Expected Results: Bit more consistent Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha1+ (x64) Build ID: f9790da286f2d2fa47f1748f8cfa6172c6622ca3 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: de-CH (nl_NL); UI: en-US Calc: CL
Created attachment 160914 [details] Example file
Created attachment 160915 [details] Screencast
@UX-advise Can Image -> Type -> Keep inside text boundaries be ticket by default. It's a major unpredictable layout mess without For the record: the problem is not limited to image, and not limited to anchoring to character. Anchor to paragraph is functioning little better.. but dragging shapes around is far superior to having it not enabled: Expect it's called Follow Text flow (or is this something different compared to Keep inside text boundaries) The only problem right know: bug 113373
Yep, this is what I struggled with for outline folding enhancement https://bugs.documentfoundation.org/show_bug.cgi?id=38093#c73 One thing that seems to work is to not have the text flow attribute 'Keep with next paragraph' set for headings.
Created attachment 160920 [details] Example file without Headings
Created attachment 160922 [details] Example file with chart and keep inside text boundaries on Keep inside text boundaries isn't helpful here. Broken position with or without
I created also a version with a shape(square) object behaviour moving is again different and causing a layout loop.. similar to this bug 133075
@Justin Rather opportunistic: You did few sw layout changes lately .. Any knowledge about the inner workings of anchoring of objects & lay-outing in LibreOffice itself? More interested in some insight; not a straight away bug fix ;-) It appears the the same anchor + same wrap is still able to produce different results depending on object (shape/frame/image/chart etc). Example bug 133075 [In simple World I expect the position of objects to be based on shared code as far as possible. However the behavior suggests otherwise.. ] The issue with images (shown in this bug) can be 'masked' by checking "Keep inside text boundaries". However the trick doesn't work for shapes/frames/charts.. This must be noticeable in MSO import?
See comment 8
Images anchored To Character are expected to stay at the anchor and the relative position (if the character moves left/right you want the image to stay at the same position). It's definitely not expected that anchor moves when paragraphs somewhere else are deleted.
Dear Telesto, 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
Still repro Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: 62531ec1091c7b3f6a3577889a18234790ec716d CPU threads: 8; OS: Mac OS X 12.3.1; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
(In reply to Heiko Tietze from comment #10) > Images anchored To Character are expected to stay at the anchor and the > relative position (if the character moves left/right you want the image to > stay at the same position). It's definitely not expected that anchor moves > when paragraphs somewhere else are deleted. If you delete the highlighted block in pieces the text will shift down (so first yellow, next red, next green). If you delete it at once it will look different. It also isn't restored on save and reload
Bug summary says "Anchor to Character is not persistent" What does that mean in the context of the example? I think you are not satisfied with the image positioning, but you do not specify what you are expecting or trying to do. Maybe you should be try ask.libreoffice.org first? Otherwise -- for example -- change your Vertical position setting to: Center to Character and see what happens. ("to character" anchor by itself does not control positioning. There are many variations and possibilities in the options, so this must also be specified. The "chaos" you report may simply be a misunderstanding of the operation of those options.
Is the problem here that "to Margin" behaves as if it were "to Paragraph text area"? This is only a bug of documentation, that doesn't clearly explain what "Margin" in vertical positioning means for "to character" anchoring [1]. Namely, it tells: > * Margin: Depending on the anchoring type, the object is positioned considering the space between the top margin and the character ("To character" anchoring) ... The "top margin of what" is not explained here. In fact, the "Margin" in the UI corresponds to ODF's 'style:vertical-rel="paragraph"' (as opposed to 'style:vertical-rel="paragraph-content"' for "Paragraph text area"; see [2]). Both "Margin" and "Paragraph text area" mean "relative to paragraph" - just to different points of the paragraph: for text area, that excludes the paragraph's borders and padding. This works as designed, completely correctly as far as I see it. Possibly it would benefit from the "Margin" being renamed to "Paragraph area" or "Complete paragraph area" ... [1] https://help.libreoffice.org/7.3/en-US/text/swriter/01/05060100.html?DbPAR=WRITER#bm_id1466719 [2] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3-schema.html#property-style_vertical-rel
One edge case might still be considered a bug: when the anchor character needed to get to the previous page, but the image couldn't then fit to that previous page, thus preventing the move of the line to the previous page. In that case, the expected outcome would be all the previous lines of the paragraph to stay on the previous page, the line with anchor stay on the next page, and simply some white space appear in the bottom of the previous page. The actual result (the bug IMO) currently is that in this case, the *whole paragraph* jumps to the next page, and stays there until there's room on the previous page to accommodate the image. I'd say, to make it clean, the latter issue needs an own bug report, and there it would need a check if that was always so, or if it is a regression.
(In reply to Mike Kaganski from comment #15) > Is the problem here that "to Margin" behaves as if it were "to Paragraph > text area"? > This is only a bug of documentation, It does behave in that way if there is no border and padding in the paragraph, which seems to be the case in the test attachments. But I agree that the documentation for Margin needs improvements. > > * Margin: Depending on the anchoring type, afaict -- there is no difference in the vertical positioning with "To Paragraph" and "To Character" (at least in my tests). Do you know a case where they are different? > The "top margin of what" is not explained here. If the "dependency" in anchoring type can be dropped, then "Margin" can be explained as: between top and bottom edges [or borders] of paragraph where anchor is located. > Possibly ... "Margin" being renamed to "Paragraph area" or > "Complete paragraph area" ... Good idea. Propose: "Entire paragraph" (to be parallel with "Entire Page" and "Entire Frame")
(In reply to Mike Kaganski from comment #16) > One edge case might still be considered a bug: when the anchor character > needed to get to the previous page, but the image couldn't then fit to that > previous page, thus preventing the move of the line to the previous page. In > that case, the expected outcome would be all the previous lines of the > paragraph to stay on the previous page, the line with anchor stay on the > next page, and simply some white space appear in the bottom of the previous > page. The actual result (the bug IMO) currently is that in this case, the > *whole paragraph* jumps to the next page, and stays there until there's room > on the previous page to accommodate the image. > > I'd say, to make it clean, the latter issue needs an own bug report, and > there it would need a check if that was always so, or if it is a regression. I moved it to bug 149241. Not sure if the title is adequate, feel free to modify.
(In reply to sdc.blanco from comment #17) > > > * Margin: Depending on the anchoring type, > afaict -- there is no difference in the vertical positioning with "To > Paragraph" and "To Character" (at least in my tests). Do you know a case > where they are different? Unfortunately I don't know, and can't read the related code at the moment. But I assume that you are correct, and it should be simply unified. I'd suggest to do the change. > Propose: > > "Entire paragraph" (to be parallel with "Entire Page" and "Entire Frame") +1
(In reply to Mike Kaganski from comment #19) > (In reply to sdc.blanco from comment #17) > > Propose: > > > > "Entire paragraph" (to be parallel with "Entire Page" and "Entire Frame") > > +1 Bug 149252