Bug 131253 - Frames are displayed around images even though Object boundaries is unchecked, as Text boundaries control it
Summary: Frames are displayed around images even though Object boundaries is unchecked...
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All All
: medium normal
Assignee: Heiko Tietze
URL: https://ask.libreoffice.org/en/questi...
Whiteboard: target:25.2.0
Keywords:
: 141081 (view as bug list)
Depends on:
Blocks: Frame
  Show dependency treegraph
 
Reported: 2020-03-10 11:34 UTC by MGA
Modified: 2024-11-08 13:30 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
131253_through.docx: wrap none/through images shouldn't display a text boundary line (51.86 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2024-03-25 19:39 UTC, Justin L
Details
131253_through2.docx: text boundary should be applied to wrap-through frames that contain text (6.16 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2024-03-27 13:59 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MGA 2020-03-10 11:34:47 UTC
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.
Comment 1 Dieter 2020-03-11 16:59:02 UTC
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.
Comment 2 eisa01 2020-05-02 17:04:34 UTC
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
Comment 3 Heiko Tietze 2020-05-04 13:22:49 UTC
Whether object or not, the text ends here. And the point is, View > Text Boundary disables the thin grey lines => NAB.
Comment 4 Justin L 2024-03-25 14:09:49 UTC
*** Bug 141081 has been marked as a duplicate of this bug. ***
Comment 5 Justin L 2024-03-25 19:39:12 UTC
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.
Comment 6 Heiko Tietze 2024-03-26 09:14:43 UTC
(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.
Comment 7 Commit Notification 2024-03-26 12:30:04 UTC
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.
Comment 8 Justin L 2024-03-26 13:42:35 UTC
(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.
Comment 9 Justin L 2024-03-26 15:14:57 UTC
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.)
Comment 10 Justin L 2024-03-27 13:59:01 UTC
Created attachment 193348 [details]
131253_through2.docx: text boundary should be applied to wrap-through frames that contain text
Comment 11 Commit Notification 2024-03-27 17:49:37 UTC
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.
Comment 12 lomacar 2024-10-28 20:59:45 UTC
Well, Justin's patch was a bad "solution" and now LibreOffice is broken. (bug 163537) Why was this patch ever accepted?

This solution makes no sense. So, there are apparently a couple problems with image boundaries. 

1. They should be controlled by Application Colors> Object Boundaries, but that has no effect.
2. They actually never display correctly, as per bug 134869

So rather than fixing 1 and 2, we now have an even more convoluted situation where, in order to see the buggy, barely sometimes visible borders you have to have Text Boundaries AND Formatting Marks turned on?!?! This boggles my mind. This is mixing up categories like crazy. Image boundaries are not text boundaries, any boundaries are certainly not formatting marks, and nothing should require two (or three!) option to be turned on in order to see it.

An exception I would make to my last point is if there was one toggle to show boundaries, and then toggling on and off certain types of boundaries was clearly presented in the UI as a set of sub-options.

Please revert this patch and just fix 1 and 2.
Comment 13 Heiko Tietze 2024-10-31 12:26:40 UTC
Patch for bug 163537 should solve this too.
Comment 14 Commit Notification 2024-10-31 15:15:55 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1a5b1552d8cee042466fc4c4ae5383c0ffbeb194

Resolves tdf#163537 && tdf#131253 - Make Boundaries independent from NPC

It will be available in 25.2.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.
Comment 15 Heiko Tietze 2024-10-31 15:21:12 UTC
The boundaries are now independent from each other. Missing piece is easy access to "object boundaries", right now you need to toggle it per tools > options > application colors. I'm working on a solution for this.

Please test the patch carefully. The code is quite spaghettily.
Comment 16 Justin L 2024-11-04 13:29:50 UTC
(In reply to Heiko Tietze from comment #15)
> The boundaries are now independent from each other.
The "text boundary" on the page margins seems to be fully on all the time now - that will not make people happy at all.

In theory, BOTH object boundaries AND text boundaries should be able to turn on the lines. After all, an object is both an object, and implements text wrapping properties. So I submit that when "View Formatting" is turned on, then the "text boundaries" lines around wrapped objects should become visible - just like it does for the page margin.

> Missing piece is easy access to "object boundaries"
The problem currently is that "object boundaries" is enabled by default. View - Boundaries around images should not be enabled by default, and hopefully that is how you are designing this missing piece.
Comment 17 Heiko Tietze 2024-11-04 13:35:54 UTC
(In reply to Justin L from comment #16)
> (In reply to Heiko Tietze from comment #15)
> > The boundaries are now independent from each other.
> The "text boundary" on the page margins seems to be fully on all the time
> now - that will not make people happy at all.
View > Text Boundary on/off should work (change full vs. crop mark per options > formatting aids, if enabled)

> In theory, BOTH object boundaries AND text boundaries should be able to turn
> on the lines. After all, an object is both an object, and implements text
> wrapping properties.
I aimed for exclusive settings. Text is text and objects are something else. It's easy to enable both but impossible the other way if internally combined.

>> Missing piece is easy access to "object boundaries"
> The problem currently is that "object boundaries" is enabled by default.
> View - Boundaries around images should not be enabled by default...
Yes. My patch https://gerrit.libreoffice.org/c/core/+/175870 adds the option to the menu, but is not working for some reason.
Comment 18 Commit Notification 2024-11-08 10:53:15 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-24-8":

https://git.libreoffice.org/core/commit/12fa0ecad4c9182c811236e8d90782741a21625a

tdf#163537 Revert "tdf#131253 sw: draw frame text boundary

It will be available in 24.8.4.

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.
Comment 19 Commit Notification 2024-11-08 13:23:52 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-24-8-3":

https://git.libreoffice.org/core/commit/cfa763a408366d84a49285fe312409945a7d33a2

tdf#163537 Revert "tdf#131253 sw: draw frame text boundary

It will be available in 24.8.3.

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.
Comment 20 Justin L 2024-11-08 13:30:11 UTC
Comment 7's patch was reverted to avoid UI churn, since bigger changes are being worked on in 25.2. This bug will need to be revisited at the end of 25.2.