Bug 69495 - FORMATTING: Toggling off bold/italic does not turn it off, but instead applies no-bold/no-italic. This messes up any style afterwards that has bold/italic in it (until Clear Direct Formatting is used).
Summary: FORMATTING: Toggling off bold/italic does not turn it off, but instead applie...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: preBibisect
Depends on:
Blocks: mab4.3
  Show dependency treegraph
 
Reported: 2013-09-17 21:28 UTC by Walter
Modified: 2015-12-17 11:00 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
This file demonstrates the error and how to reproduce it (11.96 KB, application/vnd.oasis.opendocument.text)
2013-09-17 21:28 UTC, Walter
Details
Writer document from 4.2.4.2 has surprising boldness (13.37 KB, application/vnd.oasis.opendocument.text)
2014-05-12 21:21 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Walter 2013-09-17 21:28:26 UTC
Created attachment 86025 [details]
This file demonstrates the error and how to reproduce it

Problem description:
The style formatting is effected by previous in-line formatting (eg. the use of Ctrl+B/Ctrl+I/Ctrl+U formatting shortcuts). After I toggle on and off again a BOLD mark, for example, all the successive paragraph styles will have the BOLD attribute disabled, even if set in the global style.

Steps to reproduce:
1. Open a LibreOffice file
2. See that the Heading 1 paragraph style uses a bold type face
3. write some text
4. press CTRL+B
5. write some text (text is in bold)
6. press CTRL+B
7. write some text
8. ENTER
9. Write some text
10. Press CTRL+1

Current behavior:
The new paragraph is set to Heading 1, having all formatting except for the BOLD attribute. The bug is cumulative to all formatting marks. That is, if both CTRL+B and CTRL+I were used, the Heading 1 style would not be BOLD, nor ITALIC.

For it to be able to take the appropriate formatting one needs to press CTRL+M (clear formatting).

Expected behavior:
The Style should be applied as set in the global declaration and not be affected by previous formatting marks.
Operating System: Windows 7
Version: 4.0.2.2 release
Comment 1 Cor Nouws 2013-09-17 21:51:43 UTC
Hi Walter,

Thanks for filing the issue. I see the problem too. (4.1.1.2 on Linux).

Selecting the paragraphs and chosing Ctrl-M (Clear direct formatting) sows the text as intended. But it is a weird problem.

(Should to be looked when the bug was introduced..)

Cheers,
Cor
Comment 2 Terrence Enger 2013-09-18 02:53:24 UTC
Using versions of LibreOffice as new as master fetched 2013-09-03
and as old as ubuntu-natty (version 3.3.4), I see the problem
with bold but not with either italic or underscored.

Terry.
Comment 3 hollandgh 2013-12-15 19:27:13 UTC
I'm having this problem with italics.

The problem seems to be that toggling italics off (or bold, or underline) with the toolbar button or Ctrl+I (or B, or U) does not turn off italics direct formatting but rather *applies* "no italics" direct formatting for new text typed from that point forwards (existing text is not affected). Ever afterwards when typing new text this no-italics direct formatting layers on top of styles until Clear Direct Formatting is used. So if at any point after toggling italics off a style with italics built in is used, the italics in the style won't appear because no-italics direct formatting is layered over top.

This is definitely not the correct behaviour, and not the way any other word processor does it. Toggling direct formatting off should simply turn it off, not apply no-italics heading forward.
Comment 4 Cor Nouws 2013-12-15 20:53:14 UTC
setting importance to high makes no sense - only devs (somtimes) use that field for theit own prioritising
Comment 5 Björn Michaelsen 2014-01-17 09:51:46 UTC
(This is an automated message.)

