Bug 42788 - FORMATTING - Numbering/ordered list results in misaligned text after a certain level: default indent does not match with the width of numbers/bullets
Summary: FORMATTING - Numbering/ordered list results in misaligned text after a certai...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
QA Contact: Christopher M. Penalver
URL:
Whiteboard: Confirmed:4.2.0.2:OSX target:5.2.0
Keywords: difficultyBeginner, easyHack, skillCpp
: 48475 50624 65440 67678 70297 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-11-10 07:01 UTC by Jeff S.
Modified: 2017-02-14 08:58 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
PDF example of alignment problem (19.50 KB, application/pdf)
2011-11-10 07:01 UTC, Jeff S.
Details
Numbered list roman numerals (10.72 KB, application/vnd.oasis.opendocument.text)
2012-08-08 11:27 UTC, leighman
Details
rough patch/codepointer (581 bytes, text/plain)
2014-01-05 03:49 UTC, Björn Michaelsen
Details
This is how MS works about roman numbering list (25.01 KB, image/png)
2014-01-23 11:13 UTC, Valerio
Details
Roman Numeral Outline Example, 4.4.5.2 stable Linux (9.76 KB, application/vnd.oasis.opendocument.text)
2015-09-09 18:47 UTC, Justin W. Flory
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff S. 2011-11-10 07:01:16 UTC
Created attachment 53370 [details]
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.
Comment 1 Satchit Bhogle 2012-01-24 12:13:58 UTC
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.
Comment 2 Jim Jarmusch 2012-05-16 06:21:11 UTC
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
Comment 3 Jim Jarmusch 2012-07-16 12:08:44 UTC
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.
Comment 4 leighman 2012-08-08 11:27:57 UTC
Created attachment 65277 [details]
Numbered list roman numerals

This is perhaps most obvious with roman numerals
Comment 5 leighman 2012-08-08 11:28:56 UTC
*** Bug 48475 has been marked as a duplicate of this bug. ***
Comment 6 leighman 2012-08-08 11:32:58 UTC
*** Bug 50624 has been marked as a duplicate of this bug. ***
Comment 7 Cor Nouws 2013-06-06 07:15:46 UTC
*** Bug 65440 has been marked as a duplicate of this bug. ***
Comment 8 Cor Nouws 2013-06-06 07:18:40 UTC
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 :) ?
Comment 9 Cor Nouws 2013-08-02 19:10:24 UTC
*** Bug 67678 has been marked as a duplicate of this bug. ***
Comment 10 Cor Nouws 2013-10-08 21:57:39 UTC
*** Bug 70297 has been marked as a duplicate of this bug. ***
Comment 11 Robinson Tryon (qubit) 2013-10-29 04:29:42 UTC
Whiteboard: proposedEasyHack -> ProposedEasyHack
Comment 12 Björn Michaelsen 2014-01-05 03:47:17 UTC
easyhackify
Comment 13 Björn Michaelsen 2014-01-05 03:49:24 UTC
Created attachment 91509 [details]
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.
Comment 14 Daniel Dong 2014-01-15 13:42:19 UTC
The bug does not appear in LibreOffice 4.1 and 4.3alpha on Linux
Comment 15 retired 2014-01-19 09:21:56 UTC
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.
Comment 16 Valerio 2014-01-23 11:13:23 UTC
Created attachment 92653 [details]
This is how MS works about roman numbering list
Comment 17 Valerio 2014-01-23 11:16:24 UTC
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.
Comment 18 Björn Michaelsen 2014-12-02 10:53:06 UTC
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
Comment 19 Justin W. Flory 2015-09-09 18:46:13 UTC
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.
Comment 20 Justin W. Flory 2015-09-09 18:47:32 UTC
Created attachment 118556 [details]
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.
Comment 21 Robinson Tryon (qubit) 2015-12-14 06:30:02 UTC
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillCpp )
[NinjaEdit]
Comment 22 Nusaiba Al Kindi 2016-01-13 16:31:43 UTC
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
Comment 23 Commit Notification 2016-01-21 19:41:12 UTC
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.
Comment 24 Christopher M. Penalver 2016-01-24 01:42:53 UTC
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)
Comment 25 Robinson Tryon (qubit) 2016-02-18 16:37:27 UTC
Remove LibreOffice Dev List from CC on EasyHacks
(curtailing excessive email to list)
[NinjaEdit]
Comment 26 jani 2016-03-08 06:49:38 UTC
It turns out the fix, created other problems, please look at the notes on the gerrit.
Comment 27 Christopher M. Penalver 2016-03-08 07:15:02 UTC
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!
Comment 28 jani 2016-03-08 07:49:34 UTC
(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!
Comment 29 Christopher M. Penalver 2016-03-08 08:11:24 UTC
(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!