Created attachment 192567 [details] Sample with screenshots to reproduce the bug This problem arises in LibreOfficeWriter Version: 24.2.2.0.0+ (X86_64) / LibreOffice Community Build ID: 46169670ef4031888e143823b263577296d7867f CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded But I also encountered it in older versions. (sorry, 24.2.2.0.0 was not offered in the bug report drop-down list, I selected another one close to that). There is a very old bug 32400 which is told to have been fixed on 2010-12-14 19:44:23 UTC, but this is another one. Steps to reproduce: In the appended example try out applying the "bulleted list" tool button twice on each bulleted list paragraph. They behave differently. Expected result: I expect, that they all result in the same bullet point size, preferably the one which comes out of the first few bulleted paragraphs.
I can reproduce in: Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 98c42f7e961e77d7f1c02d53862e4e78ecd07653 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded I think the logic is: - if there is no list in previous paragraph, bullet is reset to default. - if there is a list in previous paragraph, same bullet as above is used, which makes sense for consistency. So I think this is "not a bug". Can you please check that this is indeed the logic?
Dear Adalbert Hanßen, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Created attachment 196264 [details] new findings and proposal how to rectify the bug (In reply to Stéphane Guillou (stragu) from comment #1) > I can reproduce in: > ... > > I think the logic is: > - if there is no list in previous paragraph, bullet is reset to default. > - if there is a list in previous paragraph, same bullet as above is used, > which makes sense for consistency. > The implemented logic differs. I revisited my example. My investigations provide deeper insights into inconsistencies in the process and a suggestion as to how the error should be rectified. Especially in view of the fact that the details of the improved function can be explained simply and plausibly and all related alternatives are in one dialog afterward.
(In reply to Adalbert Hanßen from comment #3) > Created attachment 196264 [details] > new findings and proposal how to rectify the bug So getting to the source itself: the HTML is coming from the Serverfault answer https://serverfault.com/a/705144 It has a giant unordered list (<ul>) which contains nested unordered lists inside list items (<li>). I think the issue here was that the mouse selection from the web page did not capture the full markup, which would ruin the whole structure. So if you select everything including Some differences on Bash 4.3.11: ... Recommendation: always use [] and then paste into Writer, everything will be fine - the bullets will also be the correct size.
(In reply to Buovjaga from comment #4) > (In reply to Adalbert Hanßen from comment #3) > > Created attachment 196264 [details] > > new findings and proposal how to rectify the bug > > So getting to the source itself: the HTML is coming from the Serverfault > answer https://serverfault.com/a/705144 > > It has a giant unordered list (<ul>) which contains nested unordered lists > inside list items (<li>). I think the issue here was that the mouse > selection from the web page did not capture the full markup, which would > ruin the whole structure. So if you select everything including > > Some differences on Bash 4.3.11: > > ... > > Recommendation: always use [] > > and then paste into Writer, everything will be fine - the bullets will also > be the correct size. Buovjaga, thanks for your effort, but your explanation might be wrong: I played again both of my examples from above and I found out, that now, with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d649e297fde11efab2c681605e27e513a183e314 CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded both behave as expected. Now I test it with a different from Version, which was 24.2.2.0.0+ in my bug report. Bot versions render different results, so apparently soemething has changed in between. If you have access to the source code and find the right place(s), you might verify if changes have been applied to them (I would not even be able to find the spot where this all is handled...). Of course your way of copying and pasting works equally in version 25.2.0. However in my case, the bullet points remained to become fat ones after pasting - contrary to what you wrote. But the bullet points being fat ones is not so important, since it ca easily be corrected with just two clicks (after selecting the paragraphs). Conclusion: I regard this issue to be resolved, as the status of this conversation already tells us.
(In reply to Adalbert Hanßen from comment #5) > (In reply to Buovjaga from comment #4) > ... > > It has a giant unordered list (<ul>) which contains nested unordered lists > > inside list items (<li>). I think the issue here was that the mouse > > selection from the web page did not capture the full markup, which would > > ruin the whole structure. So if you select everything including > > Buovjaga, I don't doubt your findings about the html-structure of the source from which I had copied my example...
(In reply to Adalbert Hanßen from comment #5) > Buovjaga, thanks for your effort, but your explanation might be wrong: I > played again both of my examples from above and I found out, that now, with > > Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: d649e297fde11efab2c681605e27e513a183e314 > CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3 > Locale: de-DE (de_DE.UTF-8); UI: en-US > Calc: threaded > > both behave as expected. Now I test it with a different from Version, which > was 24.2.2.0.0+ in my bug report. Bot versions render different results, so > apparently soemething has changed in between. If you have access to the > source code and find the right place(s), you might verify if changes have > been applied to them (I would not even be able to find the spot where this > all is handled...). > > Of course your way of copying and pasting works equally in version 25.2.0. > However in my case, the bullet points remained to become fat ones after > pasting - contrary to what you wrote. But the bullet points being fat ones > is not so important, since it ca easily be corrected with just two clicks > (after selecting the paragraphs). I tested with the last commit of 24.2 bibisect repo and even there the correct way of copying produces the expected result in Writer, including bullet points that are the expected size and not big.