Bug 130358 - [FORMATTING] Numbered List Improper Indent at 10 Position (since the extra digit puts numbering beyond tabstop with certain fonts)
Summary: [FORMATTING] Numbered List Improper Indent at 10 Position (since the extra di...
Status: RESOLVED DUPLICATE of bug 126690
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Writer-Styles-List
  Show dependency treegraph
Reported: 2020-02-02 02:43 UTC by SaphireWarlord
Modified: 2022-09-09 08:36 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Screenshot of Bug (22.91 KB, image/png)
2020-02-02 02:45 UTC, SaphireWarlord
Example Document with Formatting Bug (8.94 KB, application/vnd.oasis.opendocument.text)
2020-02-02 02:46 UTC, SaphireWarlord

Note You need to log in before you can comment on or make changes to this bug.
Description SaphireWarlord 2020-02-02 02:43:33 UTC
It appears that Writer is improperly indenting the 10th item in a numbered list, but only happens with a specific subset of fonts (so far I've discovered this behavior with Arial and Droid Sans Mono Slashed).

I tried typing text and it types after the cursor as expected, but still indented. With the little experimenting I did, changing fonts seemed to be the only solution.

Steps to Reproduce:
1. Open new doc in writer, toggle the numbered list, set the font to a specific font (see above)
2. Type text in lines 1-9
3. Type enter and observe the cursor is indented unexpectedly.

Actual Results:
The indentation is not aligned with the previous numbered entries.

Expected Results:
The indentation should line up with the previous 9 numbers.

Reproducible: Always

User Profile Reset: No

OpenGL enabled: Yes

Additional Info:
Comment 1 SaphireWarlord 2020-02-02 02:45:47 UTC
Created attachment 157588 [details]
Screenshot of Bug
Comment 2 SaphireWarlord 2020-02-02 02:46:54 UTC
Created attachment 157589 [details]
Example Document with Formatting Bug
Comment 3 Julien Nabet 2020-02-02 08:09:20 UTC
On pc Debian x86-64 with LO Debian package, I could reproduce this.
It does also the same shift with Liberation Serif but from 100th entry.
Comment 4 Roland Kurmann 2020-10-11 07:48:54 UTC
I can confirm this issue with LO on Linux with Bit Stream Vera Sans font at 10th position.
Comment 5 Roland Kurmann 2020-10-12 14:31:07 UTC
I've found the location of the problem. It is in sw/source/core/doc/number.cxx line 393ff:

        // position-and-space mode LABEL_ALIGNMENT
        // first line indent of general numbering in inch: -0,25 inch
        const long cFirstLineIndent = -1440/4;
        // indent values of general numbering in inch:
        //  0,5         0,75        1,0         1,25        1,5
        //  1,75        2,0         2,25        2,5         2,75
        const long cIndentAt[ MAXLEVEL ] = {
            1440/2,     1440*3/4,   1440,       1440*5/4,   1440*3/2,
            1440*7/4,   1440*2,     1440*9/4,   1440*5/2,   1440*11/4 };

The indents are hardcoded regardless of the dimensions of the font and the number of list number digits.

A quick fix is to increase the hard coded indent, eg. use 1600 instead of 1440.

Workaround: the first knob in the ruler can be manually dragged left to increase the indents.
Comment 6 Roland Kurmann 2020-10-12 15:24:28 UTC
> Workaround: the first knob in the ruler can be manually dragged left to
> increase the indents.

The workaround seems only to work on master (7.1), but not The knobs seems kind of broken in
Comment 7 Julien Nabet 2020-10-13 20:12:07 UTC
Scito: perhaps you can submit a patch on gerrit and wait for some LO dev experts feedback? You may also ping someone on dev LO IRC.
Comment 8 Timur 2021-08-31 14:50:32 UTC
This is basically a duplicate of bug 126690 but let's keep separate so far, in case that either is just partially resolved.
Comment 9 Justin L 2021-09-25 10:05:57 UTC
A matter of taste I guess. I expect that vast majority of numbering never reaches 10, and so increasing the space might look like too much space for the normal use case.

No errors here - just a disagreement about the defaults. I would tend to mark this as WONTFIX.
Comment 10 Timur 2022-09-09 08:36:49 UTC
I'll mark duplicate because it's a frequent request scattered around in multiple bugs.

*** This bug has been marked as a duplicate of bug 126690 ***