Setting priority to highest as this is a 4.1 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Comment 6 C Stuart Hardwick 2014-02-16 06:17:27 UTC
I'm pretty sure this is the same problem I see in 4.1 and 4.2.0.4.
I have a large manuscript in which I want to replace all occurances of italics with underline. Superficially, it appears to work, except the underlined sections then show up later when I search for italics again. Then I find some of the italics was not modified, and other blocks of non-italics text get caught up in the search. It may be the same problem, that internall, the style is not being set as I command, but is instead being masked and cluttered up invisibly. This is a pretty big deal for me.
Comment 7 Cor Nouws 2014-02-16 10:57:53 UTC
Messing up styles in Writer... maybe should be even set as blocker ??
Comment 8 Mihkel Tõnnov 2014-02-16 11:07:07 UTC
(In reply to comment #7)
> Messing up styles in Writer... maybe should be even set as blocker ??

Isn't a blocker by definition a bug which blocks a final release until the bug is fixed? In that case, what's the point, as there have been several final releases containing this bug... (</sarcasm>) In any case, the sooner it is fixed, the better :)
Comment 9 Björn Michaelsen 2014-03-08 14:40:51 UTC
The behaviour described in the description is already present since commit  4b9740b4ec3987e1d4d2ad6d20b4dcf996a4fa2 with both bold and italic, so at least all versions of LibreOffice since 3.5 exhibit it.

As per comment 2, this has been this way all the way back until 3.3.4 for bold at least, which I can confirm at least for the bibisect range => NOT a regression.

Comment 2 also claims this used to work for italic/underscore. I cant confirm that: Trying italic/Heading 2, I found the buggy behaviour all the way back to 4b9740b4ec3987e1d4d2ad6d20b4dcf996a4fa2.

If this indeed did break for italic underscore between 3.3.4 and 4b9740b4ec3987e1d4d2ad6d20b4dcf996a4fa2, please file a new bug for that and mark that one as a regression.
Comment 10 Björn Michaelsen 2014-03-08 23:51:58 UTC
(whops, setting version as per comment 2 too)
Comment 11 tommy27 2014-05-12 19:52:18 UTC
would anybody please give us an update with current 4.2.4.2?
if issue persists I'll move it to mab4.2 list
Comment 12 Terrence Enger 2014-05-12 21:21:41 UTC
Created attachment 98945 [details]
Writer document from 4.2.4.2 has surprising boldness

I think that the problem is present in 4.2.4.2, at least for bold.

I typed the attached file pretty much straight through from start to finish.  Font changes within paragraphs are where I typed <ctrl>+B.  For some paragraphs I chose style "Heading 1"; otherwise the font changes at paragraph boundaries are just what the program did.
Comment 13 tommy27 2014-12-08 09:28:48 UTC
please retest with recent 4.3.x or 4.4.x versions and tell if bug persists.
if yes, move this bug to mab4.3 list (Bug 75025) since 4.2.x is END OF LIFE
Comment 14 Robinson Tryon (qubit) 2014-12-08 18:52:21 UTC
TESTING with LO 4.4.0.0.beta2 + Ubuntu 14.04

