Description: I am trying to convert an old story to HTML. I'd previously used asterisks to indicate italics. In AutoCorrect options, it plainly says "Automatic *bold*, /italic/, -strikeout- and _underline_". So I find+replaced all the asterisks with slashes. I clicked apply, and none of the words became italicized. It turned the remaining asterisks to bold, and the underscores to underlined text, but it absolutely will not make italics. When typing new text inside this document, it will AutoCorrect slashes to italics. But it ignores all the old text. All it does is change the font. I just upgraded from 5.4.1.2 to 6.0.4.2, and the problem still exists. Steps to Reproduce: 1. Put slashes around a word. 2. Check that / -> italics is checked in AutoCorrect options 3. Click Apply Actual Results: The text does not change. (However, the font changes from Times New Roman to Alias) Expected Results: The text becomes italicized. Reproducible: Always User Profile Reset: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: no Version: 6.0.4.2 (x64) Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 4; OS: Windows 6.1; UI render: default; Locale: en-US (en_US); Calc: group User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
As described. Same with -strikeout-. The options strikeout and italic are implemented in 5.4 with commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=6bfe94a631b5c5029a1f96a52b000d25e33bad4a.
Not sure this is incorrect behavior. The two "modes" of autocorrect are while modifying [M] and while typing initial text [T] The correction for typing new text occurs when the closing *, _, -, or / is entered. Likewise with existing text, modifying makes the autocorrection for each enclosing *, _, -, or / Performing a Find & Replace will make the substitution, but I don't believe it is expected to pass the text back through the edit shell to then perform an autocorrect. Should it? Not as implemented. And, revisiting the strings just replaced, backspacing over the closing mark and replacing it triggers the [M] autocorrect for each of the formats--Bold, Underline, Strikethrough, and Italic. Checked behavior in Version: 5.3.7.2 (x64) Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; Locale: en-US (en_US); Calc: group prior to adding the / italic and - strikethrough--Find & Replace did not trigger the * bold or _ underline autoreplace in that build.
Is there, or should there be, optional linkage for Find & Replace to trigger Auto-correct?
WHAT!? Of course this is incorrect behavior! Tools/AutoCorrect/Apply. Right there. Clicking that works with bold and underline, but NOT italics. If it DIDN'T replace asterisks with bolding and underscores with underlining, I would say that maybe it just couldn't do that at all. But it is doing HALF ITS JOB. Why!? And yes, I could go through the entire text and manually delete+replace every / to trigger AutoCorrect normally. That would take an entire days' worth of monotonous work. This is a NOVEL. > Not sure this is incorrect behavior. > Performing a Find & Replace will make the substitution, but I don't believe > it is expected to pass the text back through the edit shell to then perform > an autocorrect. Should it? Not as implemented.
(In reply to SNORT from comment #4) > ... > > Tools/AutoCorrect/Apply. Right there. Clicking that works with bold and > underline, but NOT italics. If it DIDN'T replace asterisks with bolding and > underscores with underlining, I would say that maybe it just couldn't do > that at all. But it is doing HALF ITS JOB. Why!? > Hmm, my bad. I'd mistakenly made a target text selection and then applied the autocorrect. Seems when applying the autocorrect to existing text, a selection is not needed nor helpful--as the autocorrect simply runs through the whole document. So confirming that the Tools -> Autocorrect -> Apply autocorrect does render the * Bold or _ Underline markup, but not the / Italic nor the - Strikethrough. So there is an implementation error--something more needed to be connected to get the same behavior. > And yes, I could go through the entire text and manually delete+replace > every / to trigger AutoCorrect normally. That would take an entire days' > worth of monotonous work. This is a NOVEL. > > No need, just do the * bold or _ underline Find & Replace with "Whole words only" checked, apply the Autocorrect for those to have distinct formatting to work against. Then change the direct formatting with Find & Replace with Find using Other Options -> Attributes--probably with the Including Styles checkbox. Pick an Attribute and use the Format button's dialog to configure first the Find field, and then the Replace field. It is a little bit fussy to get the right mix for desired result, but seems to work. It is a shame that doing it directly for / italic or - strike through with an autocorrect is not 100% yet.
Commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=6bfe94a631b5c5029a1f96a52b000d25e33bad4a had omitted SwAutoFormat::AutoCorrect in sw/source/core/edit/autofmt.cxx, which still only handles '*' and '_' to call SvxAutoCorrect::FnChgWeightUnderl.
Dear SNORT, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The error still exists in Version: 6.4.0.0.alpha0+ (x64) Build ID: 9105b85c708f42024ce063b9a944466c0afdfe9a CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-28_22:42:37 Locale: de-DE (en_US); UI-Language: en-US Calc: CL
*** Bug 139987 has been marked as a duplicate of this bug. ***
Also on Linux, also in 7.5: Version: 7.5.0.1 (X86_64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Hossein, seeing Mike's comment 6, maybe an easyHack?
(In reply to Stéphane Guillou (stragu) from comment #11) > Hossein, seeing Mike's comment 6, maybe an easyHack? Yes. I've marked it as an EasyHack. One should follow comment 6 to find the code pointers.
Fix is tracked in https://gerrit.libreoffice.org/c/core/+/154207. Added Mike to review.
Matt K committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2fa88bfbfa4c9befe1be8a1953c018437a621254 tdf#117651 Add AutoCorrect support for italic and strikethrough It will be available in 24.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.
Can this be closed as fixed?
(In reply to Buovjaga from comment #15) > Can this be closed as fixed? Yes, closing it.
Just tested it but it only works for strikethrough, not for italics. I used the original steps with a fresh profile: (In reply to SNORT from comment #0) > Steps to Reproduce: > 1. Put slashes around a word. > 2. Check that / -> italics is checked in AutoCorrect options > 3. Click Apply Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 43967453e15e1d054972a7586cfef8f8e0866270 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Can you please check? Does it work with those steps on your end?
Confirm not yet correct, with the AutoCorrect options for M and T both checked--the italic markup with "/" bracketing does not correct during modify. But it does apply while typing. Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 01a02ee7f1dbe7501a89b41e62599fba6a8b33f3 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded with 2fa88bf applied, something not quite behaving.
New fix is tracked in https://gerrit.libreoffice.org/c/core/+/160529. Added Mike to review.
Also, the fix for the debug assert is at: https://gerrit.libreoffice.org/c/core/+/160547
Matt K committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dc8b69e3393d4f71900ea871db5598a5f7af567e tdf#117651 Fix AutoCorrect support for italic, strike, bold, and underline 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.
Matt K committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/90d732a5311551ae79969ee24d98cf21ffbacac7 tdf#117651 Fix AutoCorrect crash for italic, strike, bold, and underline 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.
Now it should be fixed :) -- closing.
Matt K committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/8d3092eaea3fba2b96318d09722ca15b75a5b467 tdf#117651 Fix AutoCorrect support for italic, strike, bold, and underline It will be available in 24.2.0.0.beta2. 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.
Matt K committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/127ec9a20d837775bf46714dba9eccda62b12dde tdf#117651 Fix AutoCorrect crash for italic, strike, bold, and underline It will be available in 24.2.0.0.beta2. 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.