Bug 163314 - Inconsistent cursor spacing in ordered list when using roman numerals
Summary: Inconsistent cursor spacing in ordered list when using roman numerals
Status: RESOLVED DUPLICATE of bug 162133
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.7.2 release
Hardware: All All
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Bullet-Number-Outline-Lists
  Show dependency treegraph
 
Reported: 2024-10-05 17:15 UTC by jacob
Modified: 2025-06-20 13:18 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
roman number list - tab bug - screenshot (44.71 KB, image/png)
2025-06-19 22:18 UTC, BDF
Details
roman number list - tab bug - example file (14.65 KB, application/vnd.oasis.opendocument.text)
2025-06-19 22:19 UTC, BDF
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jacob 2024-10-05 17:15:20 UTC
Description:
It may end up being a difference in solutions, but for higher width Roman Numerals that extend beyond a certain point there is the equivalent of a tab worth of white space between the Roman Numeral and the text connected to it.

This at least looks like a bug, as what happens the rest of the time is for the text to start a certain number of spaces after the letter, number, numeral, etc. When the text jumps to the next tab it looks inconsistent with the rest of the ordered list.

The same behavior occurs when using integers if the list gets to one hundred or more.

Steps to Reproduce:
1.In libreoffice writer, create any ordered list that includes roman numerals (upper or lower case).
2.Have a series of at least ten items that are listed with roman numerals.

Actual Results:
Text is uneven with a large amount of white space.

Expected Results:
Consistent placing of text relative to the list index (roman numeral, number, letter, etc.).


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 7.3.7.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 24; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.7
Calc: threaded
Comment 1 Dieter 2024-10-22 06:45:57 UTC
Thank you for reporting the bug. Could you please add a sample document. Are you aware of customization in position tab of bulets and numbering dialog?
=> NEEDINFO
Comment 2 BDF 2025-06-19 22:18:05 UTC
I can confirm this issue!

Once the letters of the roman number are too many for the content to be displayed at the first tab step, the text is moved out to the second tab step.

Version: 25.2.4.3 (X86_64) / LibreOffice Community
Build ID: 33e196637044ead23f5c3226cde09b47731f7e27
CPU threads: 12; OS: Linux 6.11; UI render: default; VCL: gtk3
Locale: de-AT (de_AT.UTF-8); UI: de-DE
Flatpak
Calc: threaded
Comment 3 BDF 2025-06-19 22:18:52 UTC
Created attachment 201366 [details]
roman number list - tab bug - screenshot

image for the bug
Comment 4 BDF 2025-06-19 22:19:51 UTC
Created attachment 201367 [details]
roman number list - tab bug - example file

(oh boy, am I glad that this bug was not closed for being in need of information for too long)
Comment 5 V Stuart Foote 2025-06-20 11:06:41 UTC
IMHO I don't see this as worth too much effort to adjust. Behavior now of shifting an ordered list to next tab stop is reasonable.

Alternative effort to bring a listing, no matter the width of the index/sequence ordering string, to a common positions (max-width +1, or max-tab step) seems too contrived.

Though I guess we do similar to support TOC

@Justin, what do you think?
Comment 6 Justin L 2025-06-20 12:51:32 UTC
This is probably a duplicate of bug 162133.

Whatever is done here needs to be compatible with Microsoft Office.

The poor look for Roman Numerals does happen using LO's default font (Liberation size 12 font). However, using a different font (Carlito at 11pt – which is basically identical in size to Microsoft Office’s default use of Calibri 11pt), then Roman numbering fits.

Ultimately, everything depends on the document content. As soon as you change font or font size, or involve sub-levels, then every assumption made gets thrown out of the window. In the end, it is the end-user's responsibility to design the list's formatting to fit their particular needs.


(In reply to jacob from comment #0)
> there is the equivalent of a tab worth of white space 

It is not "an equivalent". It is actually using a real tabstop. That is the way that your list is defined - a number followed by a tabstop. When the list-number ends beyond the "first" tabstop position of 1.27cm, then obviously a "tabstop character" will jump to the the next defined tabstop at 2.5cm - just like what happens everywhere else in a normal paragraph.

> This at least looks like a bug, as what happens the rest of the time is for
> the text to start a certain number of spaces after the letter, number, etc.

This is simply not accurate. The text never starts after "a certain number of spaces". It always starts "at the defined tabstop". You can easily see the tabstop-visual-character when you turn on View - Formatting marks.

roman listing.odt: You can prove this by going to Format - Bullets and Numbering. On the "Position" tab you will see "Followed by: Tab stop". You can change this to "Space" if you want, but I doubt you will want the ragged edge that this produces (unless you also change the alignment to "right"). What you probably want to do is change the tabstop and indent to 1.50cm for this particular document's content (or change the "Aligned at" to 1.1cm).
Comment 7 V Stuart Foote 2025-06-20 13:18:33 UTC
OK, a dupe. With same => WF outcome. Read comments there.

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