[Upstream] Numbering mis-indents in LibreOffice Writer

Created attachment 53370
PDF example of alignment problem

When creating an ordered list through the Numbering option (F12), I then choose to change the ordering to the third from the left option in the Bullets and Numbering configuration box, under the Outline tab. This option creates the ordered list with indentations as follows: 1. (a) i. A., etc.

When using this Outline option for an ordered list, after reaching the 10th ordered list item, the text shifts to the right with an extra tab, resulting in misaligned text for any item in the ordered list with the number 10 or above. An example is attached.

I've confirmed this behavior in the Windows version and the Linux x64 version.

1) lsb_release -rd
Description: Ubuntu 11.10
Release: 11.10

2) apt-cache policy libreoffice-writer
libreoffice-writer:
  Installed: 1:3.4.4-0ubuntu1
  Candidate: 1:3.4.4-0ubuntu1
  Version table:
 *** 1:3.4.4-0ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ oneiric-updates/main i386 Packages
        100 /var/lib/dpkg/status
     1:3.4.3-3ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ oneiric/main i386 Packages

Also seen in 3.4.5 final.

3) What is expected to happen in a blank LibreOffice Writer document click Format -> Bullets and Numbering... -> Uppercase Roman Numerals -> OK button -> repeat:

type test -> click Enter button

and the space between the text and roman numeral is consistent as in Word screenshot https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/831305/+attachment/2654242/+files/word-screenshot.png .

4) What happens instead is a tab is inserted unnecessarily between the text and the roman numeral https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/831305/+attachment/2654241/+files/lo-screenshot.png .

Firstly, when using numbering of the style (i), (ii), (iii) etc, the indentations are wrong. The third line (and often the fourth and sixth) always has a greater indentation than the other lines. The numbers are aligned vertically, but the text is not. It is approximately one TAB further. This error does not manifest itself with other numbering styles such as 1., 2., 3. or a), b), c) etc.

Hello,
I can reproduce this bug with LibreOffice 3.4.3 on Mac OSX.6.8
It happens only for numbers greater than 9.
Here is a screenshot : http://i.imgur.com/g8aJ6.png

Regards,
~Jim

Hello,

This bug is still present on 3.5.5.3 on Mac OS X 10.6.8.
To overcome it, you can slide the slider on top of the document, this will realign the list item.

Created attachment 65277
Numbered list roman numerals

This is perhaps most obvious with roman numerals

*** Bug 48475 has been marked as a duplicate of this bug. ***

*** Bug 50624 has been marked as a duplicate of this bug. ***

*** Bug 65440 has been marked as a duplicate of this bug. ***

from duplicate 65440:

  " It's a problem that is caused by the default indent, linked to specific bullet/numbering types. With latin numbering the problem often starts with 10 or so.
So you can change it by setting the indent for the various levels on the tab Position....
However, of course you want this to work fine out of the box, I guess ;) "

Setting version to 330 - inherritted from OOo

Bit more words in Summary ;)

Mark as ProposedEasyHack

what more :) ?

*** Bug 67678 has been marked as a duplicate of this bug. ***

*** Bug 70297 has been marked as a duplicate of this bug. ***

Whiteboard: proposedEasyHack -> ProposedEasyHack

easyhackify

Created attachment 91509
rough patch/codepointer

attached patch should give a rough starting point on this. The patch moves the default tabstop one inch to the right, which is obviously too much. Should be enough of a starting point though.

The bug does not appear in LibreOffice 4.1 and 4.3alpha on Linux

Hm, I still see this problem when opening the "numbered list roman numberal" test file with 4.2.0.2

Confirmed:4.2.0.2:OSX

VII. and VIII. are further to the right than the rest. From what I understand that is what is being reported here as bug.

Created attachment 92653
This is how MS works about roman numbering list

Hi all,
I'm looking at this bug as my first easy hack.
I start to check how MS Office work about the same problem, and I found that MS use a different approach, as showed in the attached pictures.
I guess the real problem here is how to manage the space taken for the roman number when it start to increase for very long list.
We need to be able to manage a long list case where the first line have only one singol character as bullet char, whereas the last line can have 8 char (i.e. LXXXVIII).

How MS works: it uses the space between the bullet char and the text as a referement point, then the bullet char string is aligned to the right and the text is aligned to the left (see attached picture).
In that way, however, the char string can go out of the page margin.

How LO works: looks like all element are aligned to the first char of the bullet string.
In that way the bullet string are aligned through the list but the rest are not.
Actualy the space between the separator char and the user's text change depending to the bullet string lengh, producing a bad look.

Proposal:
Use a fixed offset applied after the separator char, ignoring the identation aligment of the user's text respect to the previuos and the subsequent bullet point.
The space taken by the bullet string can increae but the space between the separator char and the user's text will be always the same and big enough to make the text beautiful.

NOTE:
this would be my first hack in LO and my first try with C++ language, so I hesitate a bit to assign it to me, maybe there is someone more capable than me that could work on this one.

adding LibreOffice developer list as CC to unresolved Writer EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details

