Created attachment 61437 [details]
Same document saved as DOCX, style on the number in list is gone

Confirmed with LibO 3.4.5 and LOdev version 3.6.0alpha0+ (Build ID: 34513fe) under Windows Xp and Vista 64.

The XML in word/document.xml for the paragraph in the example document is as follows;

    <w:p>
      <w:pPr>
        <w:pStyle w:val="style0"/>
        <w:numPr>
          <w:ilvl w:val="0"/>
          <w:numId w:val="1"/>
        </w:numPr>
      </w:pPr>
      <w:r>
        <w:rPr>
          <w:b/>
          <w:bCs/>
          <w:sz w:val="36"/>
          <w:szCs w:val="36"/>
        </w:rPr>
        <w:t>Foo</w:t>
      </w:r>
    </w:p>

If I put a copy of the w:rPr block inside the w:pPr block, the number gets the right style!

I'm afraid I don't know the LibO code though..

Under v4.3.0.2 Build ID: 14ed55896fdfcb93ff437b85c4f3e1923d2b1409 the problem persists and affects the identifiers of ordered lists created both via direct formatting (toolbar) and using paragraph / list styles.

Opened attachment 61436 [details] and placed cursor at the end of the paragraph and pressed Enter twice then saved as docx.  When the document is reopened, the number in the list has kept its formatting.  However, the empty paragraph below the numbered list has now lost its formatting.

1. New Text Document.
2. Change to Font Size 18 and Bold.
3. Turn on Numbering.
4. Type "test1" and Enter.
5. Type "test2" but don't Enter.
6. Save as docx.
7. Close and reopen document.
Result:
Number 2 in the list has lost its formatting.

1. New Text Document.
2. Change to Font Size 18 and Bold.
3. Type "test" and don't Enter.
4. Save as docx.
5. Close and reopen document.
Result:
"test" still has its formatting.

1. New Text Document.
2. Change to Font Size 18 and Bold.
3. Type "test" and Enter.
4. Save as docx.
5. Close and reopen document.
Result:
Emtpy paragraph below "test" has lost its formatting.

I think this bug is to do with the last paragraph in the document losing its formatting if it is empty and somehow this affects the last paragraph in a numbered list if it is also the last paragraph in the document.

Version: 4.4.2.2
Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6

Confirmed still exists in 6.1alpha. Confirmed comment 5 - this is not related particularly to numbered lists - the last empty paragraph looses formatting.

This looks like an import problem, since MSWord 2003 reads the .docx just fine. Caused by ~DomainMapper_Impl calling RemoveLastParagraph. Calling "dispose" instead of "setString" works.  See bug 58327.

Created attachment 139078 [details]
lastEmptyParagraph.odt: save as .docx looses the 96 pt paragraph size

This ought to be super easy for someone who understands unotext well. Unfortunately, it completely baffles me.

I don't understand why just exchanging the string would remove all the PropertyValues in the first place.  Even so, I would think it should be trivial to get a copy of the PropertyValues, and then re-apply them afterwards (maybe with finishParagraph?). But even these trivial tasks were too much for me.  Very frustrating.

Tried again - still no luck.  For next time, make sure you don't go down the rabbit trail of looking for xTextAppend->getString() == SAL_NEWLINE_STRING because that doesn't solve the problem with OP's document.

Version: 6.1.4.2
Build ID: libreoffice-6.1.4.2-snap1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-CA (en_CA.UTF-8); Calc: group threaded

When working with .docx files, I see formatting being removed from the numbers in numbered lists even when it's not the last paragraph. It seems to happen sometimes when typing.

Steps:
1. New document
2. Change the font (e.g. to Arial 20pt)
3. Start a numbered list using F12 or the "Toggle Numbered List" button from the Formatting toolbar
4. Type some rows:
    1. one
    2. two
    3. three
    4. four
    5. five
5. Save as .docx
6. Close and reopen file

Observations:
1. The "5." is now Liberation Serif 12pt, unlike the other list numbers.
2. If you click at the end of row 2 and press <Enter>, the "2." also reverts to Liberation Serif 12pt. Same with any of the other rows.
3. Paste Special > Unformatted text at the end of a row will also cause the list number to revert to Liberation Serif 12pt.

