Still present in 3.5.1-1.

reproducible with LO 4.3.1.2 (Win 8.1)

If I copy text from anywhere in this attached document then I can reproduce it.  But if I copy it first to the Windows Editor and then from this Editor to LO then everything is fine.

Still reproducible in 4.4.2.2

I reproduced this from scratch by taking a numbered list and applying various indents to it from the Sidebar.

Action/Formatting lost?
increase indent -> no
switch to hanging indent -> yes
before text indent -> yes
first line indent -> yes

It reverts back to the default position and spacing as seen in Bullets and Numbering -> Position tab from the context menu.

Paste Special -> Unformatted Text does not cause the numbered list to lose its formatting.

Version: 4.4.2.2
Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6

Reproduces with 6.0.0.2 (x64).

I also ran into this issue while working with lists within paragraphs which have indent before text.

Additionally I work much with marginal note in indents before text. A list style can't assigned to both paragraphs with indents and paragraphs without (or another) indents because the list style overwrite the paragraph attribute. You have to create a list style for a paragraph with indent and a second one for a paragraph without indent (or another indent). This is ridiculous.

I find that a list style should be "put on" a paragraph as you can't use a list without a paragraph--every list item is also part of a paragraph.

Example of content.xml with a list style (Numbering_20_ABC) and a direct formatted list (L1):

<style:style style:name="P1" style:list-style-name="Numbering_20_ABC" style:parent-style-name="Hanging_20_indent" style:family="paragraph"/>
<style:style style:name="P2" style:list-style-name="L1" style:parent-style-name="Hanging_20_indent" style:family="paragraph"/>

For all attributes that exist in paragraphs and lists, the list attributes should add their values to the attributes of the paragraph and not overwrite them.

With that you could use a list style on different paragraph styles.

@Regina:
Is it possible to change the behavior of lists (and list styles) so that they don't overwrite indents and other attributes of the parent paragraph and only add their own indent/alignment/margin/attribute?

(In reply to Thomas Lendo from comment #6)
> 
> For all attributes that exist in paragraphs and lists, the list attributes
> should add their values to the attributes of the paragraph and not overwrite
> them.
> 
> With that you could use a list style on different paragraph styles.
> 
> @Regina:
> Is it possible to change the behavior of lists (and list styles) so that
> they don't overwrite indents and other attributes of the parent paragraph
> and only add their own indent/alignment/margin/attribute?

I think, that a change is not possible and not needed.

The conflict between list and paragraph is only in the attributes fo:margin-left and fo:text-indent. Any other influence of list numbering on paragraph is an error.

The spec explains it in section 17.20. <style:list-level-label-alignment>, 19.237 fo:margin-left and 19.246 fo:text-indent. The problem might be, whether inherited values of fo:margin-left and fo:text-indent for the paragraph also fulfill "paragraph style specifies fo:margin-left and fo:text-indent". LibreOffice denies this.
Therefore the rule "paragraph overrides list" is only applied, if the list style is directly referenced by the paragraph style. In UI you get this, if you select the list style in the Outline&Numbering tab of the paragraph style. The automatic numbering produces a similar structure. As long as you change the indent of all paragraphs in the list at the same time, this structure is retained.

The fact, that inserting into a list item changes its automatic paragraph style, is a special problem with the attached document. Inserting sets a new automatic paragraph style without own fo:margin-left and fo:text-indent here. I have no idea, what is wrong with the attached document. I cannot produce it from scratch and if I use "Save a copy" with the attached document, and then test the behavior on the copy, I do no longer see the error. I have made the tests with LO 6.1. The document is from LO 3.4. Perhaps some compatibility setting?

Regina, thanks fo your comment. I had not only the attachment of this report in mind but list/paragraph interference in general. 

So what should be done with the attributes fo:margin-left and fo:text-indent in the case I described in comment 6? List indent should be additionally added to paragraph indent (in my view) and not override para indent. I think of paragraph-agnostic list styles. I see no sense in lists that define margin and indent when paragraphs do that already.

Assigning a list to a paragraph in the para dialog complicated the list/paragraph behavior and is no solution for Benjamin. Or I'm working with Writer not as intended and I should change that and create own paragraph style with assigned list style for every indent variant I have. I'll create a new test document.

Hi Thomas, that is a general discussion and should not be here in this bug report in Bugzilla. This bug report is only about the curios behavior of the attached document.

I can reproduce the issue with the attached document and a completely new document created with LibO 6.1.0.0.alpha0+ from 2018-01-09_01:20:44. It's a problem that is caused by the indent.

Steps to reproduce:
1) Open a new Writer document.
2) Insert 3 lines of text.
3) Assign a list style from the Styles sidebar to the 3 lines.
4) Select the 3 list lines and open the paragraph dialog (context menu > Paragraph...)
5) Go to Indents & Spacing tab.
6) Change the value "Before text".
7) Copy the first line and paste it into the second line.

Actual result:
The indent of the second line changes.

Expected result:
Only the text is added without changing the formatting. Especially because the text with the same style and direct formatting has been pasted.


You can test that the attached document has been changed by direct formatting (DF) when using Ctrl+M to the whole content. Without that DF then the problem doesn't occur anymore.

Sorry for not reading all, but this simply works in 6.4+, probably 6.2.7 also.

Already in 6.1.

*** This bug has been marked as a duplicate of bug 101534 ***