Download it now!
Bug 56258 - FORMATTING: Default TABs for numbered list inappropriate, 2-digits Numbers exceed first TAB position
Summary: FORMATTING: Default TABs for numbered list inappropriate, 2-digits Numbers ex...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 83103 87848 90182 100112 (view as bug list)
Depends on:
Blocks: Bullet-Number-Outline-Lists Writer-UX
  Show dependency treegraph
 
Reported: 2012-10-21 15:53 UTC by Jordy
Modified: 2019-11-28 12:27 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Its a window screenshot, this is the wrong indent in list items. (132.45 KB, image/png)
2012-10-21 15:53 UTC, Jordy
Details
Sample Document (45.92 KB, application/vnd.oasis.opendocument.text)
2012-10-22 05:05 UTC, Rainer Bielefeld Retired
Details
3 digits numbered list (9.16 KB, application/vnd.oasis.opendocument.text)
2013-09-26 19:32 UTC, tommy27
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jordy 2012-10-21 15:53:59 UTC
Created attachment 68878 [details]
Its a window screenshot, this is the wrong indent in list items.

Problem description: 

When I make lists, these has indent "constant" but after list 9 item the items has big indents.

Steps to reproduce:
1. Make a list until it exceeds 10 items


Current behavior:
Wrong formatting

Expected behavior:
Fix this bug :)

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0
Comment 1 Rainer Bielefeld Retired 2012-10-22 05:02:52 UTC
Yes, that's an old problem inherited from OOo, see Sample document 

Unfortunately I never had a good Idea how that problem can be solved. I thought we should already have a bug for that, but I was not able to find it.
Comment 2 Rainer Bielefeld Retired 2012-10-22 05:05:13 UTC
Created attachment 68898 [details]
Sample Document

The sample document shows the different distances between numbering and content when you open it with 3.5
Comment 3 A (Andy) 2013-03-09 23:27:45 UTC Comment hidden (obsolete)
Comment 4 bfoman (inactive) 2013-05-09 11:45:41 UTC
Confirmed with:
LO 4.0.2.2
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Could not reproduce with two digits, but reproducible with three digits.
Comment 5 tommy27 2013-09-26 19:32:43 UTC
Created attachment 86690 [details]
3 digits numbered list

bug still present in 4.1.1.2 under Win7 64bit. see my sample document.
larger indent after item 100. I'm not also very happy about the alignment of first 10 items.
Comment 6 Cédric Bosdonnat 2014-01-20 08:57:16 UTC Comment hidden (obsolete)
Comment 7 Joel Madero 2015-05-02 15:43:58 UTC Comment hidden (obsolete)
Comment 8 Buovjaga 2015-06-21 12:46:42 UTC
(In reply to tommy27 from comment #5)
> Created attachment 86690 [details]
> 3 digits numbered list
> 
> bug still present in 4.1.1.2 under Win7 64bit. see my sample document.
> larger indent after item 100. I'm not also very happy about the alignment of
> first 10 items.

Repro from scratch.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58
Locale: fi-FI (fi_FI)
Comment 9 Andrey Skvortsov 2015-12-02 11:26:19 UTC
As I understand it's NOT a bug, this is correct behavior. MS Word does the same. The formatting is dependent on font type, font size, another paragraph settings.

On "10" line default tab stop is too small. Therefore it's necessary to make first tab longer. To fix this formatting issue user makes usually first custom tab stop at the appropriate position. After that text in number list started from the same position.

This works in MS Word, but unfortunately it's not working in LibreOffice because of that bug ( https://bugs.documentfoundation.org/show_bug.cgi?id=94028 ).

LO could by default create first custom tab stop automatically, that would fix this issue. But here we will have another problem. If the listing contained 8 lines, the tab position was one width. After a while another 3 lines were added, then automatically tab position need to be expanded. This potentially could break formatting of previous lines. IMHO, user should make decision about width of first tab.
Comment 10 QA Administrators 2017-01-03 19:41:58 UTC Comment hidden (obsolete)
Comment 11 tommy27 2017-01-03 23:14:27 UTC
bug still present in LibO 5.2.4.2
Comment 12 Thomas Woltjer 2017-02-13 14:44:09 UTC
Bug also present in 5.3.0.3 (on Manjaro 64-bit).
Comment 13 RGB 2018-02-17 13:49:23 UTC
IMO, the problem here is not a bug, but a poor default choice. 

By default, lists have two tab stops, the first one to indicate number position and alignment and the second one to indicate first line indent for text. The first tab for numbers is aligned "to the left" and that means that when the number is wider than the space left by the indent tab the text get pushed to the right. The easiest solution to this problem is to change the alignment for the number's tab stop to be aligned to the right, so instead of 

  9.   Text
  10.  Text

which is the current default behaviour, you get a nicer list like

   9.  Text
  10.  Text

which is the default behaviour of lists in LaTeX.

So maybe this bug report could be changed into a feature request to change the default value for numbering alignment on lists.
Comment 14 Buovjaga 2018-02-17 14:44:51 UTC Comment hidden (obsolete)
Comment 15 Heiko Tietze 2018-02-18 09:55:00 UTC
(In reply to RGB from comment #13)
> IMO, the problem here is not a bug, but a poor default choice. 

Some work has been done regarding default list styles in bug 106988.

But the issue here will not finally be solved by any style. Think about roman numbering like MMXVII that quickly exceeds the first tab width. The only solution is the dynamically adjust the tabs, which requires a format change (for consistency). 

Nonetheless we should take care about this issue when defining new default styles in order to make them work in the usual environment for 1..99.
Comment 16 Timur 2018-10-11 15:49:38 UTC
*** Bug 90182 has been marked as a duplicate of this bug. ***
Comment 17 QA Administrators 2019-10-12 02:42:32 UTC Comment hidden (obsolete)
Comment 18 Timur 2019-11-24 12:59:46 UTC
Unchanged in LO 6.5+.
Comment 19 Timur 2019-11-25 07:55:37 UTC
*** Bug 83103 has been marked as a duplicate of this bug. ***
Comment 20 Timur 2019-11-25 07:55:52 UTC
*** Bug 87848 has been marked as a duplicate of this bug. ***
Comment 21 Timur 2019-11-25 07:55:56 UTC
*** Bug 100112 has been marked as a duplicate of this bug. ***