Created attachment 68878 [details] Its a window screenshot, this is the wrong indent in list items. Problem description: When I make lists, these has indent "constant" but after list 9 item the items has big indents. Steps to reproduce: 1. Make a list until it exceeds 10 items Current behavior: Wrong formatting Expected behavior: Fix this bug :) Platform (if different from the browser): Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0
Yes, that's an old problem inherited from OOo, see Sample document Unfortunately I never had a good Idea how that problem can be solved. I thought we should already have a bug for that, but I was not able to find it.
Created attachment 68898 [details] Sample Document The sample document shows the different distances between numbering and content when you open it with 3.5
for me not reproducible with LO 4.0.1.2 (Win7 Home, 64bit) Does this issue still persist for you with the latest release of LO?
Confirmed with: LO 4.0.2.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Could not reproduce with two digits, but reproducible with three digits.
Created attachment 86690 [details] 3 digits numbered list bug still present in 4.1.1.2 under Win7 64bit. see my sample document. larger indent after item 100. I'm not also very happy about the alignment of first 10 items.
Restricted my LibreOffice hacking area
** 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 (4.4.2 or later) 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) http://downloadarchive.documentfoundation.org/libreoffice/old/ 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
(In reply to tommy27 from comment #5) > Created attachment 86690 [details] > 3 digits numbered list > > bug still present in 4.1.1.2 under Win7 64bit. see my sample document. > larger indent after item 100. I'm not also very happy about the alignment of > first 10 items. Repro from scratch. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58 Locale: fi-FI (fi_FI)
As I understand it's NOT a bug, this is correct behavior. MS Word does the same. The formatting is dependent on font type, font size, another paragraph settings. On "10" line default tab stop is too small. Therefore it's necessary to make first tab longer. To fix this formatting issue user makes usually first custom tab stop at the appropriate position. After that text in number list started from the same position. This works in MS Word, but unfortunately it's not working in LibreOffice because of that bug ( https://bugs.documentfoundation.org/show_bug.cgi?id=94028 ). LO could by default create first custom tab stop automatically, that would fix this issue. But here we will have another problem. If the listing contained 8 lines, the tab position was one width. After a while another 3 lines were added, then automatically tab position need to be expanded. This potentially could break formatting of previous lines. IMHO, user should make decision about width of first tab.
** 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.1.6 or 5.2.3 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) http://downloadarchive.documentfoundation.org/libreoffice/old/ 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! Warm Regards, QA Team MassPing-UntouchedBug-20170103
bug still present in LibO 5.2.4.2
Bug also present in 5.3.0.3 (on Manjaro 64-bit).
IMO, the problem here is not a bug, but a poor default choice. By default, lists have two tab stops, the first one to indicate number position and alignment and the second one to indicate first line indent for text. The first tab for numbers is aligned "to the left" and that means that when the number is wider than the space left by the indent tab the text get pushed to the right. The easiest solution to this problem is to change the alignment for the number's tab stop to be aligned to the right, so instead of 9. Text 10. Text which is the current default behaviour, you get a nicer list like 9. Text 10. Text which is the default behaviour of lists in LaTeX. So maybe this bug report could be changed into a feature request to change the default value for numbering alignment on lists.
(In reply to RGB from comment #13) > IMO, the problem here is not a bug, but a poor default choice. > > By default, lists have two tab stops, the first one to indicate number > position and alignment and the second one to indicate first line indent for > text. The first tab for numbers is aligned "to the left" and that means that > when the number is wider than the space left by the indent tab the text get > pushed to the right. The easiest solution to this problem is to change the > alignment for the number's tab stop to be aligned to the right, so instead > of > > 9. Text > 10. Text > > which is the current default behaviour, you get a nicer list like > > 9. Text > 10. Text > > which is the default behaviour of lists in LaTeX. > > So maybe this bug report could be changed into a feature request to change > the default value for numbering alignment on lists. Let's ask UX.
(In reply to RGB from comment #13) > IMO, the problem here is not a bug, but a poor default choice. Some work has been done regarding default list styles in bug 106988. But the issue here will not finally be solved by any style. Think about roman numbering like MMXVII that quickly exceeds the first tab width. The only solution is the dynamically adjust the tabs, which requires a format change (for consistency). Nonetheless we should take care about this issue when defining new default styles in order to make them work in the usual environment for 1..99.
*** Bug 90182 has been marked as a duplicate of this bug. ***
Dear Jordy, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Unchanged in LO 6.5+.
*** Bug 83103 has been marked as a duplicate of this bug. ***
*** Bug 87848 has been marked as a duplicate of this bug. ***
*** Bug 100112 has been marked as a duplicate of this bug. ***
Dear Jordy, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 141740 has been marked as a duplicate of this bug. ***
Any comments/duplicates prior to Nov 2017/LO 6.0 are basically irrelevant. The defaults were changed with https://gerrit.libreoffice.org/37742. This TOTALLY depends on the font chosen. In general, it seems like LO and MS Word are using the same hard-coded values. For example, using 12pt Times New Roman/Liberation and ABC numbering, the tab pushes AA out to the next level in both programs, but simply changing the font to Calibri/Carlito allows double-character numbering to line up with single-character. Both LO and MS handle 123 numbering up to 99 - with 100 pushing to the next tabstop. Microsoft doesn't seem to define special tabstops for numbering. They just use their default tabstop of 1.27 (half an inch) for everything, and start with a hanging indent of -.63, jumping half an inch for each sublevel. LO defaults to 1.25cm tabs, but 1.27 tabs for numbering, and increment by .7 each sublevel. So while MS jumps by 1.27 each time, we jump by nearly half that much. Having tighter numbering doesn't seem too bad - although not lining up with our tabstops becomes the biggest downside. So it seems like the only "problem" remaining is with roman-numeral-numbering. Now the "Numbering IVX" style almost fine - it has an enlarged range and is right-aligned. (It just has a oddball level 3). So it is simply the bullet and numbering wizard's roman-numeral-numbering [or the (number) once getting up to 10] because they are all just using the standard 0.63 / 0.7 tabs instead of the enlarged indents used by the style. However, the wizard (cui/source/tabpages/numpages.cxx) is "interesting". I mean, it is only changing minor things, but using it WILL modify the style if a style was applied. The things that are changed are found in the struct SvxNumSettings_Impl, and tabs/indents/alignment are not included - just prefix/suffix and numbering type basically. Adding (optional) tab/indenting to that struct would not be easy. It ties in with abstract locale stuff, getting the contents from i18npool/source/localedata/localedata.cxx. I assume the list of "choices" seen depends on the UI language. I tried "if SVX_NUM_ROMAN_*, then SetNumAdjust(SvxAdjust::Right)", but that often doesn't look good either, and switching to something else wouldn't undo that. So that is a bad hack attempt. Since this is all so dependent on font/size, any attempt to improve this probably needs to based on a mathematical formula, with the locale-data adding an alignment option for left/right/center. Actually, we need two (or three) mathematical forumulas to handle left and right differently.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/028aa1058340803eb8dca5ad8f39ca253ad18fb3 tdf#56258 tdf#106988 sw numbering IVX: fix bad indent/tab value It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/64318c884eac13baa3012c8da3e5feb3c1369933 tdf#56258 tdf#106988 sw numbering ivx: make style useable It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
So the styles should be nice now I think. I also have some patches that explore using the default tabstop as a mathematical way to calculate appropriate indent levels for these styles. The default tabstop is defined as 1.25cm in writer.xcs. (or 1.27 for non-metric locales and something tiny for Chinese). There are two situations that I'm still investigating. One is Format - Bullets and Numbering. That is cui/source/tabpages/numpages.cxx's single/outline NumSelectHdl_impl. This simply changes the numbering type and suffix/prefix. The other situation is the toolbar's uno:SetNumber which does most of the work in NumberingTypeManager::ApplyNumRule. The interesting thing is that both of these almost connect in txtnum.cxx, but the implementations diverge widely. If any of this is shared with Draw/Impress, I don't see where.
Outline Numbering can define the indent/tabstop positions. The formatting toolbar's "outline format" (which is disabled by default) makes changes to all defined levels - changing the numbering type and indenting. [However, it ignores the level indent information in the locale definitions and just uses the SvxNumRule::SvxNumRule constructor default of 1/4 inch increments.] The US English definitions for these 8 outlines only defines the first 5 levels. i18npool/source/localedata/data/en_US.xml - <LC_OutLineNumberingLevel> The single "ordered" numbering only defines/effects NumType, Prefix, and Suffix. <LC_NumberingLevel>. It only changes the level that the cursor is on (unless there is no numbering yet - then it defines all levels identically).
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ef3b7b7118c854d8ca67cc2249b6c08ddc1885eb NFC tdf#56258 i18npool NumberingLevel: use ref="en_US" It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b1226e1f225de4fa67a0d4f5a6aa4017284c7deb tdf#56258 i18npool: should be a SvxAdjust, not a HoriOrient It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/87a4185fff1f9294fcdc6117761b1298632c95e5 NFC tdf#56258 i18npool OutLineNumberingLevel: use ref="en_US" It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ec2f1d73936c9d8cee83c0887170e9ecb8f044ba tdf#56258 svx: use last defined locale-outline for remaining levels It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 55053 has been marked as a duplicate of this bug. ***
*** Bug 124301 has been marked as a duplicate of this bug. ***
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dd8ed1fdbc63499ac958d28536c3c5540455358b tdf#56258 en_US: increase outline levels definitions to 6 It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a9b666b6b839735919923d8911f7e1efe0eb87b0 tdf#56258 svx SetOutline: convert to toggle It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3fd0b4053763aa91b0004c523e96e7d390c7b58e tdf#56258 sw toolbar: show SetOutline by default It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/710017981194c33ac1ba1acc439f92b87869f532 tdf#56258: allow i18npool to define SvxAdjust for outline It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6cabd7d9bfed37799a344f872d5f8fcf3214116a tdf#56258 i18npool: add "adjust" to locale.dtd for outline numbering It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c3964de14cb14099b49e1c55370a5f98e773e03d tdf#56258 i18npool en-US: change outline order to match MLA style It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5297528b85652d3f5a85e75ff6bcb406ba9b34d3 tdf#56258 i18npool en-US: replace illogical outline 1.(a).i.A It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2570eb7265fbae840bf9f2d83463b0bee09beaef tdf#56258 i18npool en-US: document ISO 2145 compliant outline list format It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9993ccab05dd95dd0de0dc74fc72e5aee8a8cb61 tdf#56258 i18npool en-US: extend outline 1.a) to 4 levels It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/894efac210a3871214d95a52c322b0bee40f00ba tdf#56258 i18npool en-US: partial revert 5th outline level It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d07b1cc8148140bd3a78103da668d002b9d266ab Revert "tdf#56258 svx SetOutline: convert to toggle" It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A potential improvement still possible is to have the toolbar and the dialog consolidate their code. (There are two main code paths that let the user change the bullet/numbering type of their list. One is the toolbar/sidebar's grid of 8 choices which calls .uno:Set{Number,Outline,Bullet}. The other path is via the Bullets and Numbering dialog, which has 3 tabs containing the same grid choices.) These two code paths widely diverge on the way that they apply the selected numbering to an existing list. I explored merging these two, but decided not to because end users have likely developed workflows that work best for them, and some will prefer one way while others would prefer the other way. My sample implementation to return locale index from bullets&Numbering dialog can be seen at https://gerrit.libreoffice.org/c/core/+/144881
(In reply to Justin L from comment #27) > I also have some patches that explore using the default tabstop as a > mathematical way to calculate appropriate indent levels for these styles. https://gerrit.libreoffice.org/c/core/+/144842 https://gerrit.libreoffice.org/c/core/+/144843 https://gerrit.libreoffice.org/c/core/+/144844
I am going to mark this as finished. In my opinion, there has been significant improvement to outline numbering with these changes. I realize that many things here are very much driven by a particular user's perspective or specific document's characteristics and that there isn't necessarily a right or wrong implementation. I have tried very hard to limit myself to only tinker with things that are fairly clearly wrong or non-optimal. Although perhaps the most dangerous, I think the greatest asset is having the outline button visible on the toolbar by default. It makes each locale's outline choices very accessible. (I consider it dangerous because it might not match user expectations of what it does - since it is fundamentally different from the other bullet/numbering buttons. But UNDO works fine, so the user is easily saved from self-created disaster.)
Documented in release notes: https://wiki.documentfoundation.org/ReleaseNotes/7.6#Localization Notified locale mailing list: https://listarchives.libreoffice.org/global/l10n/2023/msg00014.html
*** Bug 154889 has been marked as a duplicate of this bug. ***
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/293959d42c0eb19a5e953c6d2610b2c7b1908412 tdf#56258 i18npool en-US: re-arrange outline numbering suggestions It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.