Description: Even after unchecking "Object boundaries" in LibreOffice > Preferences > LibreOffice > Application Colors > Custom Colors > General, thin frames are displayed around images. Steps to Reproduce: 1. Paste an image in a Writer document Actual Results: Image is shown, but with a thin gray frame around it Expected Results: The image, but without the frame Reproducible: Always User Profile Reset: No Additional Info: This issue was talked about here but not fixed: https://ask.libreoffice.org/en/question/71487/unwanted-gray-border-showing-up-around-images/ They just make the frames white, but that's not the same as no frame when images overlap.
I can't confirm it with Version: 7.0.0.0.alpha0+ (x64) Build ID: eeb2d19e77d6dc47c68e8ba0920a02cf64a1247b CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-GB Calc: threaded Could you please add a screenshot to make the problem more visible? Thanks.
I can confirm this, however it's because the setting that controls this is the "text boundaries" I would have thought images are rather an "object" rather than text, so I can see why this is confusing. Maybe "text boundaries" should be changed to "text and image boundaries"? I'll let the UX team decide if this should be kept open or closed
Whether object or not, the text ends here. And the point is, View > Text Boundary disables the thin grey lines => NAB.
*** Bug 141081 has been marked as a duplicate of this bug. ***
Created attachment 193300 [details] 131253_through.docx: wrap none/through images shouldn't display a text boundary line (In reply to Heiko Tietze from comment #3) > Whether object or not, the text ends here. And the point is, View > Text > Boundary disables the thin grey lines => NAB. The text does not "end here" if the frame is wrap through (or wrap none). Note that the page's text boundaries are also not (fully) boxed in (when "show formatting marks" is turned off), just a few angle brackets are shown. It is EXTREMELY disconcerting to the user to have a border around their image, and even more so since it does not work consistently (bug 134869). I propose that the frame's "text boundaries" should only show when formatting marks are turned on.
(In reply to Justin L from comment #5) > I propose that the frame's "text boundaries" should only show when formatting > marks are turned on. You mean to AND combine two options? Would be quite surprising for users.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5bf7df62645f73ad69772f318ea3058dfd6fce12 tdf#131253 sw: draw frame text boundary on when show formatting marks It will be available in 24.8.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.
(In reply to Heiko Tietze from comment #6) > You mean to AND combine two options? Would be quite surprising for users. Why do you think that would be surprising for users. I already stated that this exact combining of two options happens with the page boundary, which is very noticeable. What is surprising to the user is that the same control that controls the essential body text/header/footer indicators also draws a border around their typically borderless images. A user would almost never want to lose the body/header/footer indicators, but they would almost always want to lose that fake image border. Additionally, because that fake border basically has never worked anyway (bug 134869), users aren't going to have any idea of the purpose of a frame's "text boundary". It was only your comment 3 that clued me in to the value of it. (Of course, the implementation didn't consider that wrap-through frames don't have "text stopping here" and was drawing the boundary line anyway, once again blurring the meaning/intent of the option.) In short, NOTHING about the prior situation was unsurprising, or useful, but rather it was simply infuriating. Comment 7's patch should be a good start to addressing the primary concern of the 5 bug reports (2 here, 3 on the essentially duplicate bug 134869) while still allowing that extremely tiny minority who actually find value in the fake border to have access to the broken implementation. For me personally, if I had any question as to why text flowed around an image a certain way, I would logically click on the image itself and use the image handles to identify the full picture size.
bug 134869 comment 11 indicates that these fake borders became visible on floating frames starting with LO 6.0. In OOo, it seems like (only) as-character frames showed the boundaries. "Text boundaries" didn't toggle this on or off, so it was always showing. (The toggle was fixed in 3.5.0.)
Created attachment 193348 [details] 131253_through2.docx: text boundary should be applied to wrap-through frames that contain text
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c51f9f15b8c308e62b4839cc13d623fdab0486c2 tdf#131253 sw: draw frame text boundary if fly has textframe It will be available in 24.8.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.