Bug 140057 - Paragraphs in Writer do not behave according to their format specifications, either default or when overridden on a per paragraph basis
Summary: Paragraphs in Writer do not behave according to their format specifications, ...
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.3.1 release
Hardware: x86-64 (AMD64) macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-01 13:01 UTC by irrevdjohn
Modified: 2021-08-28 14:41 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description irrevdjohn 2021-02-01 13:01:16 UTC
Description:
This may be linked to the format shortcut keys, e.g. Command-1 for Heading 1.

When I create a new Heading 1 with the shortcut, on completing the line and pressing <Enter>, the style name for the next new line (Text Body) appears correctly in the menu bar drop-down. However the formatting of the characters remains as if it was a Heading 1. I have to click menu > Format > Clear Direct Formatting for the correct styling to take effect.

Moreover, the Text Flow property for the Heading 1 paragraph, ‘Keep with next paragraph’, does not take effect at the bottom of a page.

I noticed this behaviour a number of times in release 7.0.3.1. The aberrant paragraph continued to misbehave when the document was re-opened in 7.0.4.2. But when I used the same shortcut again to re-style the Heading 1, it then behaved properly.

Steps to Reproduce:
1. In Writer, use shortcut Command-1 to change a paragraph style to Heading 1.
2. Write the text of the heading and press <Return>.
3. Try writing the Text Body paragraph that you should now be in. It appears in the format of the heading, although the paragraph style is Text Body.
4. Towards the bottom of the page, add another Heading 1 para in the same way, followed by a Text Body para. The Heading 1 is not kept with the Text Body but a page break occurs between them.

Actual Results:
As previously described.

Expected Results:
As previously described.


Reproducible: Always


User Profile Reset: No



Additional Info:
[Information automatically included from LibreOffice]
Locale: en-US
Module: TextDocument
[Information guessed from browser]
OS: Mac OS X (All)
OS is 64bit: no
Comment 1 Dieter 2021-02-16 06:36:19 UTC
I can't confirm this with

Version: 7.1.0.3 (x64) / LibreOffice Community
Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded

To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile (https://wiki.documentfoundation.org/UserProfile) and re-test?
=> NEEDINFO
Comment 2 QA Administrators 2021-08-16 03:50:19 UTC Comment hidden (obsolete)
Comment 3 irrevdjohn 2021-08-18 15:44:10 UTC
This is still an intermittent bug in 7.1.4.2 for Mac.

I have just been editing a new document created from a template. Most of the Text Body paragraphs behave properly after an H1. However, there is one place where <Return> after an H1 produces a para where Text Body is indicated in the drop-down of the Formatting toolbar, and in the Styles and Formatting sidebar, yet the characters continue in the larger font size and bold feature of the previous H1. This aberrant behaviour continues indefinitely for successive paras.

The problem resolves if I highlight the offending H1 and click Format > Clear Direct Formatting. But I never directly formatted the H1 in the first place!

I have double-checked the template, and can find no problem with it. It is a very bare bones template with a single H1 paragraph. My finished document contains many H1s and other paragraph types. Yet only one displays this peculiar behaviour.
Comment 4 irrevdjohn 2021-08-18 17:34:33 UTC
Further to my previous comment, I have come to the tentative conclusion that there may have been a problem in the template file, since other weird formatting errors occurred in documents based on it, e.g. a text format applied ad hoc to an entire paragraph of a built-in style would be applied across the board to all other paragraphs of that type. Paragraphs that used custom styles could have Format > Text > (style) applied with no knock-on effects.

Today I have re-built the template from scratch, and so far have had no further formatting problems.
Comment 5 Dieter 2021-08-28 14:41:54 UTC
(In reply to irrevdjohn from comment #4)
> Today I have re-built the template from scratch, and so far have had no
> further formatting problems.

Good news! So let's close this bug.
=>RESOLVED INVALID