Description: Frame boundaries for borderless frames could previously have their visibility toggled with the View > Text Boundaries option. Now they can only be seen when View > Formatting Marks is turned on. This is wrong. Steps to Reproduce: 1.Create a text frame without borders. Actual Results: If Formatting Marks is turned off under the View menu, you can't see the boundaries of the text frame. Expected Results: I would expect to be able to toggle the boundary visibility using View > Text Boundaries! Reproducible: Always User Profile Reset: No Additional Info: I can't imagine why this change was made. Conceptually, frame boundaries and text boundaries are more related than formatting marks. What is even the purpose of the Text Boundaries toggle at this point? By default I want to be able to view frame boundaries without seeing formatting marks. It is much less common to need to view formatting marks.
In fact the View -> Text Boundaries toggle control remains effective. But yes at 24.8 as with other UI elements it has now been linked to the NPC/Formatting marks toggle [1] The "text boundaries" are a formatting/layout mark--not a printable WYSIWYG and they belong with the "Pilcrow" tb button or <Ctrl>+F10. IMHO done correctly now, but not sure it was intentional. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/166033
Formatting Marks should not affect Text, Table, and Section Boundaries. It works for tables but not text (and frames), and both text and section also depend on this option by having either a frame around the entire object or just some indicator at the corner.
(In reply to Heiko Tietze from comment #2) > Formatting Marks should not affect Text, Table, and Section Boundaries. It > works for tables but not text (and frames), and both text and section also > depend on this option by having either a frame around the entire object or > just some indicator at the corner. Heiko, not sure I follow. There is a distinction between text, table, section and frame "boundaries" that are all layout marks, and so *only* visible while authoring, compared to what are styled "borders", that may be coincident to the boundaries, but will actually be published/printed with the document. Clearly all these "boundaries" marks should toggle with other NPC/formatting marks, when set visible from the View menu (though there should probably also be entries on the Tools -> Options panels for respective modules). While the "borders" are not at issue and are otherwise controlled in UI. Do note that the Table "boundaries" remain fully drawn, but probably should shift to corner marks, like the section and page layout marks, when the NPC/formatting marks are toggled.
View > [x] Formatting Marks + Options > Writer > Formatting Aids > Paragraph end => shows the pilcrow View > [x] Formatting Marks + Options > Writer > Formatting Aids > Breaks => shows the soft line break etc. View > [x] Table Boundaries => shows the table (if border is set to none) View > [x] Text Boundaries + View > [x] Formatting Marks => shows text/frame border (also via Application Colors) Boundaries are no formatting marks, and if they were we would have to make this dependency clear by eg. disabling the sub-items.
Created attachment 197173 [details] sample doc, various boundary types to toggle NPC
Created attachment 197175 [details] screen capture of boundary toggle with <Ctrl>+F10 Seems clear they are formatting/layout marks and should toggle with other NPC. The Table boundary should probably go to corner marks. Not sure why but the View -> Section boundaries seems to be non-functional, though the section view does toggle.
(In reply to V Stuart Foote from comment #6) > > Seems clear they are formatting/layout marks and should toggle with other > NPC. > I disagree. Formatting marks are not useful for people like me (in fact, I find them distracting): I only use styles and set Writer to ignore double spaces, spaces and tabs at the beginning/end of line, etc., so there is no need for me to keep an eye on markers for spaces or tabs or all the other stuff gathered under the pilcrow (they are correct the whole time). But I always need to know where the boundaries of borderless objects such a frames, etc, are, if the picture I just dropped is not going beyond the margins, etc. For my user case all those blue dots and arrows are useless most of the time, but the boundaries of objects are always important.
V Stuart, try thinking about it as a human actually using the software in production. I think RGB has described it well. Users absolutely need a way to view boundaries without formatting marks during normal editing. Sometimes it is nice to turn of the boundary visibility to have a cleaner view of how the output result will look. Formatting marks generally only need to be turned on when there is some crazy formatting issue like an invisible formatting character or maybe when you need to check a document for use of tabs versus spaces. Everything was working fine in every previous version of LibreOffice and OpenOffice, now it is broken.
This was introduced for bug 131253 by Justin with the comment // particularly with images (but also plausible for any kind of frame), // it is very disconcerting to see a fake border, // so (just like the page boundary) only show fly "text boundaries" // when "Show Formatting Marks" is turned on if (!gProp.pSGlobalShell->GetViewOptions()->IsViewMetaChars()) return; With or without this line, the behavior is not satisfactory. My expectation is to have * non-printable characters controlling single glyphs only, fine-tuned via tools > options > formatting aids * structuring elements (internally called subsidarylines) switch on/off per view menu, and I would distinguish between objects (charts, images...), sections & frames, tables, and text boundaries Section boundaries has no effect at all, and switches on/off with text boundaries (I could live with this generalization but we'd have to remove the command then), objects such as graphics also follow text boundaries. And all together the non-printable option.
Oh dear, yes, this is a bigger problem because it affects page boundaries too. Meanwhile section boundaries and table boundaries are not affected by this bug. To me it makes no difference if frames, section boundaries and page boundaries are all considered "text boundaries". That is logical.
(In reply to RGB from comment #7) (In reply to lomacar from comment #8) (In reply to Heiko Tietze from comment #9) > This was introduced for bug 131253 by Justin with the comment > Nope. Reviewing bug 131253 and commit [1], Justin's logic was sound and *was* well reviewed. It explicitly addressed the non-printing visual aids being placed around frames of inserted images. Disagree with Heiko's take, NPC has not controlled just single glyph markers since the 3.6 release (where it already toggles between showing the page margin corner marks and full margin lines), and at 5.0 release its labeling in UI changed from 'Non-printing Characters' to 'Formatting Marks' [2] to better reflect its scope. Still room for additional effort for user configuration of controls (tb button|menu|module options)--but having the "subsidiarylines" toggle with 'Toggle Formatting Marks' (.uno:ControlCodes) is functional and suited to task. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/165294 [2] https://gerrit.libreoffice.org/c/core/+/28742
(In reply to V Stuart Foote from comment #11) > (In reply to RGB from comment #7) > (In reply to lomacar from comment #8) > (In reply to Heiko Tietze from comment #9) > > This was introduced for bug 131253 by Justin with the comment > > > > Nope. Reviewing bug 131253 and commit [1], Justin's logic was sound and > *was* well reviewed. > > It explicitly addressed the non-printing visual aids being placed around > frames of inserted images. > > Disagree with Heiko's take, NPC has not controlled just single glyph markers > since the 3.6 release (where it already toggles between showing the page > margin corner marks and full margin lines), and at 5.0 release its labeling > in UI changed from 'Non-printing Characters' to 'Formatting Marks' [2] to > better reflect its scope. > > Still room for additional effort for user configuration of controls (tb > button|menu|module options)--but having the "subsidiarylines" toggle with > 'Toggle Formatting Marks' (.uno:ControlCodes) is functional and suited to > task. > > > =-ref-= > [1] https://gerrit.libreoffice.org/c/core/+/165294 > [2] https://gerrit.libreoffice.org/c/core/+/28742 I couldn't disagree more. This is a major issue to how I and many others work. There absolutely must be a way to toggle Non-printing Characters separately from boundaries. They way it worked before was fine! Why change it? There was no reason to do so. And it's a stupid idea to require users to turn on two options in order to see something. How is the average user supposed to figure that out? Especially when one of the options is so unintuitive? When someone turns on View > Text Boundaries, they expect to see text boundaries! Formatting marks should be changed back to Non-printing characters. Why was that even changed? Why do the page boundaries change with that option? That also feels like a bug. No other software ties non-printing characters together with boundaries or guides or grids or any kinds of lines. The major difference between these things is that Non-printing characters can change the flow of the document because they are actually characters in the text. This must be treated separately from lines that control the flow of text. As I said before, it is rare that anyone ever needs to look at non-printing characters, but it is normal that people need to see boundary lines. If this isn't fixed I am going to have to downgrade LibreOffice and never upgrade again. How do these decisions get made? To me it's an obvious bug, but let's put it to a vote somewhere if we have to.
Related to this issue, a 10+ years old report: Bug 74386 UI: Provide obvious way to turn full-page text boundaries on/off, independent from Show non printing characters
Took the liberty to submit a patch meanwhile.
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.
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.
View - Formattings Marks disabled - I can see the borderless frame (both with full or Crop marks activated). Verified with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1a5b1552d8cee042466fc4c4ae5383c0ffbeb194 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded It was not like this in 24.8, when disabling Formattings Marks is hiding the borderless frame. Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
(In reply to RGB from comment #13) > Bug 74386 > UI: Provide obvious way to turn full-page text boundaries on/off, > independent from Show non printing characters I don't think I would have any problems with "text boundaries" drawing appropriately scaled crop marks / rectangle delimiters around pictures - just like the page margins. (In reply to RGB from comment #7) > I always need to know where the boundaries of borderless objects such a > frames, etc, are, if the picture I just dropped is not going beyond the > margins, etc. And wouldn't you need to have the page margin lines visible to do that with any precision? And why wouldn't the picture-content itself provide that information (unless the picture is transparent at the edges, in which case I don't understand why it would be a problem to go beyond the margin...) [These are genuine questions - I'm not trying to be argumentative.] Oh, I think I understand. You are not talking about the page margin or about the boundary around the picture itself, but the text boundary inside a separate, non-textbox, frame-that-will-contain-text, and you don't want the picture to overlap that other frame. So you are not worried about an external-object-boundary, but an internal-text-boundary (that shows up inside the frame's border).
Created attachment 197398 [details] textBoundaries.odt: text-containing flies should normally show text boundary Instead of Heiko's patches, this one would probably also resolve this bug (assuming that comment 18 captures the heart of the complaint). Thanks to RGB for describing his use case. As always, a sample document would have been helpful as well... https://gerrit.libreoffice.org/c/core/+/176014
Created attachment 197427 [details] Example file (In reply to Justin L from comment #19) > Instead of Heiko's patches, this one would probably also resolve this bug... Your patch makes the frame follow text boundaries (and essentially the app color obsolete). I'm not against this solution (and drop the additional toggle option). What I dislike at your patch is the incomplete separation as app color > object changes the appearance for frames (and potentially combines the two toggles if the merge conflict is solved).
(In reply to Heiko Tietze from comment #20) > Your patch makes the frame follow text boundaries My comment 19 patch basically returns LO to working the way it always have. > What I dislike at your patch What you dislike about the way LO has been working so far is... I'm not really in favour of making major changes in this area as it certainly will trigger angry responses (just like this bug report did to my comment 9 patch). But you are the UI guy, so if you follow through on the separation of text boundaries and NPC, then I will just revert comment 9's patch in 24.8.
(In reply to Justin L from comment #21) > I'm not really in favour of making major changes in this area as it > certainly will trigger angry responses... Let's see how this is accepted by the community. If we receive a lot of complaints it's easy to revert. But how about removing the object boundaries option completely?
(In reply to Heiko Tietze from comment #22) > But how about removing the object boundaries option completely? If you are asking about completely getting rid of text boundaries around images, that would be very bad for images with transparent backgrounds/edges (like in comment 19's example).
(In reply to Justin L from comment #23) > (In reply to Heiko Tietze from comment #22) > > But how about removing the object boundaries option completely? > If you are asking about completely getting rid of text boundaries around > images, that would be very bad for images with transparent backgrounds/edges > (like in comment 19's example). I see _object_ boundaries around frames, in addition to text boundaries. Other types of objects are not affected by the option, AFAICS.
(In reply to Heiko Tietze from comment #22) > But how about removing the object boundaries option completely? Rough patch at https://gerrit.libreoffice.org/c/core/+/176242
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.
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.