Could you attach any example documents to allow others to check on different
system/build?

reproducible with LO 3.6.4.3. (Win7 Home, 64bit)

The reason for this bug seemed to be the web link in this line.

reproduced by the following steps:
1. Open WRITER
2. Write four lines (like: "line1", "line2", "line3" and "line4") and format them with font size 16
3. Add some empty lines and then add/type one further line (like "line10") and format it with font size 10
4. Add/type one further line below with a web link (like "lineURL, www.libreoffice.org") and format it with font size 10 and press the enter key after the web link so that the link gets formatted as a link
5. Select the four first lines and go to BULLETS AND NUMBERING from menu FORMAT
6. Choose a numbering type from the tab NUMBERING TYPE (like e.g. the second type "1.")
7. Go with the cursor to the end of line 3, after the text "line3" and press the enter key for a new numbering/line
8. Select the text "line10" and copy it to this new empty numbering "4." from step 7 and this line will now be formatted with font size 10, including the numbering itself
9. Select this line and format it with font size 16 and it will work fine
10. Now go with the cursor to the end of line 2, after the text "line2" and press the enter key for a new numbering/line
11. Select the text "lineURL, www.libreoffice.org" and copy it to this new empty numbering "3." from step 10 and this line will now be formatted with font size 10, including the numbering itself
12. Select this line and format it with font size 16 and the text will be formatted with font size 16, but not the numbering itself, the numbering will keep the font size 10

Created attachment 88134 [details]
List imported from .DOCX can't have font for numbering on first item changed.

It's still possible to get into a case like this with 4.0.x and at least 4.1.2.3 (Ubuntu versions) when working with an imported .DOCX, see new attachment.

On my system with 4.1.2.3 the numbering for the first item in that list is "stuck" as Times New Roman despite attempting to format the whole mess in Arial.  Nondeterminism:  During the first editing session after pasting, most of the list numbering wanted to stay Times New Roman, but after some save, reload, and save cycles it unexpectedly reduced to the first numbered paragraph, which in the underlying XML appears to have the distinction of being broken into multiple text spans.


The original problem document (unfortunately containing private information) was a legal pleading with a lot of structured numbering that, most annoyingly, was stuck as "Calibri" when Calibri isn't even available and was being substituted.  This was first observed with whatever 4.0.x was current with Ubuntu 13.04; I upgraded to 13.10 to pull in 4.1.2.3 in case anything was fixed; unfortunately not.

Hope this isn't bug necrophilia but it seems highly related.

I'm not able to reproduce it with Version: 4.1.3.2
Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a. List items can be manually formatted and the numbering stays consistant. 
@Alexander: could you try with a newer version and confirm that the issue is not present anymore. Thanks -Sophie

(In reply to comment #5)

Still reproducible with 4.2.1.1 under Win7x64 using steps from comment 2. Also reproducible with OOo 3.3.0 and AOO 4.0.1.

Note that probably you will want to copy entire paragraph in step 11, including trailing newline.

However, if I place cursor just to the left of numbering at any numbered line (so that all the numbering is grayed), I see that font size selector shows "12". If I manually select 16, entire numbering (including those items that keep sized small) turns to font size 16. After this step, repeating step 11 from cimment 2 won't change numbering size, it will stay 16. This is tested with all abovementioned versions, as well as with 3.5.2rc2 and 3.6.4.3. I suppose that OP simply didn't know this workaround.

Also, manually setting the numbering size cannot be undone.

As there is no such thing as "unability to fix this", probably this should be removed from MAB? However, as it makes no sense to have lists with inconsistent formatting, this should still be considered a bug. Or, alternatively, a descent UI should exist to control formatting of individual list numbers.

And I knew there was a workaround! If you go to the beginning of the text and backspace (so you delete the #3 in the example, and www.libreoffice.org goes to the #2 line) then push enter it'll recreate the #3 at the right size.

Since there is an easy workaround I am removing this from MAB4.2 list at least for now. Apologies for the noise

Marking as:

Minor - can slow down professional work but will not prevent it (easy workaround)
Medium - bumped up from default "low" because I can imagine it being a bit annoying ;)

note that it was originally placed on MAB list from someone that I don't recognize (perhaps a user...). Probably didn't belong there to begin with had they just said there was a reasonable workaround

Sorry for not following 12 steps from Comment 2 to test, I just ask: is this bug-to-be-fixed at all? 
Apart from simple Joel's workaround, pasting unformatted text looks like a proper way of inserting any new text.

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

Repro using the steps from Comment 2.

Workaround from Comment 12 still works.

(In reply to libreoffice.spam@fodder.homebuilt-lan.com from comment #17)
> 7 years, no fix. Still broken in 6.2.4.2 (x64) and work around given in
> comment #12 does not work.
> 
> See example document.

Two workarounds to fix the numbers here.

=1=
1. Put cursor to line "3. Line C" e.g. between "L" and "i".
2. Activate "Clone Formatting" tool (on toolbar, or in Format menu)
3. Apply the tool to the two first list items, selecting *the whole items* - position the mouse to the right of the "B.", press left mouse button, move mouse to the left of "1.", and release the mouse button.

=2=
1. Select first two full list items (e.g., starting from left of "1." and ending to the right of "B.").
2. Apply font size 10.
3. Re-apply font size 14.

However, what you mention here is not what is discussed in this bug. The bug's problem is not poor/absent UI for manipulating list numbers direct formatting, but inconsistent operation of items' numbers when changing the item's font size (which is clearly seen in the reproduction steps from comment 2, but it works fine in the second workaround I mentioned above).

Created attachment 154072 [details]
Sample per comment 2

(In reply to libreoffice.spam@fodder.homebuilt-lan.com from comment #17)
> See example document.
Wrong example. That issue in DOCX was fixed in master now and is not related to this bug. 

I attach Sample created per comment 2. Please always attach an example.

repro 7.3+

(In reply to MW from comment #22)
> Could not reproduce
> 
> Steps:
> 
> Made a list of 30 lines with size 14 font
> 
> Opened a new document and wrote lines with size 12 font
> 
> Copied size 12 font and placed on every line of the size 14 font document
> 
> Results:
> 
> Font was copied to the size 14 font document at size 12 font
> 
> Font was changeable to size 14 font through selecting size 12 font and
> changing it in the drop down for font size to size 14 or through clone
> formatting size 14 font on page  

Contrary to this, I still repro with steps from comment 2

Arch Linux 64-bit, X11
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 556b095dfb99c5db92328a63ffa30f07d8840db2
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 10 October 2023