Description: When using the Roman Numeral Outline, the program bugs when it reaches VII and the indentation is off. Same problem with openoffice writer. Steps to Reproduce: 1.Open new document 2.Toggle Ordered List ON 3. Choose the Upper-Case Roman number I. II. III. .... 4. Randomly write something until you reach XX (20 or more ordered list). 5. You should see the identiation begins to offset at VII and VIII then return to normal at IX and then again the problem beings at XII .. and so on. Actual Results: Outline list does not have all have same identation regardless of Roman Numeral value. Expected Results: Outline list should all have same identation regardless of Roman Numeral value. Reproducible: Always User Profile Reset: Yes Additional Info: .
Please attach a sample file, reduce the size as much as possible without private information, and paste the information in Menu/Help/About LibreOffice, there is a copy icon.
Created attachment 195436 [details] Comparison: OnlyOffice (left), MS 365 (centre), LO 25.2 alpha0+ Reproduced in: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8705cfecd5a10f817d3a2a02041d85e77282aa30 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Not a good look for a default list style. In attachement, see how OnlyOffice and MS 365 Word align the numbering to the right by default to avoid the issue. (Which can be done in LO with Formats > Bullets and Numbering > Position > Alignment.) That solution is in my opinion preferable to increasing the tab stop size to accommodate e.g. "CLXXXVIII.", resulting in a big empty space between numbering and paragraph. The same issue arrises when e.g. the "1. 2. 3." list reaches 100. It's just less of a problem because it happens later, and because it does not go back and forth like for Roman numerals.
UX/Design team, do you think the default alignment should be "Right"? Something else?
Alignment right solves the issue, or some larger tab stop/indentation. See also bug 156071. (Both NAB, IMO. But I'll make this one a duplicate for now.) *** This bug has been marked as a duplicate of bug 156071 ***
Tried with the stock list style "Numbering IVX" and it is right aligned. Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 32; OS: Linux 6.9; UI render: default; VCL: kf6 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 24.2.5-1 Calc: threaded
(In reply to Heiko Tietze from comment #5) > Tried with the stock list style "Numbering IVX" and it is right aligned. Interesting! So: - List Styles from the sidebar: - Roman numerals: right-aligned - Arabic numerals: left-aligned - Letters: left-aligned - "Ordered List" styles from toolbar or dialog widgets: - all left-aligned - "Outline Format" styles from toolbar or dialog widgets: - mix of left- and right-aligned for the ones mixing letters and roman numerals We can see that right-aligned is already a default for levels using Roman Numerals in some places. My suggestion is to either: - make it the default for all levels where roman numerals are used (i.e. for the "Ordered List" styles from the widget) - or make it the default for all ordered lists, for consistency
Done for v6.0 (with modifications for v7.6) in https://gerrit.libreoffice.org/c/core/+/37742 for bug 106988 => aFormat.SetNumAdjust( SvxAdjust::Right );
(In reply to Heiko Tietze from comment #7) > Done for v6.0 (with modifications for v7.6) in > https://gerrit.libreoffice.org/c/core/+/37742 for bug 106988 > > => aFormat.SetNumAdjust( SvxAdjust::Right ); Thanks for digging it out. Setting to "new", as we can see this has been done for some style but not all, resulting in inconsistency and ugly defaults. Just unsure if it should be all list and all levels for consistency, or only Roman numeral levels.
Based on the work I did in LO 7.6 for bug 106988... The poor look for Roman Numerals does happen using LO's default font (Liberation size 12 font). However, using a different font (Carlito at 11pt – which is basically identical in size to Microsoft Office’s default use of Calibri 11pt), then Roman numbering fits. It quickly became evident that setting “good defaults” could only apply to entire lists – which consists of the list styles, and the locale-defined outlines. That is because these two categories define indenting/spacing for the ENTIRE LIST allowing all 9 sublevels to have uniform, aesthetic spacing. However, the testing in this report is not being done by setting an outline style. It is being done by changing only ONE LEVEL! That tool simply changes one type of numbering (which already has formatting) into another type. It would be incorrect to start changing the spacing or alignment formatting in this context, because then that level will be misaligned from its sublevels, and potentially destroy user-specified settings. Humans generally want left-aligned or fully justified text content, so forcing right-aligned Roman numerals is usually not acceptable. The entire list needs to be designed well to accommodate right-alignment. Microsoft implicitly acknowledges this, since their graphic shows left-aligned Roman numerals. Despite this, Microsoft Office forces right alignment for Roman numerals, often with horrible results. So, forcing right or left alignment is a bad idea, and we should not follow Microsoft’s lead in this situation. Lists are complicated, and it is a mistake to try to over-simply them. We give the user nice, predefined outline choices, as well as a tool to easily adjust a level’s numbering type, but it is ultimately the user’s responsibility to customize the list according to their own arbitrary tastes.
Created attachment 195513 [details] changeNumbering1.docx: forcing right-align when changing to Roman Numbering would be wrong!
Created attachment 195514 [details] changeNumbering2.docx: forcing left-align when changing away from Roman Numbering would be wrong! If you force Roman numbering to the right, then you need to force other numbering to the left (in case the user changes their mind). I imagine this could potentially have nasty implications for RTL languages... Bad idea anyway.
Created attachment 195516 [details] changeNumbering3.docx: Forcing right-aligned roman numbering is wrong in this case Similar to comment 10's example, but coming at it from a different workflow. You simply cannot make blanket statements about what the "right thing to do" is about lists.
Thanks for the detailed explanation, Justin! Much appreciated. (And please excuse my still-limited understanding in my response.) (In reply to Justin L from comment #10) > Created attachment 195513 [details] > changeNumbering1.docx: forcing right-align when changing to Roman Numbering > would be wrong! Indeed, I didn't think of headings. It's easy to forget and/or misunderstand how interlinked Heading paragraph styles and List styles are... But changing the "Number" property in the Bullets and Numbering dialog doesn't change the Alignment property, and a Heading paragraph style uses the list style "Heading Numbering" (which, as I understand it, is not listed in the List styles on purpose and only controlled by Tools > Heading Numbering). So could this ticket only concern non-heading lists created with the "Toggle" buttons from the toolbar? (In reply to Justin L from comment #9) > The poor look for Roman Numerals does happen using LO's default font > (Liberation size 12 font). However, using a different font (Carlito at 11pt > – which is basically identical in size to Microsoft Office’s default use of > Calibri 11pt), then Roman numbering fits. But it eventually doesn't at higher numbers, stating at XVII, then jumps back left at XIX. > It quickly became evident that setting “good defaults” could only apply to > entire lists – which consists of the list styles, and the locale-defined > outlines. That is because these two categories define indenting/spacing for > the ENTIRE LIST allowing all 9 sublevels to have uniform, aesthetic spacing. > However, the testing in this report is not being done by setting an outline > style. It is being done by changing only ONE LEVEL! That tool simply changes > one type of numbering (which already has formatting) into another type. It > would be incorrect to start changing the spacing or alignment formatting in > this context, because then that level will be misaligned from its sublevels, > and potentially destroy user-specified settings. I didn't realise the toolbar's "Toggle" buttons didn't apply an predefined list style. The Style Inspector made it look consistent with predefined list styles, except for the "List Style Name" property which seems to be a random number assigned when creating a hidden style on the fly? > Humans generally want left-aligned or fully justified text content, so > forcing right-aligned Roman numerals is usually not acceptable. I'm not sure this is an universal truth that applies to this specific context: I can imagine many users would like (_non-heading_) lists with the clean "mirror" orientation that right-alignment provides. > The entire > list needs to be designed well to accommodate right-alignment. Makes sense. > Microsoft > implicitly acknowledges this, since their graphic shows left-aligned Roman > numerals. Interesting! > Despite this, Microsoft Office forces right alignment for Roman > numerals, often with horrible results. So, forcing right or left alignment > is a bad idea, and we should not follow Microsoft’s lead in this situation. Indeed, your sample documents illustrate that. > Lists are complicated, and it is a mistake to try to over-simply them. Couldn't agree more now! :D > We give the user nice, predefined outline choices, as well as a tool to easily > adjust a level’s numbering type, but it is ultimately the user’s > responsibility to customize the list according to their own arbitrary tastes. So is your take that this ticket is "won't fix" / "not a bug", or you think things could still be improved for those toggles? e.g. is bug 156071 a sensible ask in your opinion?
Created attachment 195525 [details] sample ODT to illustrate original issue ... just so we have an editable file that illustrates the original issue and: (In reply to Stéphane Guillou (stragu) from comment #13) > But it eventually doesn't [fit] at higher numbers, stating at XVII, then jumps > back left at XIX.
(In reply to Stéphane Guillou (stragu) from comment #13) > Indeed, I didn't think of headings. I don't think headings are relevant here. (While there are some LO coding quirks about headings, there isn't really anything special about them except that they automatically have lists attached to them.) So just ignore "Heading numbering" in this discussion. The only point of changeNumbering1.docx is that you have a list already and are changing to a different number-choice. > (In reply to Justin L from comment #9) > > However, using a different font (Carlito at 11pt then Roman numbering fits. > [Stephane comments} But it eventually doesn't at higher numbers, stating at > XVII, then jumps back left at XIX. Sure. We also have something similar for regular numbers when you get to 10,000, or when using (#) formatting. At some point the numbering exceeds the tabstop and then has a big spacing jump to the next tabstop. List formatting needs to be designed to fit the content of a particular document. By the way, you have the same kind of problem with Roman numerals even when right aligned. By the time you get to point 388 on the first level, the number is spilling off the paper (based on all defaults). The important point here is that when the direction changes, the space-distance after should also be changed. Actually, it makes most sense to be "followed by a space" with right alignment and "followed by a tabstop" for left alignment. But changing that needs to be done with the other sub-levels in mind (in order to look balanced), while this tool (by definition) deals only with a single level. The big caveat is that if you change the spacing and direction on one option, you now need to force spacing and direction on every option. That will end in disaster. > I didn't realise the toolbar's "Toggle" buttons didn't apply a predefined > list style. Yeah, it is all based on very generic list-in-general defaults. While the outline toggle defines (almost) everything, the numbering toggle defines only the character (for one level, but if there is no existing list, it would automatically cascade to the remaining sub-levels). For example: - make a paragraph into a list by toggling on with "(a)" - press enter to start the next point. Press tab to go to the next sublevel. - note the sublevel is also "(a)". toggle this level to "1." - press enter to start the third point. Press tab to go to the third sublevel. - note that the third sublevel is back to "(a)" > So is your take that this ticket is "won't fix" / "not a bug", or you think > things could still be improved for those toggles? I don't see much that could be improved: - one could argue that maybe we should change our default font/size. - the default-list-settings could be changed to be based on the size of a tabstop instead of some arbitrary number, which might help multi-level lists line up nicer with regular text. (I looked into that - very complicated. Different locales can have different tabstop lengths.) - starting with LO 7.6, the "Outline format" toggle exists on the toolbar, and now has better choices. Users should probably switch to using that for the "best results". - this would be the perfect task to seek "artificial intelligence" funding for. Ultimately, everything depends on the document content. As soon as you change font or font size, or involve sub-levels, then every assumption made gets thrown out of the window. For me, this is a both WONTFIX and NOTABUG. > e.g. is bug 156071 a sensible ask in your opinion? I would only make a change to lists if it is something that Microsoft formats can already do.
Created attachment 195531 [details] Microsoft-selecing-Roman-numbering-shows-left-aligned-but-does-right-aligned.png (In reply to Stéphane Guillou (stragu) from comment #13) > > Microsoft implicitly acknowledges this, > > since their graphic shows left-aligned Roman > numerals. > Interesting!
By the way, why are you using Roman numbering anyway (especially if you don't like the results). And if you say you need to use it because of academic standards, you should be using the first outline-format choice, which matches the MLA/CMoS/Turabian academic standard.
(In reply to Justin L from comment #15) > > [Stephane comments} But it eventually doesn't at higher numbers, stating at > > XVII, then jumps back left at XIX. > Sure. We also have something similar for regular numbers when you get to > 10,000, or when using (#) formatting. > [...] > Ultimately, everything depends on the document content. Of course, but the issue here is that: - it happens way earlier and with font defaults. It is very common that a user will have a 7+ -item list, but very unlikely one will reach 10,000. - the Roman numeral list jumps to the next tab stop, then back, which does not happen elsewhere as far as I can see. But I now understand the right-alignment is not the right solution, and that the toolbar toggles use the existing tabstop size of the current paragraph style. So let's close as "won't fix". If there is a different change that could help (e.g. promoting one method over another from the UI, or taking a change of default the other way around...), let's propose that in a new enhancement request with a clean, precise idea to start from, and link to the discussion here. Thanks again, Justin.