I would just like to confirm that this is still an issue in 4.4.5.2-5.fc22 stable of LibreOffice Writer. I am running Fedora 22, Linux 4.1.6-200, and the indention on outlines still has an extra indention sometimes, usually on the top line of the list (i.e. the primary numbering count, if that makes sense).

This has been an issue that has been present for quite some time, and I think it would help increase the graphic appeal of the program for users… professors have questioned why my numbering system is off when I hand in assignments with outlines using LibreOffice Writer. ;P

I have / will attach an ODT that demonstrates this problem as well.

Created attachment 118556
Roman Numeral Outline Example, 4.4.5.2 stable Linux

Testcase of bug explained in bug report, present in 4.4.5.2 stable for Linux.

Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillCpp )
[NinjaEdit]

Hi all,

I changed the default numbering alignment of the Roman(upper/ lower) numbers list to the right instead of left. Moreover, this will not affect the other list types default settings. Also, numbering alignment can be changed by the user and any new list created will not be affected by the user choice (using the default settings for the new list).

I submitted a patch you can check it:

https://gerrit.libreoffice.org/#/c/21439/

thanks
Nusaiba

Nusaiba Al-Kindi committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6517141b6233c5f9667031bc92f66109fddf5b76

tdf#42788: FORMATTING - Numbering/ordered list

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Fixed in:
Version: 5.2.0.0.alpha0+
Build ID: 3fc292f7b32f30b98dad208eb03e086b927d38a2
CPU Threads: 2; OS Version: Windows 6.19; UI Render: default;
TinderBox: Win-x86@39, Branch:master, Time: 2016-01-22_23:56:18
Locale: en-US (en_US)

Remove LibreOffice Dev List from CC on EasyHacks
(curtailing excessive email to list)
[NinjaEdit]

It turns out the fix, created other problems, please look at the notes on the gerrit.

jan iversen, could you please post the direct URL of the notes of the gerrit you are referring to (versus make folks dumpster dive for it via a search engine, etc.)?

There is nothing in https://cgit.freedesktop.org/libreoffice/core/commit/?id=6517141b6233c5f9667031bc92f66109fddf5b76 that discusses any regression potential, or side effects.

Also, given the scope of this report is confirmed fixed, I'm not sure what the value is in reopening it. Instead, it may be better to open a net new report, reporting in detail any confirmed or potential regression.

Also, please mark yourself CC on reports you make comments to, so you get any follow up emails that requests a response.

Thanks!

(In reply to Christopher M. Penalver from comment #27)
> jan iversen, could you please post the direct URL of the notes of the gerrit
> you are referring to (versus make folks dumpster dive for it via a search
> engine, etc.)?
Not a bad idea, will have to dig it out.
>
> There is nothing in
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=6517141b6233c5f9667031bc92f66109fddf5b76 that discusses any regression
> potential, or side effects.
>
> Also, given the scope of this report is confirmed fixed, I'm not sure what
> the value is in reopening it. Instead, it may be better to open a net new
> report, reporting in detail any confirmed or potential regression.
>
Well if you revert a change (that you committed) it seems natural to reopen the bug as well.

Opening a new bug with the same text can of course be done.

Please be aware that I (among others) confirmed it fixed, and was later made aware that this patch caused problems with higher indent levels. It was the hope that the author of the patch would submit a fix, but with a new release candicate due next week, a revert was needed.

> Also, please mark yourself CC on reports you make comments to, so you get
> any follow up emails that requests a response.

Now why would I do that ? I get mail on these issues already. You might not have noted it, but all easyhacks was changed a while ago, so I get CC from all of them instead of filling up the dev list.

rgds
jan i.

>
> Thanks!

(In reply to jan iversen from comment #28)
> (In reply to Christopher M. Penalver from comment #27)
> > jan iversen, could you please post the direct URL of the notes of the gerrit
> > you are referring to (versus make folks dumpster dive for it via a search
> > engine, etc.)?
> Not a bad idea, will have to dig it out.

If it is more convenient, would you have the revert commit URL instead?

> >
> > There is nothing in
> > https://cgit.freedesktop.org/libreoffice/core/commit/
> > ?id=6517141b6233c5f9667031bc92f66109fddf5b76 that discusses any regression
> > potential, or side effects.
> >
> > Also, given the scope of this report is confirmed fixed, I'm not sure what
> > the value is in reopening it. Instead, it may be better to open a net new
> > report, reporting in detail any confirmed or potential regression.
> >
> Well if you revert a change (that you committed) it seems natural to reopen
> the bug as well.
>
> Opening a new bug with the same text can of course be done.

Whatever makes sense here is fine with me (especially since the commit was reverted).

> > Also, please mark yourself CC on reports you make comments to, so you get
> > any follow up emails that requests a response.
>
> Now why would I do that ? I get mail on these issues already. You might not
> have noted it, but all easyhacks was changed a while ago, so I get CC from
> all of them instead of filling up the dev list.

This is another request to please stop making people dumpster dive for information. Nobody except for a few know that, and expecting others to either know this, or dumpster dive for this, is putting an unnecessary onus on others.

> rgds
> jan i.
>
>
> >
> > Thanks!