Partial deleting of text in numbered list is causing wrong new numbering

[Valentin_K]

We’ve faced quite strange behaviour of numbering list when some text is deleted.
Pre-conditions:

1. LibreOffice Writer version: 7.6.7.2
2. ‘Show Tracked Changes’ option is enabled.

Based on Release Notes for the version 7.6.7.2 LibreOffice 7.4 Community: Release Notes - The Document Foundation Wiki
Numbered list items in edited text expected to be like that:

Could please someone check such a scenario, is that a bug? TIA.

Original and resulted (edited) text screnshots are in comment below the question.

[Valentin_K]

Original text:

[Valentin_K]

Edited text:

[ajlittoz]

You did not tell how you created your numbered list. If your list does not use a list style and is the result of Tools>Bullets & Numbering or the equivalent toolbar button, you fall under a badly specified Word-compatibility feature. In this mode, Writer must guess where a list instance starts and ends. In the majority of cases where you type your text sequentially, everything works fine. But if your list was made through “erratic” edits, i.e. you type some text outside the list, you then come back inside your list, (add a few other iterations to make things worse), then Writer is lost. It likely breaks your list into semi-independent bits individually numbered.

The only reliable way to maintain numbered lists is to apply a list style which will isolate your list from the dreaded “one-size-fits-all” feature mixing all lists together whether bulleted or numbered.

Unfortunately, list styles are not trivial at all.

[EarnestAl]

It looks to me as though you have backspace deleted the number in what used to be item 3 so it is now not numbered.
Either that or there is a line break so that previous item 3 is now part of item 1

Using your example, if I select from the start of item 2 to the start of item 3 and press either Delete or Backspace then Item 2 is deleted, item 3 and below are renumbered correctly.

TrackChanges121172.odt (34.4 KB)

Version: 7.6.7.2 (X86_64) / LibreOffice Community
Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5
CPU threads: 8; OS: Windows 10.0 Build 26100; UI render: Skia/Raster; VCL: win
Locale: en-NZ (en_NZ); UI: en-GB
Calc: CL threaded

[Valentin_K]

@ajlittoz @EarnestAl Thanks for your responses.
Finally i’ve double checked and described a cases how to reproduce. Attaching a document with description.
So the main question is why numbered list edited in MS Word in Track Change mode (some items and text been removed) displayed differently in LibreOffice Writer?
Is there any trick or workaround how to avoid the difference?
Track changes with numbered list issue.docx (338.0 KB)

[ajlittoz]

Unfortunately, you provided screenshots without enabling View>Formatted Marks to see exactly what was erased and added. Screenshots don’t give access to existing formatting directives.

Writer IS NOT Word. Your document is saved .docx (obviously because it is created with Word). Consequently, it requires a conversion when read by Writer. DOCX and ODF are not equivalent formats. Most constructs beyond the most common, e.g. a paragraph, must be translated to a collection of partial directives, the set of which emulates the original formatting.

List numbering is one of the features where both suites differ most. In the Single item removed case, if you have any remnant for the “erased” item, e.g. some space after the last word as is very common in lay Word users, the item still exists. The matter is made more difficult by “compatibility rules” added to “fix” so-called “intuitive” behaviour (in fact, flaws in using a document processor) which modify the interpretation of text behind the scene.

Without formatting marks, I can’t tell if your list item reduces to a space in which case (due to frequent misuse in Word) the item still exists but is not numbered.

It is also possible you erase the item starting from left of “Non-medicated” with Bksp where you create an unnumbered item (“Non-medicated”) in addition to deleting previous text.

In the *Single item+some text" case, you may bump into another problem: knowing the limit of a list. Word has no notion of styles beyond the paragraph ones. Consequently, it relies on some heuristics to guess where a list starts and ends for the purpose of restarting numbering. Writer has list styles which clearly delimit occurrences of lists (but this can’t be forwarded to .docx). Failing list styles, Writer plays guess game about list extension. This guess is highly dependent on edit history, i.e. the order in which text was typed. If it was done out of order, you may end up with this situation.

For better analysis, provide a 2-page sample of your original document.

[Valentin_K]

TrackChanges121172_3.docx (15.4 KB)
TrackChanges121172_2.docx (15.5 KB)
@ajlittoz here is these 2 files.
If I understood correct .ODF is the only native format for Writer? I.e. if DOC, DOCX or RTF files are opened Writer is making emulation of it.
So appreciated for your time spending on analysis and explanations!

[ajlittoz]

Let’s start by the simpler document …_3.docx with "full-paragraph deletion. I dumped the file as .fodt to see how Writer understood DOCX.

First surprise: two converted list styles are mixed, WWNum2 on the first item, WWNum1 on the others. First paragraph “Chemicals” has forced list item starting value 1, good. But next item which passes under WWNum1 (an independent list style in theory) has no forced starting value, thus it should be numbered 1. However, this is a deleted item.

Deletion begins after the start of the list item marker and ends after the bookmark, before “Non-medicated”. This deletion encompasses the first closing list item marker and the second opening list item marker. Consequently, the first list item marker (before “Paints”) should be active for “Non-medicated”.

I have no idea how Writer behaves when a list item marker thus spans several (deleted, though) paragraphs as list property (for numbering effect) involves a single paragraph. Since deletion twists the neat XML nesting of directives, the net effect may be creating an unnumbered item (personal guess).

Things revert to “normal” on next paragraph “Industrial”.

---

Document …_2.docx exhibits a different behaviour with partial paragraph deletion. Again I examined Writer-created XML.

I’d say thing are more compliant with my understand of the list feature in Writer.

First item is under WWNum2 control. We then have a deleted item until start of “Non-medicated”. This item is controlled by WWNum1. Though we have the same nesting, deletion wiped out the list marker before “Non-medicated” and from my understanding (which is not developer’s) this results in an unnumbered item.

Next paragraph “Industrial” is a full paragraph with its WWNum1 list marker. It is the first one met; therefore I agree with number 1. which is the “natural” starting value for this new list.

I don’t understand why “Pharmaceuticals” shows up as unnumbered. The deletion markers (opening and closing) don’t contain paragraph start, thus don’t interact with the list marker. Despite this, the item is unnumbered despite being a continuation of WWNum1.

After that, “Common” and “Machines” have the expected numbers (according to my understanding).

---

I think you’re facing a very subtle bug. You should submit a report, attaching your 2 sample documents and explaining clearly the problem. Attaching also a Word screenshot to show the difference is certainly a plus to provide a proof.

I am under 25.2.3.2 and I see the same as you.

EDIT 1: I accepted all changes and it does not fix the strange “unnumbered” item. I had to force Format>Lists>Add to List to renumber the item (and automatically all subsequent ones).

EDIT 2: I made other tests this morning, comparing “standard” .odt documents with this .docx converted XML.

Contrary to what I stated above, there is indeed a single list started with text:list …> requesting style WWNum2. What I don’t understand is why items get a style-override=WWNum1. Does this mean there already is some direct formatting done in Word?

Nevertheless, sudden appearance of unnumbered items is a bug.