https://bugs.documentfoundation.org/show_bug.cgi?id=162133
--- Comment #15 from Justin L <jl...@mail.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.