https://bugs.documentfoundation.org/show_bug.cgi?id=56258
Justin L <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=83 | |103 | Assignee|[email protected] |[email protected] |desktop.org | --- Comment #24 from Justin L <[email protected]> --- 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. -- You are receiving this mail because: You are the assignee for the bug.
