Hi. When I apply the the autocorrect to a text in order to correct it all at once, it happens that all the text/paragraph/linespace formatting is lost, getting back to default. As an example, I have a text that is in Calibri Light size 10, with space between lines and paragraphs as normal and equal for both, and when I apply autocorrect to the text, it sets the text to Times New Roman size 12, with extra space between paragraphs. The autocorrect shouldn't affect the formatting options...
Can you reproduce it repeatable with a new WRITER document? If yes, can you please give more information about the different single steps to reproduce it. I couldn't reproduce it with LO 4.4.1.2, Win 8.1.
I have LO 4.4.1.2 Portuguese Version, and Windows 7 Home Edition. This happens in all new "writer" documents I open. First write a lot of text in Calibri Light size 10, then select it all, right-click it and select paragraph. Set all the space between the paragraphs and lines to the minimum possible (0, simple, etc.). Then select Format in the upper bar, Autocorrection, then Apply. The formatting is then lost. Even worse: I discovered that if a paragraph starts with a speech dash (alt+0151), the autocorrection transforms it into a bullet black circle and the paragraph becomes as it was on a list. Also, I noticed that if you change the text formatting in the list on the left of the font list, the formatting also changes. The font, for instance, becomes Liberation Serif... (In reply to A (Andy) from comment #1) > Can you reproduce it repeatable with a new WRITER document? If yes, can you > please give more information about the different single steps to reproduce > it. I couldn't reproduce it with LO 4.4.1.2, Win 8.1.
Ah, now I understand what you mean, thank you very much. Reproducible with LO 4.4.1.2, Win 8.1. If you select FORMAT -> AUTOCORRECT -> APPLY the font is automatically changed to the Text Body specs (go to the Sidebar -> STYLES AND FORMATTING -> PARAGRAPH STYLES -> Text Body). I agree there should be an option that the font is not changed, but I could not find it. In this case it could be from my point of view some kind of an enhancement request?
So let's make this into an enhancement request -> Adjusted Summary -> Severity: enhancement
Probably need to figure out why the [M] modify AutoCorrect options only apply the Default style, bug 59034, as that would need to be fixed before this can be sorted.
(In reply to V Stuart Foote from comment #5) > Probably need to figure out why the [M] modify AutoCorrect options only > apply the Default style, bug 59034, as that would need to be fixed before > this can be sorted. This hypothesis does not seem correct. In 7.2.0.0.alpha0+, unselect all [M] options in Tools - AutoCorrect - AutoCorrect Options, then use Tools - AutoCorrect - Apply in a document with some non-empty paragraphs with "Default Paragraph Style". All non-empty "Default PS" are converted to "Text Body" PS with this comment (even though no [M] fields are checked). This explains the observation in comment 0. Have changed bug summary accordingly, but not sure why this bug is classified as an enhancement. Seems like a bug (imho).
(In reply to sdc.blanco from comment #6) > (In reply to V Stuart Foote from comment #5) > > Probably need to figure out why the [M] modify AutoCorrect options only > > apply the Default style, bug 59034, as that would need to be fixed before > > this can be sorted. > This hypothesis does not seem correct. > > In 7.2.0.0.alpha0+, unselect all [M] options in Tools - AutoCorrect - > AutoCorrect Options, then use Tools - AutoCorrect - Apply in a document with > some non-empty paragraphs with "Default Paragraph Style". > > All non-empty "Default PS" are converted to "Text Body" PS with this comment > (even though no [M] fields are checked). > > This explains the observation in comment 0. > > Have changed bug summary accordingly, but not sure why this bug is > classified as an enhancement. Seems like a bug (imho). Right and the issue of Tools --> Autocorrect --> Apply only applying to "Default" paragraph style is still involved. Issue of OP would not occur if their PS is something other than Default. It effectively clears the DF applied to default paragraphs, and casts them to Text Body--to me that is happening within the edit shell. Also, either the 'Default' or the 'Text Body' PS may be modified (i.e. not by DF) from template defaults to suite authoring needs--so this is a styles based editing feature--poorly documented and in need of rework. But it is consistently implemented. The Autocorrect 'M' modify applicable to 'Default' PS is involved. For example use the markdown we support: bold, italic, strikeout and underline. Set up a FODT with dummy text in a paragraph of Default, vs dummy text in a paragraph of Quotation. Edit the FODT externally (notepad++, or vi) to bracket a few text spans with the flags. Then open in Writer and Tools -> Autocorrect -> Apply. Only the Default PS will be affected.
(In reply to V Stuart Foote from comment #7) > so this is a styles based editing feature--poorly documented and in need of > rework. But it is consistently implemented. iiuc, there is no bug here? in which case, would a relevant "enhancement" request -- formulated explicitly in positive terms -- be something like? "Do not convert non-empty 'Default Paragraph Style' to 'Text Body' when using Tools - AutoCorrect - Apply." or "Add a [M] option to control whether "Default PS" are converted to 'Text Body'" (for example, under "Replace Custom Styles" it might be "Convert "Default Paragraph Style" to "Text Body"
The FN_AUTOFORMAT_APPLY is ancient StarOffice handling by SvxAutoCorrCfg, not surprised that its linkage in AutoCorrect GUI for existing (the Modify 'M' checkbox) only applies between 'Default' and 'Text Body' PS. So, it requires user to assign selection to 'Default' PS for the AutoCorrection to apply to existing text--and that the resulting paragraph receives the 'Text Body' PS. Enhancement would be to provide user choice of target PS conversion, or perhaps to not force the conversion at all--an option on the AutoCorrect dialog. It is actually pretty handy "feature", but it needs documentation of its current state, and absent refactoring probably adjustments in the UI (e.g. some of the 'M' checkboxes should be listed as applicable only to 'Default' paragraph style ).
(In reply to V Stuart Foote from comment #9) > It is actually pretty handy "feature", but it needs documentation of its > current state Thanks for interesting archeology. Have been trying to improve the documentation, but will appreciate any help I can get. From one PoV, whether intended or not, it could look like AutoCorrect was designed to make it easier (or to encourage) shifting over to Styles-based document production. This bug 90507 notes that Tools - AutoCorrect - Apply automatically changes all Default PS to Text Body (requested or not). [This has been documented since at least 2015, but now I have tried to clarify the "note" about this]. (Bug or not, this current behavior is consistent with promoting a styles-based approach, and makes it "easy" to get rid of unstyled (default) paragraphs from a document.) Bug 95433 notes (and objects to) that using choosing "Apply Styles" in [T] also changes Default PS to Text Body after Enter is used. (but is that a bug?, especially when user has chosen "Apply Styles"?) In both cases, these "bugs" could be seen as features to help insure the avoidance of unstyled paragraphs appearing in a document. But this potentially helpful behavior "collides" with the issue in bug 59034, namely that (many) [M] options only work with Default PS. In short, at present, this (speculative) "helpful" behavior described in bug 90507 and bug 95433 undercuts the possibility to make post-facto auto-correcting clean-up in a document (unless one is willing to remove all non-default PS).
(In reply to sdc.blanco from comment #10) > ... > But this potentially helpful behavior "collides" with the issue in bug > 59034, namely that (many) [M] options only work with Default PS. > ... Yes I would agree, and would also note the 'Replace Custom Styles' has some interesting behavior as well. Not clear if those are relative to the Standard Template, or to the Template used to create the document--but its action when applied is to remove other PS and revert to something present in the template. So, makes me wonder exactly what is considered a "custom" style as related to the AutoFormat in (editeng/acorrcfg.hxx & acorrcfg.cxx)? I've gotten lost several times now trying to trace it out in Opengrok.
(In reply to V Stuart Foote from comment #11) > 'Replace Custom Styles' has some interesting behavior According to help, https://help.libreoffice.org/7.2/en-US/text/shared/01/06040100.html: Replaces the custom paragraph styles in the current document with the "Default", the "Text Body", or the "Text Body Indent" paragraph style. From experimenting: 1. Have not been able to get "Default" only "Text Body" and "Text Body Indent" (wondering if I should "remove" "Default" from "help") 2. Have also gotten "First Line Indent" (for a custom style that inherits from Quotations) 3. Adding a manual Tab at beginning of Custom Style gives "Text Body Indent" (or "First Line Indent") instead of "Text Body" 4. Custom Styles with Borders are NOT modified (which I assume should be considered a bug) Perhaps I need to start a new ticket for that option?
When I create a new PS "Test" based on Default with a red font color and do autocorrection like "SHe" (converted to She) or *way* (made bold) the PS remains "Test" and the color is still red. And that's what I expect, namely auto correct does not change my format. Am I wrong? Version: 6.4.7.2 Build ID: 6.4.7-9 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: kf5; Locale: de-DE (en_US.UTF-8); UI-Language: en-US Calc: threaded
(In reply to Heiko Tietze from comment #13) > When I create a new PS "Test" based on Default with a red font color and do > autocorrection like "SHe" (converted to She) or *way* (made bold) the PS > remains "Test" and the color is still red. And that's what I expect, namely > auto correct does not change my format. Am I wrong? > > Version: 6.4.7.2 > Build ID: 6.4.7-9 > CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: kf5; > Locale: de-DE (en_US.UTF-8); UI-Language: en-US > Calc: threaded Additional steps: Save the document and reopen. Select the paragraph with your 'Test' custom PS Tools --> Autocorrect --> Apply Result? On Windows builds the custom PS is converted to the 'Text Body' or standard template.
(In reply to V Stuart Foote from comment #14) s/or/of ...to the 'Text Body' of standard template.
Tools > AutoCorrect > Apply does in fact change the PS. My "Test" formatted text becomes Text Body and the previously auto formatted text 'while typing' (SHe -> She and *nervously*) are now direct formatted (bold was DF before). With 7.2 I don't this conversion into DF anymore and "She" is black. What input is needed from UX?
(In reply to Heiko Tietze from comment #16) > > What input is needed from UX? Well we should improve the documentation, obviously. But AC controls modifying existing text--styled or DF--are very powerful and in a sense quite dangerous as applied to 'M' modify existing content. Need to verify the handling of 'custom' styles, what constitutes them and how are they made non-custom so can be protected from the 'Replace Custom Styles' action. Also, given the evolution of styles in the LibreOffice UI, how could the AC handling in editshell be applied to a broader mix of styles. Currently it only converts a limited set of PS. Any consistent usage now requires user select and apply a 'Default' PS first, and only results in a 'Text Body' PS. While results of the 'Replace Custom Styles' action seems error prone to document layout at best.
(In reply to Heiko Tietze from comment #16) > What input is needed from UX? In this concrete instance, AutoCorrect is categorically modifying Default PS to Text Body, with no way to ‟disable” this action (see comment 8) I understand the motivation for Stuart’s query to be: - AC was designed a long time ago. - Most of actions in [M] only work with Default PS, limiting its utility. - And this current bug 90507 makes it even worse, because one Tools > AutoCorrect > Apply removes all Default PS. - But AC may have interesting potential if its capability was expanded beyond Default PS. - Plus its current operation with "Replace Custom Styles" should be reviewed in light of LO orientation to styles. But maybe that discussion should be a new ticket, so that the bug report here does not get lost -- which should be addressed no matter what else is decided for AC.
My question is rather why AC changes the style at all (except for the markup formatting things). My take: No [M] at all.
(In reply to V Stuart Foote from comment #17) > While results of the 'Replace Custom Styles' action seems error prone to > document layout at best. Opened Bug 140024 in relation to "Replace Custom Styles"
(In reply to Heiko Tietze from comment #19) > My question is rather why AC changes the style at all Because you (probably) had "Replace Custom Styles" activated in your AutoCorrect options. If the checkbox was unchecked then your Test PS (probably) would not have changed. > My take: No [M] at all. Sounds a little drastic. There are many useful [M] options (e.g., combine single line paragraphs), which can be applied selectively.
Trying to summarize: + AutoCorrect's "Replace while modifying existing text" works only for Default style (bug 59034) + issue is that "Apply" changes the PS to Text Body (does not happen while typing); if nothing is selected, Apply affects all text + "Apply and Edit Changes" changes the PS but is not taken into track changes + do not force the conversion at all but OTOH handy yet undocumented feature (Stuart) + promoting a styles-based approach, and makes it "easy" to get rid of unstyled (default) paragraphs (Seth) + "[T] Apply Styles" not working on typing (Seth) + 'Replace Custom Styles' has some interesting behavior as well (Stuart) + unclear how this relates to used templates + "replace custom styles" option in AutoCorrect needs critical review (bug 140024) I don't think a "style my document" function is desired. In particular without a chance to follow the modification due to missing TC support. Could be fixed, of course. But simple step forward could be to rename the unclear caption to "Change 'Default Paragraph Style' to 'Text Body'". We should also at least check on Apply whether this option is enabled. Removing UX to get this into production.
Start working on this together with bug 128192. I'll prevent AutoCorrect from changing the style if it is expected.
In this patch, it should be able to prevent AutoCorrect from changing "Default Paragraph Style" paragraphs into "Text Body". Meanwhile, AutoCorrect still converts potential headlines into "Heading 1". I'm not sure whether we should keep this behavior or not. Looking for an answer! https://gerrit.libreoffice.org/c/core/+/151008
(In reply to Heiko Tietze from comment #22) Hi, I'd like to confirm what is expected in this bug. > + AutoCorrect's "Replace while modifying existing text" works only for > Default style (bug 59034) This should be fixed in bug 128192. > + issue is that "Apply" changes the PS to Text Body (does not happen while > typing); if nothing is selected, Apply affects all text This is expected, and it is worth investing why it doesn't work while typing. > + "Apply and Edit Changes" changes the PS but is not taken into track > changes True. It only happens in the BuildText function. > + do not force the conversion at all but OTOH handy yet undocumented > feature (Stuart) I can prevent the force conversion from Default Paragraph Style to Text Body > + promoting a styles-based approach, and makes it "easy" to get rid of > unstyled (default) paragraphs (Seth) A new option can be added to AutoCorrect maybe. > + "[T] Apply Styles" not working on typing (Seth) True. > + 'Replace Custom Styles' has some interesting behavior as well (Stuart) > + unclear how this relates to used templates If users are using custom styles (user defined styles), then 'Replace Custom Styles' decides whether to apply BuildText function which contains converting style to Text Body to it. > + "replace custom styles" option in AutoCorrect needs critical > review (bug 140024) I'm not so sure about this. Therefore, I'm wondering whether we have decided what to do in this bug. I've currently remove the conversion to Text Body in this patch. If there is anything else expected, please let me know. https://gerrit.libreoffice.org/c/core/+/151213
(In reply to Heiko Tietze from comment #22) > But simple step forward could be to rename the unclear caption to "Change > 'Default Paragraph Style' to 'Text Body'". We should also at least check on > Apply whether this option is enabled. Which unclear caption are you referring to?
(In reply to Baole Fang from comment #25) Thanks for all your work on the AutoCorrect. Here are some comments, but it is likely that additional comments will appear soon. > > + AutoCorrect's "[M] options ... works only for Default PS style (bug 59034) > > This should be fixed in bug 128192. (I can see that the summary of bug 128192 was changed recently, making it, in effect, a DUP of bug 59034). iiuc, after the resolution of bug 128192, all [M] options will be applied to any PS (both predefined and custom) (at least, in principle). Which means that the help page [1] should be updated to remove the following sentence (in 2nd paragraph)? "In general, [M] options are applied only to paragraphs with Default Paragraph Style." > I can prevent the force conversion from Default Paragraph Style to Text Body If bug 128192 is resolved, then your proposal, which is also the purpose of your patch [2], seems like the right thing to do for this ticket (and then the "note" in the help page [1] can be removed.) > > ...makes it "easy" to get rid of unstyled (default) paragraphs (Seth) > A new option can be added to AutoCorrect maybe. No need for a new option because (a) this "conversion" (from Default to "Text Body") can be achieved using the "Find and Replace" dialog, and (b) the AutoCorrect Options dialog has many options already. Also, default PS should become irrelevant if Bug 47295 is resolved. [1] https://help.libreoffice.org/7.6/en-US/text/shared/01/06040100.html [2] https://gerrit.libreoffice.org/c/core/+/151213
Perhaps we should split the bug. (In reply to Baole Fang from comment #26) > Which unclear caption are you referring to? Don't remember, maybe I was referring to some comment.
(In reply to sdc.blanco from comment #27) > If bug 128192 is resolved, then your proposal, which is also the purpose of > your patch [2], seems like the right thing to do for this ticket (and then > the "note" in the help page [1] can be removed.) Thank you for your explanation.
(In reply to Heiko Tietze from comment #28) > Perhaps we should split the bug. Please do. By now, I do not see clearly, if https://gerrit.libreoffice.org/c/core/+/151213 is a reasonable change, or not, from UX decision PoV - only individual PoVs here.
(In reply to Heiko Tietze from comment #28) > Perhaps we should split the bug. Sorry, can you clarify how it needs to be split?
(In reply to Stéphane Guillou (stragu) from comment #31) > > Perhaps we should split the bug. > Sorry, can you clarify how it needs to be split? According comment 27 most issues should be solved with (the duplicate) bug 128192. Seth, what do you think is needed?
Created attachment 187100 [details] screenshot of AutoCorrect options dialog (In reply to Heiko Tietze from comment #32) > what do you think is needed? ...in relation to AutoCorrect [M] (where Tools – AutoCorrect – Apply is involved). 1. The OP of this ticket is that AutoCorrect [M] should not change the PS of a “Default PS” paragraph. That could/should be the issue for a UX decision (where the recommendation is to make that change). 2. Already split out is bug 140024 (about “Replace Custom Styles”) (where I will propose to remove “Replace Custom Styles” as an option). Bug 140024 is mentioned because if these two changes are made, then AutoCorrect (AC) [M] will no longer make any PS changes (consistent with comment 17, comment 19, and comment 22). This “no PS change” principle (in [M] options) could also become a UX decision. Then the function of AC [M] could be described as focused on making corrections/clean-up/replacements in the document (e.g., capitalization, spaces, tabs), where the user should not expect that any PS changes are made to existing paragraphs. (Meanwhile, the Find and Replace dialog already provides a way to make PS changes in a document, with more flexibility and transparency than AC). Finally, outside the scope of AC [M], PS change while typing is the focus of bug 95433). I think this summary covers all the issues raised in the preceding discussions in this ticket. What do you think Stuart?
(In reply to sdc.blanco from comment #33) > I think this summary covers all the issues raised in the preceding > discussions in this ticket. What do you think Stuart? Yes agree, the 'AutoCorrect Options...' dialog's 'Options' panel is not the place for PS changes/replacements -- the 'Find and Replace...' dialog's 'Paragraph Styles' offers more consistent work flow -- it is always in [M] modify context. The [T] 'Apply Styles' and [M] 'Replace Custom Styles' don't function as expected. The [T] apply styles is disabled by default, but we still get the Text Body PS following a Heading PS--so it does not do what would be expected. Would expect the while typing "Apply Styles" should control use of PS 'Paragraph Style...' dialog's Organizer tab 'AutoUpdate', 'Next Style', and 'Inherit from'--how can it, its off by default. And yes the [M] 'Replace Custom Styles' should go, not clear it functions as expected while modifying content of existing PS--the 'Find and Replace...' PS feature will list all PS (template defaults and custom) in the current document for find (only those in use) or replace (any defined in the document). Much more consistent workflow--drop the [M] 'Replace Custom Styles' from the AutoCorrect Options dialog.
Can anyone summerize what should be solved in this ticket?
(In reply to Baole Fang from comment #35) > Can anyone summerize what should be solved in this ticket? Do not change the PS if the option "[ ] Apply Style" is unchecked. Applying a style works as described in the help [1] (except adding tabs to increase the heading level) but apparently either the 'while typing' or 'apply' autocorrection does not take the setting into account. Maybe Stephane has more detailed STR. [1] https://help.libreoffice.org/7.6/en-US/text/shared/01/06040100.html
(In reply to Heiko Tietze from comment #36) > Maybe Stephane has > more detailed STR. Sorry, my understanding of the autocorrect feature is still pretty patchy and it's guaranteed Stuart or Seth will do a better job at it :)
(In reply to Heiko Tietze from comment #36) > Do not change the PS if the option "[ ] Apply Style" is unchecked. Applying > a style works as described in the help [1] (except adding tabs to increase > the heading level) but apparently either the 'while typing' or 'apply' > autocorrection does not take the setting into account. Maybe Stephane has > more detailed STR. > > [1] https://help.libreoffice.org/7.6/en-US/text/shared/01/06040100.html From my understanding "Apply Styles" works as it claims. As it says here [1], it only applies heading styles to text with specific format. It has nothing to do with converting default style to "text body", nor "text body" is following a heading style. When I test its function, it works as expected. Regarding "Replace Custom Styles", it is also working as expected because a custom style is replaced with "text body". The only problem is that "Default Paragraph Style" is also replaced with "text body". Now, I've modified the logic [2], such that 1. "Default Paragraph Style" remains itself during auto correct 2. custom styles are replaced with "text body" when "Replace Custom Styles" is checked I'm not sure whether this is expected. Feel free to leave any comments or code review. [1] https://help.libreoffice.org/7.6/en-US/text/shared/01/06040100.html [2] https://gerrit.libreoffice.org/c/core/+/151213
(In reply to Baole Fang from comment #38) > From my understanding "Apply Styles" works as it claims. So let's resolve the ticket and handle follow-ups in new reports.
(In reply to Heiko Tietze from comment #39) > (In reply to Baole Fang from comment #38) > > From my understanding "Apply Styles" works as it claims. > > So let's resolve the ticket and handle follow-ups in new reports. No patch has been submitted yet, so perhaps it is premature to close this ticket as Resolved. But if I understand proposed patch, then it looks like it might address the problem from the OP.... Note: "Apply Styles" is a [T] option. But the problem is with the applying AutoCorrect manually. So it does not matter if "Apply Styles" works according to the help page. In short: If "Replace Custom Styles" is unchecked and "Apply Styles" is unchecked (or checked, problem happens in both cases), and you run Tools - AutoCorrect - Apply (which should not use "Apply Styles" because it is a [T] option), then, at present, a "Default Paragraph Style" paragraph is converted to "Body Text" PS. That conversion of PS should not happen. That is the point/conclusion of this ticket (as stated in comment 33, comment 34 and comment 36).
(In reply to sdc.blanco from comment #40) > (In reply to Heiko Tietze from comment #39) > > (In reply to Baole Fang from comment #38) > > > From my understanding "Apply Styles" works as it claims. > > > > So let's resolve the ticket and handle follow-ups in new reports. > No patch has been submitted yet, so perhaps it is premature to close this > ticket as Resolved. But if I understand proposed patch, then it looks like > it might address the problem from the OP.... > > Note: "Apply Styles" is a [T] option. But the problem is with the applying > AutoCorrect manually. So it does not matter if "Apply Styles" works > according to the help page. > > In short: If "Replace Custom Styles" is unchecked and "Apply Styles" is > unchecked (or checked, problem happens in both cases), and you run Tools - > AutoCorrect - Apply (which should not use "Apply Styles" because it is a [T] > option), then, at present, a "Default Paragraph Style" paragraph is > converted to "Body Text" PS. That conversion of PS should not happen. That > is the point/conclusion of this ticket (as stated in comment 33, comment 34 > and comment 36). Agree.
Baole Fang committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/083975f9666e3dc6fd665dc0418e6c3130628359 tdf#90507: Prevent changing default style in AutoCorrect It will be available in 7.6.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.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/62a280c3b288b30ac34f68e4665c76369336cda1 (related) tdf#90507,tdf#154933 Text Body -> Body Text
Seth Chaiklin committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/help/commit/a12f65df843f2cd8f2c6a04e41c981c753c3d5bf (related) tdf#90507,tdf#154933 Text Body -> Body Text
Verified with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 069c7dc4e9706b40ca12d83d83f90f41cec948f8 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded Thanks Baole Fang! I hope you will also consider fixing another AutoCorrect bug 140024.