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

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.

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.

setting importance to high makes no sense - only devs (somtimes) use that field for theit own prioritising

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

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.

Messing up styles in Writer... maybe should be even set as blocker ??

(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 :)

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.

(whops, setting version as per comment 2 too)

would anybody please give us an update with current 4.2.4.2?
if issue persists I'll move it to mab4.2 list

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.

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

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

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

CONFIRMED with LO 4.3.3.2, on Windows 7 x64

CONFIRMED with LO 4.4.0.0_beta2 on Windows 7 x64

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.

(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

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.

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?).

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.

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.

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

Migrating Whiteboard tags to Keywords: (preBibisect)
[NinjaEdit]