Apache OpenOffice (AOO) Bugzilla – Issue 98748
Roman numeral outline numbering has improper indents
Last modified: 2013-08-07 14:41:21 UTC
Steps to reproduce. 1. Start a new document. 2. Enable outline numbering using the roman numeral level 1. 3. Type out stuff for I, II, III, etc... 4. Notice that the roman numeral 3 has improper indentation.
Created attachment 59836 [details] Testcase of issue
Spacing after roman numeral 4 is also affected.
This is not a bug (though it has been reported now for several times), but maybe somehow an automatism could be implemented, which sets more proper indent and spacing default values for every available numbering type.
That would be nice considering how annoying this bug is. I don't like how I presently have to adjust the indents manually. I also disagree that fixing this bug is an enhancement. The formatting for ordered lists, numbered or bullets, is fundamentally broken.
I was wondering if I could perhaps get some more insight as to what causes this bug.
So, is this issue going to be rectified in time for 3.1 or will it be ignored?
I see this bug. However, changing the numbering scheme to Arabic numerals and then back to Roman numerals clears this right up for me in my testing of your attachment. This is certainly an annoyance bug, but fixing it without resorting to manually editing the layout of each line is simple enough. I am testing this feature on OpenOffice 3.1 running under Ubuntu 8.10. The OpenOffice 3.1 was downloaded from an OpenOffice.org mirror and installed via dpkg using the official .debs packages.
Even in 3.1.1, this isn't hasn't been acknowledged.
setting keyword
*** Issue 107359 has been marked as a duplicate of this issue. ***
This bug is still present in Open Office 3.2 I use outlines ALOT, actually that's what I use my word processor most often for, so this bug is highly annoying to me. Thanks for the work around of changing from roman numerals in an outline to numbers and back to outline again. I can verify that that works for me as well.
*** Issue 110557 has been marked as a duplicate of this issue. ***
@llstarks: please don't change flags like "issue type". What looks like a bug must be handled as enhancement because the way to fix it is not obvious (must be re-designed). (BTW: defect or enhancement will have no influence on rapidity of the fix) The problem due to 2 concurring defaults: - by default the "Numbering followed by" character is a tab and a tab jumps to to the next tab position when its space to text gets too small. -> changing from Tab to Space cures the problem. - by default the "Numbering alignment" is "Left". -> setting it to "right" cures the problem because the numbering string expands to the left and does not "push" the tab to the right. This affects every numbering but is extremely noticeable using Roman numbering because it expands "faster" then Arabic numbering to the right: Compare: XVIII (5 characters) and 18 (2 characters). This varies of course depending on the font used... Using Tomes New Roman, the effect might show with number VII while it shows already at II in Courrier New (which is wider). So possible workarounds while waiting for better defaults: - use Numbering alignment "Right" (looks better anyway), or - use something else than a Tab for separator, or - in some cases, using another font while keeping the other defaults might help Last thing: Please don't comment for every release that this issue is not fixed. This is obvious looking at its status! Else asking for it at every release doesn't push it further. Unfortunatly we have lot more other issues to fix before... @Requirements: Proposals: The solution would be to change some defaults. For all Numberings or just for Roman: 1. No Tab as Default: not a good solution because has been introduced AFAIK for MS-compatibility reasons -> Void. 2. Right alignment by default for Roman numbering -> could be a solution 3. Set wider default Tab position to default paragraph styles so that the effect shows very "late" when using Roman. I'd advocate for 2)
*** Issue 112633 has been marked as a duplicate of this issue. ***
*** Issue 112833 has been marked as a duplicate of this issue. ***
*** Issue 115710 has been marked as a duplicate of this issue. ***