LibreOffice Writer - Bold activates by itself

users
#1

I have found a strange action by Writer. I think it might be a bug, but I'm
not sure. At the moment I'm using LibreOffice Writer 4.2.6.3. But, I have
verified this also in 4.3.1.1, 4.3.1.2, 4.3.2.2, and 4.3.3.2.

In a Writer text document, on a blank line, do this:

1. Turn on Bold either by Ctr+B or by toolbar button.
2. Type some text in bold font.
3. Before pressing Enter, Type Ctl+B to turn bold off.
4. Press Enter two times.
5. Press the Up arrow one time.
6. Look at the Bold toolbar button, Bold will be back on.

I just tested LibreOffice 3.5.4.2, and OpenOffice 4.3.1, both of those do
not act this way.

#2

Hi,

I have verified this in 4.4.0.0 alpha and 4.3.2.2 under Fedora 21

I can also see that the problem is NOT apparent under XP on 4.2.0.4.

What OS are you using?

Cheers

#3

I seem to recall that this has always been the case, at least under Linux
Mint with various versions of LibreOffice. Interestingly, if on the second
line one puts some text (not in bold as one would expect) and then do
newline and move the cursor back up to before the text on line two it shows
bold as being off. (I have to say that one thing which I miss in Writer
and also in Word, when I used it, is the approach that WordPerfect used (or
maybe still does if it still exists) whereby one could see the codes that
switched bold, and underlining etc. on and off. One could then see exactly
where the bolding started and stopped.)

Graham

#4

Hi :slight_smile:
It does sound like a bug and maybe worth posting a bug-report about it
before it settles in for the long haul! Go for it! :slight_smile:
Regards from
Tom :slight_smile:

#5

Hi :slight_smile:
Ahh, you reminded me! Yes i used to like that feature of Wordperfect a LOT
too. With Writer and Word i've always tended to switch on the backwards P
to show all non-printing characters. It doesn't go quite as far as Wp did
but it's still a huge help.

Errr, most people seem to hate seeing those characters and seem to think
Writer is broken when they see them on my screen or see it as proof that
Writer is unusable. So i have to switch them off a lot of the time, when
working with others :frowning:

You seem to be the first person saying that you have seen the odd behaviour
in other versions of LibreOffice. Are you sure you switched Bold off?
Regards from
Tom :slight_smile:

#6

Tom,

yes, I switch off bold. What is not clear to me at all in Writer (and in
Word) is to what character the codes switching on and off bold etc. are
attached. I write every now and then texts with mathematics in them and
variable names are always in italics. Sometimes I want to change a name,
say from x (italic) to ax (italic). The way I did it in WordPerfect was to
put the cursor before the x and type an a - very easy. In Writer you
cannot do that, as you get a normal a and not an italicised one. I would
then guess that the on and off codes are stuck to the next character, which
might explain the behaviour mentioned by the OP. I doubt somehow that this
is a bug.

Graham

#7

Hi :slight_smile:
Yeh, i'm now on Ubuntu 14.04 with LO 4.2.6 and do have the problem but
earlier on 3.5.7 i wasn't getting it.

Hmm, is this something to do with styles? Is it that the style is staying
the same and so the boldness is staying on?
Regards from
Tom :slight_smile:

#8

You have to realize that ODF uses an xml-based markup system, not a
formatting codes system, as Wordperfect did. When you apply a bold style to
a snippet of text, you are essentially creating a markup (greatly
simplified) <span style="bold">snippet</span>. When you change the style to
normal, you are telling LO "make the next snippet on this line normal".
When you hit the return button, you are essentially saying to LO, "close
this paragraph", causing LO to add a </p> piece of markup. However, LO also
remembers the style of the last entry on the line, and applies it to the
next paragraph as well. To see this in action, perform jerryb's procedure,
but type some text in normal style after the bold text on the first line.
You will see the normal style applied to the next paragraph.

#9

"What OS are you using? "

I was using Xubuntu-14.04.

#10

"However, LO also remembers the style of the last entry on the line, and
applies it to the
next paragraph as well. To see this in action, perform jerryb's procedure,
but type some text in normal style after the bold text on the first line.
You will see the normal style applied to the next paragraph. "

Indeed, you are right. If, after turning bold off at the end of the first
line. I press Enter once, then press Space once, then press Enter once more,
then press Up one time, the Bold does NOT come on.

I still think this is a bug and not normal. By manually turning Bold off at
the end of the first line, it should stay off until it is manually turned
back on. I tend to think that it should never come on automatically, unless,
like someone said, it is embedded into a style.

#11

I do not get the same results, but maybe I am doing things differently in 4.2.7 and 4.3.3:
Ctrl+B to made the line bold.
Type some words.
Ctrl+B after typing the last character.
Enter once.
Type some words.

      This last line is NOT bold. Maybe you should not be typing <Enter> twice.

Dan

#12