(In reply to Walter from comment #0)
> Steps to reproduce:
> 1. Open a LibreOffice file

Using attachment 86025 [details]

> 2. See that the Heading 1 paragraph style uses a bold type face

(yes, via Styles and Formatting interface)

> 3. write some text

Add a hard return after "Heading 1 = BOLD" (creating a new paragraph and changing to Default Style).

Write "Foobar Foobar"

> 4. press CTRL+B
> 5. write some text (text is in bold)

write " jazz jazz"

> 6. press CTRL+B
> 7. write some text

write " foobar again"

> 8. ENTER
> 9. Write some text

write "Yep, yep"
> 10. Press CTRL+1

Result: Just the last "Yep, yep" are converted to Heading 1. Bold formatting appears to be correct.

> Current behavior:
> The new paragraph is set to Heading 1, having all formatting except for the
> BOLD attribute. The bug is cumulative to all formatting marks. That is, if
> both CTRL+B and CTRL+I were used, the Heading 1 style would not be BOLD, nor
> ITALIC.

Having trouble repro'ing that with this document
Comment 15 Robinson Tryon (qubit) 2014-12-08 19:12:20 UTC
CONFIRMED with LO 4.4.0.0.beta2 and 4.3.5.1 on Ubuntu 14.04

Simpler repro steps:

- Create a new Writer file
- Verify that Heading 1 is bold:

  - Format -> Styles and Formatting -> Heading -> Heading 1 
  - (right-click) -> Modify -> Font tab
  - See that Western Text Font -> Style is set to "Bold"

- Go to the Style picker -> Heading 1

- Type "This header should be bold", then press ENTER

(for me, the header appears bold)

- Check the Style picker: it should display 'Text Body' now

- Type "Here's the body text <Ctrl+B>this is bold<Ctrl+B> and this is plain", then press ENTER

(for me, this line of text appears plain, bold, and plain, as expected)

- Create a 2nd heading: Style picker -> Heading 1

- Type "Is this header still bold?", then press ENTER

(for me, the header DOES NOT appear bold, even though it should!)

RESULT: Adding the section of bold text removes the bold formatting from subsequent Heading 1 lines.


To further confirm that the bolded section is the problem: add a hard return before and after the word "body" (i.e. before the bolded section), and change the style for the word "body" to be Heading 1. The word will appear (correctly) bold.

Changing mab4.2 -> mab4.3
Comment 16 Walter 2014-12-09 21:41:50 UTC
CONFIRMED with LO 4.3.3.2, on Windows 7 x64

CONFIRMED with LO 4.4.0.0_beta2 on Windows 7 x64
Comment 17 TJT 2015-06-05 19:49:06 UTC
This looks alike a duplicate of a bug I filed many moons ago, #53504.

Seems to be fixed in LO 5 beta1.  Can someone verify?  Tested against RHEL6 / x64.
Comment 18 Walter 2015-06-07 13:04:12 UTC
(In reply to TJT from comment #17)
> This looks alike a duplicate of a bug I filed many moons ago, #53504.
> 
> Seems to be fixed in LO 5 beta1.  Can someone verify?  Tested against RHEL6
> / x64.

Tested on Windows 7 x64, bug fixed for me
Comment 19 Cor Nouws 2015-06-10 06:42:09 UTC
Indeed. Fixed on 5.0.0beta1
Not on 4.4.3.2 - but since the long history and prolly hard to find traces that fixed it, I would revert from asking fixing on 4.4 too.
Comment 20 Michael Stahl (CIB) 2015-06-11 13:10:34 UTC
was curious about this: it's definitely no regression,
can reproduce comment #15 all the way back to OOo 3.0.1

what changed it is this commit:

    commit 3c0805e1f4f4d14e92c7e655d59c87de5c207e48
    Author:     Miklos Vajna <vmiklos@collabora.co.uk>
    AuthorDate: Thu May 14 11:34:33 2015 +0200
    
        tdf#86639 SwEditShell: when setting para style, reset char attrs if needed


but i think it's more of an accident: the "non-bold" would
still be inserted but if you apply "Heading 1" to a paragraph
the character-attributes spanning the entire paragraph will
be deleted (is that intentional?).
Comment 21 TJT 2015-06-11 22:21:00 UTC
I'm not sure, but this may warrant additional thought.  The change fixes the basic issue of styles not being corrupted by previous paragraph-wide settings, But it doesn't completely fix the issue.

Test case:

Create a line w/ a single bold word in the middle using the default text style.

Now set it to Heading 1.

Everything before and including the word is in bold as expected, the rest of the line looses the bold setting.

In most cases, for headings anyway, this shouldn't be an issue since the user probably won't be changing character settings in the middle of text meant as a heading.  But in the case they do, the style application leads to surprising results.
Comment 22 JJ Palacios 2015-06-20 11:01:42 UTC
All platforms, (at least OS X and Ubuntu 15.04) versions 4.3.7.2 and 4.4.2.2 proven

I followed the steps to reproduce.

Current behavior:
The new paragraph is set to Heading 1, having all formatting except for the BOLD attribute. The bug is cumulative to all formatting marks. That is, if both CTRL+B and CTRL+I were used, the Heading 1 style would not be BOLD, nor ITALIC.
Comment 23 tommy27 2015-06-20 15:07:12 UTC
I'll set status back to RESOLVED WORKSFORME since it has been reported to be fixed by different users in LibO 5.0 beta ( see comment 17, comment 18, comment 19 ) 

the fix is not present in the 4.3.x and 4.4.x codelines so there's no surprise about your later tests.

feel free to reopen if after trying LibO 5.0 beta you still see that the issue persists

I also set version to Inherited from OOo according to comment 20
Comment 24 Robinson Tryon (qubit) 2015-12-17 11:00:33 UTC
Migrating Whiteboard tags to Keywords: (preBibisect)
[NinjaEdit]