Created attachment 63132 [details]
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
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
Could you attach any example documents to allow others to check on different
reproducible with LO 18.104.22.168. (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 22.214.171.124 (Ubuntu versions) when working with an imported .DOCX, see new attachment.
On my system with 126.96.36.199 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 188.8.131.52 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: 184.108.40.206
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
(This is an automated message.)
Setting priority to highest as this is a 4.1 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
(In reply to comment #5)
Still reproducible with 220.127.116.11 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 18.104.22.168. 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.
is this bug still valid in current 22.214.171.124 release?
if yes, please move it from mab4.1 to mab 4.2 list since 4.1.x is EOL
Still REPRODUCIBLE with 126.96.36.199 under Win7x64.
Though I hesitate adding it to 4.2 MAB, as I described in comment 7. Please decide if it is needed.
see Mike comments and do the right choice.
There is indeed no workaround and for any professional document with a list this could be a problem. Agreeing that this belongs on MAB list
Funny thing is I've experienced this before but never could figure out reproducible steps. I don't think that it's just because there is a URL being copied and pasted but comment 1 steps work (description does not, those steps do not reproduce the bug).
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
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.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice
(5.2.5 or 5.3.0 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Build ID: libreoffice-188.8.131.52-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.
Created attachment 152672 [details]
Example of inconsisted numbering font size.
7 years, no fix. Still broken in 184.108.40.206 (x64) and work around given in comment #12 does not work.
See example document.
(In reply to email@example.com from comment #17)
> 7 years, no fix. Still broken in 220.127.116.11 (x64) and work around given in
> comment #12 does not work.
> See example document.
Two workarounds to fix the numbers here.
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.
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 firstname.lastname@example.org 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.