I just did the same as Dan and got the same results. When I press Ctrl+B at the end of a line, LO respects that choice when I get to the next line, and doesn't apply boldface.

I did this with LO 4.1.5.3 on Win7.

Virgil

#13

I just did the same as Dan and got the same results. When I press Ctrl+B at the end of a line, LO respects that choice when I get to the next line, and doesn't apply boldface.

I did this with LO 4.1.5.3 on Win7.

Virgil

the fact remains that if you press enter twice (whether intentionally or otherwise) the first blank line is bolded. From what I can see the problem occurs between 4.2.3 and 4.2.4 (RPM version).

Jerry would you like to file a bug report? If not I am happy to jump onto bugzilla tomorrow

Cheers

#14

Hi :slight_smile:
Good plan!

The change in behaviour might be the first sign of some bigger problem that
crept in recently - or it might be completely harmless and just be a minor
annoyance. Posting a bug-report might help the devs quickly spot which way
it's likely to be, or leaves them with a marker for when the problem first
appeared.

If you post a clickable link back to this thread then maybe someone here
can help add something useful later on.
Regards from
Tom :slight_smile:

#15

Yes, I just tried it on LO 4.2.6.3 on my Ubuntu 14.04LTS partition and it behaved as you described. I didn't even have to insert two blank lines. It just ignored my attempt to turn off Bold (using Ctrl-B) at the end of the first line.

Interesting.

Virgil

#16

timllloyd wrote

I just did the same as Dan and got the same results. When I press
Ctrl+B at the end of a line, LO respects that choice when I get to the
next line, and doesn't apply boldface.

I did this with LO 4.1.5.3 on Win7.

Virgil

the fact remains that if you press enter twice (whether intentionally or
otherwise) the first blank line is bolded. From what I can see the
problem occurs between 4.2.3 and 4.2.4 (RPM version).

Jerry would you like to file a bug report? If not I am happy to jump
onto bugzilla tomorrow

Cheers

Virgil, if you are willing to do that, please go right ahead. I've never
done that, so am not experienced at it. I don't mind if you do.

Thanks to everyone who verified what I was seeing. At first I just wasn't
sure if it was normal or not, but it did seem odd.

Yes, to see the problem you must press Enter two times after turning bold
off at the end of a line of bold text.

Cheers,
jerry

#17

Hi :slight_smile:
It was Tim who offered to post the bug-report. I am sure both Tim and
Virgil understand who your thanks are aimed at :slight_smile: Such confusions easily
arise on mailing-lists and both are very experienced with these sorts of
things. :slight_smile:

Posting a bug-report is not as difficult as it sounds. There are various
guides and differing opinions on how to post a perfect bug-report but the
basic thing to remember is that it's always possible to add more to your
bug-report later so your first attempt does not have to be perfect, or even
good. Also there is a team of QA personnel who help triage bugs and are
usually happy to help newbies improve their bug-reports. After doing your
first report the documentation on how to post a perfect report might make
more sense and might help you improve yours.

The bug-report itself is much like posting an e-mail. You just need to
write a good subject-line, maybe copy&paste the one you used for this
e-mail thread or maybe tweak it to something like "Bold stays activated
even after being switched off".

First thing is to register at the bug-reporting website. This is the bit
that puts most people off but it's really not that tough. You have made it
to this list and registered at Nabble so registering at the bug-reporting
place should be much easier for you. Once you have registered it's easier
for any other issues you might spot in the future or to add helpful
comments to the bug-report that gets posted about this issue.

These guides help. Both aim at helping you post a perfect bug-report so
don't worry too much about trying to do everything they say. Some people
find the 1st link more useful because it's a nice pretty gui that helps
point&click users by hiding most of the options;
https://www.libreoffice.org/get-help/bug/

Other people find the 2nd link more useful for exactly the same reason (ie
that it doesn't hide anything and allows more flexibility);
https://wiki.documentfoundation.org/QA/BugReport

If you do go for it you can always ask us for help and advice if you do get
stuck but i think you'll be surprised at how much easier it is than the
guides or reputation makes it sound! :wink:
Good luck and regards from
Tom :slight_smile:

#18

ok, bug logged:

https://bugs.freedesktop.org/show_bug.cgi?id=85943

#19

"It was Tim who offered to post the bug-report. I am sure both Tim and
Virgil understand who your thanks are aimed at :slight_smile: Such confusions easily
arise on mailing-lists and both are very experienced with these sorts of
things. :slight_smile: "

Oops!

Good encouragement, thanks Tom.

I'll try it next time.

j.

#20

timllloyd wrote

ok, bug logged:

https://bugs.freedesktop.org/show_bug.cgi?id=85943

Tim, thank you for posting the issue to Bugzilla. As it turns out, Urmas
had gotten to it (if a bit terse) with fdo#85876
<https://bugs.freedesktop.org/show_bug.cgi?id=85876> issue will be tracked
there, and the 85943 bug is resolved as a duplicate.

Stuart