This <Enter> behaviour happens even if the numbered list was not the last paragraph in the document.

Also, if there is enough text in the rows to wrap multiple lines, then after reopening the .docx, even sometimes just typing some text is enough to trigger the formatting change behaviour. But this is very inconsistent and it doesn't happen every time.

This particular case happens every time for me, though:

Steps:
1. New document
2. Set font to Arial 10pt
3. Start new numbered list
4. Type "Please prepare the mortgage referencing Standard Charge Terms No. 200033 and with our additional provisions (attached)." and press <ENTER>.
5. Fill out the next several lines with some placeholder text, just to have more rows to play with.
6. Save as .docx
7. Close and reopen file
8. Replace "200033" with "${terms_number}"
9. Click elsewhere

Observations:
1. The "1." reverts to Liberation Serif 12pt.
2. Interestingly, unlike the formatting reverts caused by <Enter>, the above typing formatting change cannot be reverted with Undo.

Created attachment 148346 [details]
2019-01-15 Numbered list example, ODT version

Created attachment 148347 [details]
2019-01-15 Numbered list example, DOCX version

Created attachment 148349 [details]
2019-01-15 Numbered list example, before and after

This looks definitely like an import problem. Opening a / the test document in Word, works correctly. Creating a test document in Word and opening it in Writer has the same problem. From my POV the XML in either the Writer export or the Word export looks the same.

So I can also confirm the two problems:
1. On open, the last numbered item always has the default wrong formatting
2. In a multi-item document, adding a new item by pressing enter anywhere in an existing / correct item, changes the old numbering item to the broken default and interestingly creates the new item with the original / correct format.

Created attachment 153927 [details]
Document nodes diff between odt and docx.

(In reply to Justin L from comment #7)
> Confirmed still exists in 6.1alpha. Confirmed comment 5 - this is not
> related particularly to numbered lists - the last empty paragraph looses
> formatting.
> 
> This looks like an import problem, since MSWord 2003 reads the .docx just
> fine. Caused by ~DomainMapper_Impl calling RemoveLastParagraph. Calling
> "dispose" instead of "setString" works.  See bug 58327.

AFAI can currently tell, the RemoveLastParagraph is really not the problem. The formatting of the list item is.

You can see this, if you make an full round-trip by opening a broken docx and save it as an odt and reopen it. The resulting document is correctly handled by Writer again, just like the original. You can even add breaks to multiple items with different formatting in the docx, save that and the odt document will look as the docx was expected to look in the editor.

My current conclusion: some meta-information is missing somewhere between the imported docx document structure and the Writer layouting. Unfortunately this makes the fix even harder - at least for me.

One probably good thing: the diff of the layout.xml between the odt and docx is zero (minus the obviously changed memory pointer values), so the layout seems to be equal.

And for the attached nodes.xml diff (SW_DEBUG=1 soffice and Shift+F12, if you want to reproduce): I don't yet know what the meaning of using SwpHints instead of SwAttrSet is, but it's somehow partly interchangeable and seems to correctly survive the full round-trip.

There was a patch to fix bug 64222. This kind of mutated this bug, as the import is now correct, but interestingly the removal of the direct formatting of a numbered item now won't restore the original number format, but just for a DOCX document and just if it's not the last item. Saving that "broken", edited DOCX as an ODT and opening that document, fixes the number again. Saving as a 2nd DOCX doesn't help the number format.

This kind of proves my suspicion, that for the DOCX import some connection between the direct formatting and the number format is missing while displaying / editing the DOCX in Writer.

There was a 2nd patch for bug 64222 to fix a regression introduced by the first patch. This fixes this bug as far as I can tell. But there is still a bug for editing the the DOCX numbered item, where changing the items font (type, size, underline, italic, etc.) won't be reflected in the number, if the value was overridden in the ODT. For all non-overriden values, changing the item is also reflected in the number. I think this is the consequence of the different representation in the internal nodes, already visible in the attached diff.

But I consider this a completely different bug, as actually both described bugs in comment 1 and comment 11 (wrong import and wrong item breaks) are fixed now.