Download it now!
Bug 51168 - EDITING: Numbering Size is Inconsistent with Text Size After Copy/Paste
Summary: EDITING: Numbering Size is Inconsistent with Text Size After Copy/Paste
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Paste Character
  Show dependency treegraph
 
Reported: 2012-06-17 03:58 UTC by Alexander
Modified: 2019-09-10 10:08 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Example screenshot (191.10 KB, image/jpeg)
2012-06-17 03:58 UTC, Alexander
Details
List imported from .DOCX can't have font for numbering on first item changed. (10.12 KB, application/vnd.oasis.opendocument.text)
2013-10-26 00:21 UTC, J. Kanowitz
Details
Example of inconsisted numbering font size. (5.38 KB, application/zip)
2019-07-09 11:02 UTC, libreoffice.spam@fodder.homebuilt-lan.com
Details
Sample per comment 2 (10.62 KB, application/vnd.oasis.opendocument.text)
2019-09-10 10:08 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander 2012-06-17 03:58:28 UTC
Created attachment 63132 [details]
Example screenshot

Problem description: 
I have numbered list. All letteres i make 14 size.
But some numbers are 12 size. And i can't choose and edit it. When i delete the number, previous list number become 12. If i delete list, it doesn't help. When i choose all and make 14 font size, it doesn't hepl.
I pasted to this list some 12 and 10 font size lines, but after i changed them to 14. How can office remember this size if i choose all and make 14 size?
Steps to reproduce:
1. Make big list with 14 font size
2. Paste some 12 font size lines (i'm not sure, it is because of pasting)
3. Make them 14 size

Current behavior:

Expected behavior:
I can change list number font size manually.
Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0
Comment 1 bfoman (inactive) 2012-06-20 03:39:50 UTC
Could you attach any example documents to allow others to check on different
system/build?
Comment 2 A (Andy) 2012-12-25 14:58:17 UTC
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
Comment 3 J. Kanowitz 2013-10-26 00:21:15 UTC
Created attachment 88134 [details]
List imported from .DOCX can't have font for numbering on first item changed.
Comment 4 J. Kanowitz 2013-10-26 00:21:50 UTC
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.
Comment 5 sophie 2013-11-06 09:44:46 UTC
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
Comment 6 Björn Michaelsen 2014-01-17 09:51:50 UTC Comment hidden (obsolete)
Comment 7 Mike Kaganski 2014-02-23 03:42:16 UTC
(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.
Comment 8 tommy27 2014-05-13 04:40:58 UTC Comment hidden (obsolete)
Comment 9 Mike Kaganski 2014-05-13 11:14:58 UTC
Still REPRODUCIBLE with 4.2.4.2 under Win7x64.

Though I hesitate adding it to 4.2 MAB, as I described in comment 7. Please decide if it is needed.
Comment 10 tommy27 2014-05-13 11:19:46 UTC
@Joel
see Mike comments and do the right choice.
Comment 11 Joel Madero 2014-05-13 15:16:00 UTC Comment hidden (obsolete)
Comment 12 Joel Madero 2014-05-13 15:20:11 UTC
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
Comment 13 Timur 2016-02-22 10:42:04 UTC
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.
Comment 14 QA Administrators 2017-03-06 15:38:40 UTC Comment hidden (obsolete)
Comment 15 Ahiijny 2019-01-15 16:29:55 UTC
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.
Comment 16 libreoffice.spam@fodder.homebuilt-lan.com 2019-07-09 11:02:49 UTC Comment hidden (no-value)
Comment 17 libreoffice.spam@fodder.homebuilt-lan.com 2019-07-09 11:07:54 UTC Comment hidden (no-value)
Comment 18 Mike Kaganski 2019-09-05 09:16:32 UTC
(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).
Comment 19 Timur 2019-09-10 10:08:02 UTC
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.