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. ***