https://bugs.documentfoundation.org/show_bug.cgi?id=131253
--- Comment #8 from Justin L <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug.
