When, for example, I am typing a bold word that I want to follow with punctuation, I hit Ctrl-b to begin the word. I type the word. And then I hit Ctrl-b to end the word, and type the (non-bold) punctuation. I just think it looks better that way. But this reveals a flaw. Because often, when I hit that Ctrl-b (or any other text style shortcut, such as Ctrl-i) it un-bolds the preceding word. Not a whole phrase. Only the last word. Sometimes it behaves correctly, and lets me continue with normal typeface after the bold word. I haven't taken the time to isolate that behavior. It seems like that is a special case, and the default behavior is to un-bold the word I am ostensibly still typing. I guess the software can't spell, so it doesn't know I am thinking that I am at the end of the word. To my way of thinking, if I hit Ctrl-b after a space, that is the same thing as inserting a <b> tag. And if I hit Ctrl-b again (because I am inside the <b> tag) it should insert a </b> tag for me, context-agnostically. I would think an app as sophisticated as LO could parse its own HTML tags, and make sure they are nested properly. I am not assuming it does that, just comparing my own thought paradigm with the observed behavior. Thank you for your attention to this. It's just a paper cut I've struggled with over the years, and found less efficient workarounds for, such as going back and selecting the word with the mouse, and clicking the "B" button. Sorry my report is not super-detailed. On the other hand, I think this is a fairly straightforward issue.
Thank you for reporting the bug. I can not reproduce the bug. Build ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77 CPU threads: 2; OS: Windows 6.1; UI render: default; Locale: en-US (en_US); Calc: group
The simplest way to reproduce this bug (and I am on Ubuntu 18.04 and 18.10, but I have had it on every version for several years) is simply to hit the key sequence for a font weight change, e.g. Ctrl-B or Ctrl-I, type a word, and then hit the key sequence again before hitting the space bar. The word will switch back to normal weight. LO behaves as expected when highlighting a word and using a control sequence, or changing the font weight in other ways. It is only when you use the control sequence in the middle of typing the word that it behaves abnormally.
This is still not fixed in 6.1.2.1.
(In reply to Coburn Ingram from comment #2) > The simplest way to reproduce this bug (and I am on Ubuntu 18.04 and 18.10, > but I have had it on every version for several years) is simply to hit the > key sequence for a font weight change, e.g. Ctrl-B or Ctrl-I, type a word, > and then hit the key sequence again before hitting the space bar. The word > will switch back to normal weight. I cannot reproduce. The word stays bold. I know you said you've seen this over the years, but maybe try in Safe mode. Help - Restart in safe mode and then Continue in safe mode. Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away. Arch Linux 64-bit Version: 6.1.4.2 Build ID: 6.1.4-4 CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: bb30e9e591d5f9f913b3cd8fbaa3c5e412b509bd CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 23 January 2019
Yes it goes away in Safe Mode. But I have had this problem on every version of LibreOffice/OOO I have used for the last decade or more, on more than one platform. It still persists. Have you tested on Ubuntu?
(In reply to Coburn Ingram from comment #5) > Yes it goes away in Safe Mode. > > But I have had this problem on every version of LibreOffice/OOO I have used > for the last decade or more, on more than one platform. It still persists. > > Have you tested on Ubuntu? I asked on IRC and got a tip that you should test in normal mode, but with automatic spellchecking turned off (from Tools menu or Shift-F7).
Now I cannot reproduce the bug, in 6.1.4.2, on Ubuntu 18.04.1, in the document I was having trouble with. Spellchecker makes no difference. I will do a little more checking but it seems to have gone away.
(In reply to Coburn Ingram from comment #7) > Now I cannot reproduce the bug, in 6.1.4.2, on Ubuntu 18.04.1, in the > document I was having trouble with. Spellchecker makes no difference. I will > do a little more checking but it seems to have gone away. Thanks for retesting with the latest version. Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.