Description: By default, style TextBody includes no page break. Put one in (Format>parag>TextFlow>Breaks, Insert). Then, hit ^m (ClearDirectFormatting); page break stays. Why? Steps to Reproduce: 1.In a parag TextBody, insert a page break 2.hit ^m (ClearDirectFormatting) 3. Actual Results: page break stays Expected Results: page break should go since it does not belong to the style. Reproducible: Always User Profile Reset: No Additional Info: none
Clear _direct_ formatting does nothing but to remove formats like font weight, size, and color. It's a bit unclear what you mean with "style TextBody includes no page break" but given it's a direct formatting to the paragraph style (context menu > paragraph > paragraph...) this is not direct formatting. There should be a duplicate ticket requesting clear direct formatting to also clear direct paragraph formats but cannot find it, closest are bug 71233 and bug 78371. Mike, any idea? Why should one add a page break after/before text body?
(In reply to Heiko Tietze from comment #1) > Clear _direct_ formatting does nothing but to remove formats like font > weight, size, and color. It's a bit unclear what you mean with "style > TextBody includes no page break" ** In the styles list, right-click TextBody, choose Modify>TextFlow, Breaks: Insert is NOT checked —at least, after a fresh installation of LO. Try the converse with style Heading1: Check TextFlow, Breaks: Insert PageBreak; apply ^1 to any text, make it a Heading1: new page; format it, uncheck Breaks: PageBreak disappears; ^m restores the PageBreak. > Why should one add a page break after/before text body? **before. Because the text contains a frame which does not fit in the current page, and LO has trouble displaying it. The page break moves text and frame to a new page.
This obviously *is* direct formatting, and I bet there was some explicit processing for page breaks not removed when clearing the direct formatting from paragraphs. Of course we need to look into the code to be absolutely sure, but it's my gut feeling, that this is a "feature" targeted on inexperienced users coming from MS Office, and who are not used to the idea that page break is a property of paragraphs. Personally I would thing that a configuration would be useful for this, to allow more complete clearing of direct formatting.
(In reply to Mike Kaganski from comment #3) > Personally I would thing that a configuration would be useful for this, to > allow more complete clearing of direct formatting. Something like Paste vs. Paste Special? Clear DF v - Clear Character Format Clear All Formatting Special Clear... And special clear allows to [ ] All Character Formats [ ] Font [ ] Font effects [ ] Position [ ] Highlighting [ ] All Paragraph Formats [ ] Alignment [ ] Indents and Spacing [ ] Text flow [ ] Background (using the property dialogs as basis; "All" disabled the other options)
(In reply to Heiko Tietze from comment #4) Well, I don't think we need that complexity. Just some Options section with checkboxes, that controls what Clear DF does for this user. I don't think we need levels of the feature available at any given moment. If a user is not OK with the "helpful" precaution that we have for inexperienced users, there would be no problem for this user to have manual page breaks always cleared at every Clear DF invocation IMO.
(In reply to Mike Kaganski from comment #5) > (In reply to Heiko Tietze from comment #4) And also we should not add things here, like allowing to not clear something that is cleared now by that function. Only provide checkbox(es) for thing(s) that are *currently* excluded from the function.
(In reply to Heiko Tietze from comment #1) > Clear _direct_ formatting does nothing but to remove formats like font > weight, size, and color. No, clear direct formatting not only remove character formatting but also paragraph formatting like text alignment > Why should one add a page break after/before text body? Because it's a good feature to have to separate long and outstanding paragraphs that spans almost over the entire page (In reply to Mike Kaganski from comment #3) >This obviously *is* direct formatting, and I bet there was some explicit processing >for page breaks not removed when clearing the direct formatting from >paragraphs. Of course we need to look into the code to be absolutely sure, but it's >my gut feeling, that this is a "feature" targeted on inexperienced users coming >from MS Office, and who are not used to the idea that page break is a property of >paragraphs. That is more than just non-sense! LibreOffice is a stand alone office suite with it's own features, behaviour and even remarkable visual efforts of branding! And the users have to bare with this! No user would be helped by keeping a page-brake that is applied to a paragraph when he clears all formatting for this paragraph as no user is been helped when he wants to remove a page-break while he doesn't understand that it is a paragraph formatting. Learning the application is the key! (In reply to Heiko Tietze from comment #4) >Something like Paste vs. Paste Special? >[ ] All Character Formats >[ ] Font >[ ] Font effects >[ ] Position >[ ] Highlighting This is even more non-sense! First the OpenDocument Format allows advanced formatting, than LibreOffice makes exceptions for users of other applications, than we scatter the UI and force the users to mark 10 checkboxes for using a function that is mean to be basic? CLEAR ALL FORMATTING should clear ALL formatting, simple as this! (In reply to TorrAB from comment #0) >Expected Results: >page break should go since it does not belong to the style. I agree with the opener, page-break applied to paragraphs should be removed by clearing the direct formatting
(In reply to Sascha Z from comment #7) > (In reply to Mike Kaganski from comment #3) > That is more than just non-sense! LibreOffice is a stand alone office suite ... There is no "non-sense" when you talk about user experience. You may think that something is (il)logical from some perspective, but please try to accept that there is more than one possible point of view, and there is more than one group of users of LibreOffice in the world. While I would *personally* like to have "Clear DF" to remove every bit of DF from selection, I know and accept that there are *sufficiently many* users who *want* something that I dislike, and that demand *often* warrants the presence of those things in the programs. E.g., I believe myself rather advanced user, and as such, I *possibly* could advocate changing LO to *remove* DF as a concept from LO (based on "I can live without it; it makes LO inconsistent, and its documents hard to maintain when exchanging with users who use DF, etc., etc..."). But instead I am blocking any attempt to make basic users' LO experience worse (which is suggested now and then by those ex-basic users, e.g. who believe that they know how to fuse DF and style together), because basic users are not second-class users. Similarly, users who migrate to LO are not second-class users. And until their expectations are not impossible in LibreOffice's paradigm, their wishes are just as important as anyone else's. It's just a matter of an option to be "strict". It would not hurt anyone.
Core pointers: The entry points for "Clear DF" for Writer are: SwAnnotationShell::Exec in sw/source/uibase/shells/annotsh.cxx SwDrawTextShell::ExecDraw in sw/source/uibase/shells/drwtxtsh.cxx SwTextShell::Execute in sw/source/uibase/shells/textsh1.cxx (look for FN_FORMAT_RESET in all three) The last one is relevant for text. In SwTextShell::Execute, #i78856 and tdf#40496 are handled, excluding language attributes and writing direction. In SwDoc::ResetAttrs (sw/source/core/doc/docfmt.cxx), which does the actual work, additional things are excluded (e.g., see "not including META here" comment). Lastly, lcl_RstAttr excludes more, e.g. RES_PAGEDESC and RES_BREAK that define page break and its style, and also numbering rules. Note that SwDoc::ResetAttrs is used not only in .uno:ResetAttributes, so handle with care.
To add complexity to the matter, the page break formatting attribute can also be set by using Insert > Page Break (Insert menu, not Format menu). Also, they can be removed by either pressing Backspace with the cursor after the page break or Delete with the cursor before the page break. This make page breaks seem like they are inserted objects as opposed to a formatting attribute. Think that formatting attributes like "align left" or "bold" can't typically be erased by pressing Backspace or Delete. So, internally (content.xml), page breaks are a formatting attribute, but the UI currently offers them under two concepts: as a formatting attribute (Styles, Format > Paragraph...) but also as objects (Insert > Page Break, backspace/delete). Both map to the same thing. For users that think of them as objects and not as formatting attributes it would be unexpected to have Clear Direct Formatting erase them; much more if they don't use Styles. This just means that, unfortunately, whatever decision is made will break the expectation of a different set of users.
(In reply to Octavio Alvarez from comment #10) > To add complexity to the matter, the page break formatting attribute can > also be set by using Insert > Page Break (Insert menu, not Format menu). Made this mistake myself when asking why setting page break on text body would be required ;-). IMO a very good reason to not include page breaks in Clear DF.
(In reply to Octavio Alvarez from comment #10) > To add complexity to the matter, the page break formatting attribute can > also be set by using Insert > Page Break (Insert menu, not Format menu). > Also, they can be removed by either pressing Backspace with the cursor after > the page break or Delete with the cursor before the page break. This make > page breaks seem like they are inserted objects as opposed to a formatting > attribute. Only to note - I vented my opinion few times earlier - and obviously the same objection thrown in (existing users).. Anyhow.. Still not big fan of page breaks being a formatting attribute of a paragraph. You copy it around incidentally (bug number on request) with all fuzz related to it. Causes page breaks being in the paragraph dialog (which not obvious place too look, if you're not seeing it as formatting attribute but as object You get discussion as 'clear formatting marks'. TorrAB request is valid, based on the conception of page breaks being formatting attribute :-). The current implementation is kind of weird compromise build on to different concepts; because of people not able to choose. There are few more of those around. It's my world or/or. As for both sides have valid points. The initial reporter as people who object. And instead of consistent experience you get the flip-flop inconsistency to keep up the (evil) compromise. It's now not it on both ends. It behaviour doesn't meet the exceptions of either design. And that's even worse outcome. As you can't even predict what's work or not. Except you you no the schism between paradigms within LibreOffice user community (or UX) For me still not clear if this compromise is best interest of enduser (consistence/ coherence). Or if the enduser cares to much. Or this schism only exists for people deeply involved.. Or some need to be different from .. or a group of users who deeply wanted page breaks as formatting attribute.. I assume there is history to it.. starting somewhere in the nineties.
Just to answer those who like to throw in unrelated rant filled with self-inventer guessing positioned as truth. There was no "people not able to choose". The ODF is built with "page break (and page style) are paragraph property" concept. It is decided, and allows things like having paragraph styles that have the page break property. But as there are people that *want* to see it as a kind of "insertable object", a helper was implemented to allow insertion of the break using a dialog (which lists different kinds of breaks). Of course, adding such a helper makes people imagine that "people not able to choose"...
(In reply to Mike Kaganski from comment #13) > Just to answer those who like to throw in unrelated rant filled with > self-inventer guessing positioned as truth. > > There was no "people not able to choose". The ODF is built with "page break > (and page style) are paragraph property" concept. It is decided, and allows > things like having paragraph styles that have the page break property. > > But as there are people that *want* to see it as a kind of "insertable > object", a helper was implemented to allow insertion of the break using a > dialog (which lists different kinds of breaks). Of course, adding such a > helper makes people imagine that "people not able to choose"... Sorry for what you call 'rant'. However not sure where to bring this up elsewhere (and kind of relevant, IMHO). Also thanks for answering! For the record: I was bit ambiguous with "people not able to choose" was not directed to user (but more related to those involved in development/design) So there was an actual choice: page breaks are paragraph settings.. Which got "polluted" by compatibility mode which kind of suggesting an object. Similar as what they blue page break line does. As 'paragraph setting' is the design choice, and 'object interpretation' only compatibility mode this should be included in arguments made (in my perception). The starting point for reasoning should be based 'paragraph setting' As this does make request for comment 0 'stronger' and argument against it 'weaker'. [I do get the request and yes I do get objection; and no clue what's proper outcome]. Without this knowledge it's hard to follow the line of reasoning, IMHO.
There is *no* need in arguments here. The solution is simple, does not need any compromises for any side, and is discussed to be a setting under Options -> Writer that would include *more* things in the "Clear DF" if user feels they want that. The code pointer is provided in comment 9. No more polluting of the issue is needed, unless one has something substantial to *change* the suggested solution, or - maybe - someone wants to make the issue unmanageable, and prevent people understanding the issue by filling it with uncountable posts.
(In reply to Octavio Alvarez from comment #10) > This just means that, unfortunately, whatever decision is made will break > the expectation of a different set of users. FWIW: my comments where triggered by this line.. Note: even a dedicated setting is a compromise (and not a panacea) :P. People must be aware of the presence. It also triggers a discussion about the defaults). Normally a issue is 'mitigated' by saying there is a setting for that. (and dissolving most of the sting). Hard to argue against it.. but sometimes still feels like leaving something hanging in the air. And people still land in ask or here, as the 'initial experience' not being ideal. And you have - as user - to remember you're specific configuration. Again, there no final answer/solution to this (preference/expectations differ). However, adding another tweak to accommodate this, not kind of bloating things? And surely not tested by majority (nor maintained). From that perspective I'm even reluctant for creating a setting at all. Only sharing opinion/vision. Not inclined to start debate.. more sharing thoughts. And yes I maybe phrase it in a way people are inclined to respond, else a 'truth' being born. But not sure how to archive that in a neutral observer like way. My 2 cents.. --- For the record: I marked my other comments (and responses)off-topic keeping this kind of clean.
(In reply to Telesto from comment #16) We live in a real world. In it, there is LibreOffice, with its innovative idea of "break being a paragraph property", making many things logical and simple, having it as its strength. And we have other word processing programs that have the other model (with page break being an object), that *also* has its upsides, and results in people having mindsets and expectations. You simply cannot have all best things at once, and no downsides. And it's not OK to be overly rigid in not accepting tools that mimic the other model. Speaking about "not ideal", "feels like leaving something hanging in the air" etc. is just being idealistic, and wasting time. A setting allows people to make the job done. Other improvements (like tdf#91874) could improve discoverability. Or of course, we may just drop LibreOffice code as a whole, and start making a true AI with mind-reading capabilities, that would produce documents without user involvement.
(In reply to Mike Kaganski from comment #17) > A setting allows people to make the job done Let's come back to the topic. This is a solution, another is to have a dedicated UNO command and an entry in the toolbar. Or we just resolve as WF with the argument that most if not all users expect PB to remain when cleaning DF from the document. The topic is on the agenda for the call this evening, input here is welcome.
(In reply to Heiko Tietze from comment #18) > input here is welcome. I would certainly welcome this *setting*. Especially in the view of coming SI, which would make people see the DF, and then after clearing it, will see the remnants left. I definitely oppose the idea of more .uno commands, because (1) it is most probably a decision to make once for a user, if they want something cleared or not when using Clear DF; (2) adding such a UI (like Clear only character formatting, clear only paragraph formatting) will inevitably confuse users who do not realize that e.g. paragraph formatting includes character formatting, and so why selecting part of paragraph that was DF-ed to bold, and clearing DF, does not make effect? or changes the whole paragraph? The idea of additional commands is not what is asked here (make the function more self-consistent), it's introducing a new feature with a huge confusion impact in the view of the DF/style relations complexity.
(In reply to Mike Kaganski from comment #17) > (In reply to Telesto from comment #16) > And it's not OK to be overly rigid in not accepting tools that > mimic the other model. Don't get me wrong. Not trying to imply such a thing. It's surely amicable. Only attempting to accentuate a negative side-effect. If you assume (pre-biased) it's an formatting object (which kind of common in different editors) and move to LibreOffice you get the impression of again being an object (as it apparently behaves as expect. Insert page break + CTRL+ENTER + floating toolbar at page break). Until the point you start editing. And some point - un-expect - you become aware it's a paragraph property (which you didn't even consider in advance.. as it isn't universal). So keeps an illusion in tact until the bubble bursts. As the mimicking only goes to a certain point (when you fall through). Some my never notice.. But if you fall through the experience becomes rather confusing. As it totally different compared to the first appearance. You think you got it, but surely not the case. There is no flowing seamlessly from paradigm A into B . It's abrupt ending.. But that's my personal experience. I would even consider 'real' object page breaks next to paragraph formatted page breaks [as I kind of in fight with it a certain points] But making stuff likely complex too. With lots of different decoration of for source of the page break. So not quite sure if this an reasonable proposal at all. > Speaking about "not ideal", "feels like leaving > something hanging in the air" etc. is just being idealistic, and wasting > time. A setting allows people to make the job done. Other improvements (like > tdf#91874) could improve discoverability. Merely attempted to say: more settings is not automatically a panacea. Say you expect Clear Formatting removing page breaks. And it isn't . And starting to question yourself. I'm I doing something wrong? Why isn't the page break not removed.. If you ask that question.. and start investigating (which likely not to common; I personally opt for *argh* have to remove those manually). You must be quite interest in the topic. Then the get the answer there is a setting inside Tools -> options -> .. [Assuming Page breaks not being deleted by default using clear formatting]. So how many people will find it, use it? [And Test it] Similar happening with my favorite example markdown auto-correct. It's enabled by default. Typing *HELLO* [SPACE} results in bold. Without having a clue how or why. So yes, I can disable Markdown. But simply don't know about it being enabled. Or even considering * * being a markdown command. Similar for /Hello/ (hyperlink/ file path) So writing a bug report.. getting report it's setting.. takes the 'angle out', but still kind of discontent (that's the case for me at least). Here I debate the presence of the feature (does Markdown belong to editor) to being enabled by default. [Heiko surely getting tired of me bringing this up endlessly on every occasion I can find; but he probably has a *shrug* mode] > Or of course, we may just drop > LibreOffice code as a whole, and start making a true AI with mind-reading > capabilities, that would produce documents without user involvement. Hmm, preferable not. I'm mostly not totally clear what I 'think I want' and what I actually want. Another solution might be simply using good old typing machine :P. Solves a lots of problems (and replaces them with new ones). -- Leaving this at the UX department to figure out what to do here. As I get the request of comment 0, but also reluctant to add more settings. Surely not able to weight the pro/cons [And Mike thank you time.. answering.. I can be kind of annoying; persistent, hard-headed. And bit sloppy in my communication]
Fwiw, I would *never* expect that clearing formatting would remove any page breaks, specifically not if they were created manually. Doing so would be a bug, not a feature.
(In reply to Telesto from comment #20) > There is no flowing seamlessly from paradigm A into B . It's abrupt ending This is the mistake you repeat again and again, not trying to accept your mistake. LibreOffice is not a teaching tool. It is *not* created to provide some sort of "smooth transition" between paradigms by revelation. It is built around (and provides a tool set for those who use) style-pased approach. It *also* provides a separate (limited) tool set for those who don't use the styles paradigm, as much as fits into LibreOffice architecture. The two paradigms are *incompatible*. The latter is not meant as an educational material. It is created to *allow people have their task done* for those who *don't* use styles. That's all. If you need to learn the other paradigm, there's no smooth transition. You need to read guides, and change your mind set. There is no, and never will be, the thing that you expect again and again in your numerous posts: things that allow you to live comfortably between the two stools. This is just because the two paradigms are incompatible. And in this case, it's the same: if you use helper tools as means to understand program architecture (or at least underlying principles), you are doing it wrong.
We discussed this topic in the design meeting and did not come to a agreement. Options are: a) another UNO command that clears also page break (interaction similar to Save/SaveAs) b) an option that toggles the behavior c) always clear the page breaks d) reject the enhancement request (btw, MSO behaves similar to LibreOffice) There seems to be a trend for d).
(In reply to Heiko Tietze from comment #23) > btw, MSO behaves similar to LibreOffice Note that this is absolutely irrelevant here. It's obvious that current behavior is modelled after the idea in the other tools that don't have the "page break is a property of paragraph" concept; and Word is one of those. The idea of this RFE is to provide a means to (optionally) use the tool *consistently* with *its own* architecture. FTR, it seems that people overlook comment 9 entirely. And there are many more things in DF that are skipped when clearing DF, both on character and paragraph levels, some of which are listed in the said comment. They include *language*, *direction*, "numbering styles". I'm OK with closing it WONTFIX ATM; my take is "it will be reopened eventually when it all becomes more prominent in SI in v.7.1".
(In reply to Mike Kaganski from comment #24) > "numbering styles". Sorry, a thinko. Should had been "numbering rules".
(In reply to Mike Kaganski from comment #22) > (In reply to Telesto from comment #20) > > There is no flowing seamlessly from paradigm A into B . It's abrupt ending > > This is the mistake you repeat again and again, not trying to accept your > mistake. LibreOffice is not a teaching tool. "Teaching tool" is the outer of the spectrum, IMHO. Which I would call Clippy. Or help. However I prefer to be in control. And being able to estimate what a function is doing (based on past experience, and maybe even other tools). The bold icon as 'bold' b. B. CTRL+B being surprisingly the shortcut. And letter being *bold*. We could also show cursive I in the toolbar for bold with shortcut CTRL+C. You sort of Stroop-effect. The Bold button is as it is, because similarity (convenience/recognizable). It's easy to remember (b for bold) and visual supporting. So has all elements of 'teaching' subtly embedded It also touches the design principles in my interpretation of them https://wiki.documentfoundation.org/Design/Principles (Self-Explanatory & ux-consistency). I prefer self-explaining functions and ux-consistency. The same function is presented in different ways. Insert -> Page break kind of pointing to object. And there is Format -> Paragraph Style -> Text Flow -> Page Break. Insert -> Page break -> could hypothetically also point to Format -> Paragraph Style -> Text Flow tab. From functionality perspective not that much different. I never ever realized of presence Format -> Paragraph Style -> Text Flow because of Alt+Enter & Insert -> Page break . And page break kind of buried deep in the paragraph settings, while rather often used. -> And because most of LibreOffice really does match my expectations on - what you call 'teaching' - I assume this also to be true for page breaks (and number of other areas). Inserting landscape page style between page breaks by double clicking one of them (different bug report) It is *not* created to provide > some sort of "smooth transition" between paradigms by revelation. It is > built around (and provides a tool set for those who use) style-pased > approach. It *also* provides a separate (limited) tool set for those who > don't use the styles paradigm, as much as fits into LibreOffice > architecture. The two paradigms are *incompatible*. The latter is not meant > as an educational material. It is created to *allow people have their task > done* for those who *don't* use styles. That's all. If you need to learn the > other paradigm, there's no smooth transition. You need to read guides, and > change your mind set. There is no, and never will be, the thing that you > expect again and again in your numerous posts: things that allow you to live > comfortably between the two stools. This is just because the two paradigms > are incompatible. And in this case, it's the same: if you use helper tools > as means to understand program architecture (or at least underlying > principles), you are doing it wrong. I barely use styles, but I do use page breaks, I encounter issue never the less because of the paradigms. And comment 10 also makes note of two visions floating around. If LibreOffice page break by paragraph style it should make it more obvious from the start. Insert -> Page Break -> Manual page break could point to Paragraph styles dialog instead of dedicated dialog. And say pre-fill the settings. Pressing OK would still 'do' what it supposed to do. But not masking the whole conceptual difference. I not extensive user of documentation. And also 'hard' to search for something if you don't know where it's coming from. What do I search for if *hello* turns up bold. If you now it's autocorrect you now where to look in help. But if you have no clue how, what and where.. Same holds true for page breaks (and have couple of other bugs open with surprise or struggle factor. Where it must be possible to make path bit more 'smooth'. Instead helping out but putting people on the wrong foot with that at the same time. Kind of similar to the whole bold/unbold topic. Where clicking bold is enable bold. And clicking it again not resulting in disable bold (which GUI suggesting this), but being explicit unbold [It similar thing to me, but I admit out of scope here] And this: "*allow people have their task done* for those who *don't* use styles" is simply untrue. The fact if you use styles or not is irrelevant. It suggests the scope of the issue would be limited exclusively to explicit page style users. However even the defaults are styles. And the page break is still a formatting not an object if with active usage of styles Drag drop starting of first paragraph after page break creates unwanted results.. And DOCX tends to love to add additional page breaks, make extending the conflict. I believe there must be alternative possible to *allow people have their task done* while being more transparent about what's happening. The main objective is surely: *allow people have their task done*. However, I think it can be implemented more communicative. So you might get a feeling in kind of natural - non-intrusive/disturbing way - about what's happening. So searching for win-win proposition. Communicative ui/getting work done) are not two Mutual exclusive targets (zero sum game) The can blend into each other, IMHO. The can go hand in hand, IMHO.
Interestingly enough, although Clear Direct Formatting does not remove manually inserted page breaks or manually added page breaks as format, it does re-add manually removed page breaks if the paragraph style originally had a page break and then the break was removed from the Format > Paragraph dialog.
(In reply to Octavio Alvarez from comment #27) > does re-add manually removed page breaks... Consistency at its best ;-)
Bug 139079 comment 0 (R. Green) The most natural and fastest way to clear ad hoc formatting from a WRITER file SHOULD be to select ALL and apply "Clear direct formatting". But this cannot be done because the command (inexplicably) deletes page breaks as well. (Even worse, the deletion of page breaks does not show up until the document is saved and reloaded: see Bug 73483.) Imagine a book with many chapters, and it has become apparent that there is character formatting applied willy nilly throughout the document. The user wants to remove this leaving only the paragraph and character styles. To avoid losing page breaks, the user has to apply "Clear direct formatting", section by section, skipping the page breaks. A very time-consuming and tedious business. IMV, the average user is likely to assume (wrongly) that "Clear direct formatting" only applies to text and should leave page breaks alone. SUGGESTION: "Clear direct formatting" should NOT delete page breaks. Instead there should be another command, "Clear page breaks", to delete the page breaks separately.
(In reply to Telesto from comment #29) Very interesting, and reproducible. Funny. It actually does remove the manual page breaks when saving. That is definitely a bug: the code does things to *not* clear the breaks, and I assume it still clears *something* unintentionally that relates to the breaks, that prevents the *kept* break from being saved to ODT. Note that it *does* correctly save the "cleared" break to DOCX, so it proves this to be a bug. So all in all, the "Clear DF breaks saving manual page breaks to ODF" is a separate bug (tdf#73483 correctly mentioned in See Also), and existence of that bug (which clearly shows some people *want* to keep breaks when clearing DF) makes it obvious that "clear manual breaks unconditionally" (c) in comment 23) is not a proper solution.
> Bug 139079 comment 0 (R. Green) > Imagine a book with many chapters, and it has become apparent that there is > character formatting applied willy nilly throughout the document. The user > wants to remove this leaving only the paragraph and character styles. If the user only wants to keep paragraph and character styles than deleting all unsigned page brakes is IMO exactly what Clear direct formatting should do. An e-book is normally delivered as PDF-file and even if its still work-in-progress should the author use styles on a document this size. Clear Direct Formatting does not delete page breaks that are applied to a paragraph style but only page break of direct formatted paragraph without any style.
IME, use of in-paragraph-style page breaks was haphazard due to Bug 134439. However this has now been fixed.
(In reply to Sascha Z from comment #31) > Clear Direct Formatting does not delete page breaks that are applied to a > paragraph style … Yes, the page breaks are kept, but all the page styles are wiped and revert to default. IMV, there is a need for a user option to be able to "lock" the page styles in some way, so that you can use "Remove direct formatting" without worrying about losing them.
(In reply to R. Green from comment #33) >all the page styles are wiped and revert to default. Confirm this (mis)behavior happens to me after saving, closing and reloading the document. In my case it even removed all bake breaks to styled paragraphs. Would this call another bug.
thanks for the discussion and insights. Let me resolve this as NotABug.
Why is this bug just closed? We never found any solution but even more bugs!
(In reply to Sascha Z from comment #36) > Why is this bug just closed? We never found any solution but even more bugs! **Good question. I myself was baffled. What is the conclusion of this lively discussion?
I suppose Cor just accidentally pushed the button in the wrong browser tab :-) No need to worry, this is obviously still NEW.
(In reply to Telesto from comment #29) > SUGGESTION: "Clear direct formatting" should NOT delete page breaks. Instead > there should be another command, "Clear page breaks", to delete the page > breaks separately. **Even those who belong to the style, eg, a Heading1 because you want a chapter to begin on a new page?
> The most natural and fastest way to clear ad hoc formatting from a WRITER > file SHOULD be to select ALL and apply "Clear direct formatting". **Why would one do DF here and there throughout a (large) document, and suddenly decide to remove it all? More likely, "Clear direct formatting" will be applied punctually, one parag at-a-time.
(In reply to TorrAB from comment #40) > > The most natural and fastest way to clear ad hoc formatting from a WRITER > > file SHOULD be to select ALL and apply "Clear direct formatting". > > **Why would one do DF here and there throughout a (large) document, and > suddenly decide to remove it all? More likely, "Clear direct formatting" > will be applied punctually, one parag at-a-time. Not at all; I do it all the time for different reasons even for large documents. Examples: 1. Pasted documents from the Internet or imported from other documents will require cleaning. "Clear All Formatting" and "Paste Unformatted" may not be desirable when copying large portions if the formatting is decently applied. Also, existing formatting may be used as visual guides to reapply styles. A full clean up may be needed afterwards. 2. After applying a set of direct formats a formatting pattern may come up which will lead to the creation of a Style. Once the Style is created and applied, Direct Format should be removed to avoid formatting surprises. Character styles can become the most confusing but the most useful sometimes. 3. The user may lose track of direct formatting. Maybe the file was reverted to a saved version or format paintbrush was used throughout the document. A quick clean can be done by issuing "Clear Direct Formatting" to the whole document. 4. If I know that I am keeping the document DF-clean, then it is just way easier and faster to do Ctrl+A, Ctrl+M and going to specific paragraphs to clean DF. In "surprises" and "losing track" I am including what I have called "hidden Direct Formatting" in the past. Hitting Bold twice does *not* remove direct-format-bold; it instead sets the text as direct-format-regular. So, yes, this is why cleaning the whole document from DF is sometimes necessary. To keep it on-topic: it would certainly be a bit confusing if I suddenly lose manually inserted page breaks when doing a document-wide "Clear DF" if I did it using Insert > Break or Ctrl+Enter.
(In reply to Octavio Alvarez from comment #41) > To keep it on-topic: it would certainly be a bit confusing if I suddenly > lose manually inserted page breaks when doing a document-wide "Clear DF" if > I did it using Insert > Break or Ctrl+Enter. * People seeing a page break being as object will never consider a page break to be removed by clear formatting * People seeing page break as formatting, might desire removal or not (depending) on the user case. Also there is partly a terminology question: clear DF formatting reads as clear all (DF) formatting. In that line obviously all formatting must be removed (including page breaks, as this being formatting in the LibreOffice model). Obiter dictum: I personally see use case for both types of page breaks, instead of always getting the 'formatting one'; see bug 137151.
(In reply to Octavio Alvarez from comment #41) > (In reply to TorrAB from comment #40) > > > The most natural and fastest way to clear ad hoc formatting from a WRITER > > > file SHOULD be to select ALL and apply "Clear direct formatting". > > > > **Why would one do DF here and there throughout a (large) document, and > > suddenly decide to remove it all? More likely, "Clear direct formatting" > > will be applied punctually, one parag at-a-time. > > Not at all; I do it all the time for different reasons even for large > documents. Examples: > > 1. Pasted documents from the Internet or imported from other documents will require cleaning. **Will these foreign documents contain LO-formated pageBreaks? Would you suffer if those breaks were removed by "Clear direct formatting"? Will you not want to remove some of them, and add your own, as part of the required ‘cleaning’? > Character styles can become the most confusing […] **… but they are independent from parag styles, to which pageBreaks belong. > […] what I have called "hidden > Direct Formatting" in the past. Hitting Bold twice does *not* remove > direct-format-bold; it instead sets the text as direct-format-regular. **not in my test: select a normal (non-bold) word; hitting ^b several times toggles the format bold on and off. Anyway, this is character formatting, independent from pageBreaks
IMO the underlaying bugs needs to be fixed before. Bug 73483 "Clear direct formatting deletes page breaks but this does not show up until reopened" breaks the feature and gives users unexpected results. Also I created a report for the bug described by R.Green in comment #33 as 139311 "ClearDirectFormatting removes page styles". We can still hold endless discussions if or if not page breaks should removed after these bugs got fixed.
(In reply to TorrAB from comment #43) > > […] what I have called "hidden > > Direct Formatting" in the past. Hitting Bold twice does *not* remove > > direct-format-bold; it instead sets the text as direct-format-regular. This being kind of a thing, but surely off-topic here: bug 135871
adding see also to bug 74078, because search on "Page Style" attribute refers exactly to Page Breaks. Is it possible that the reason why Page Break is not removed from Direct Formatting is the same reason why the "Page Style" search attribute does not work?
This wish is the opposite to bug 139079.