Bug 108273 - FORMATING: Tabstops behave strange when paragraph is right or middle aligned
Summary: FORMATING: Tabstops behave strange when paragraph is right or middle aligned
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.0.beta1
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Tab-Stops
  Show dependency tree / graph
 
Reported: 2017-05-31 23:12 UTC by David Fritzsch_LibreOffice
Modified: 2026-01-06 17:58 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
The problem with the Tabstops - and how it should be. (10.11 KB, application/vnd.oasis.opendocument.text)
2017-05-31 23:18 UTC, David Fritzsch_LibreOffice 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Fritzsch_LibreOffice 2017-05-31 23:12:03 UTC 
Description:
Tabstops doesn't follow the visual marks of the document rulers if paragraph is anything else than aligned to left.

Steps to Reproduce:
1. write a line or text and put somewhere a tab
2. click on the document rule above to set a left tabstop
3. align the line/paragraph right

Actual Results:  
Right align paragraph somehow also mirrors the tabstop
so for example: left tabstop is at 2 cm ; and page boarder is at 17 cm
=> the tabbed text will end at 15 cm 
so right align is turning the left tabstop to a right one using the right boarder.

That's confusing and anything else than easy to handle or work with.

Expected Results:
also on the right align paragraph the tabstop should work as shown on the document rules and place the tabbed word at 2 cm(from the left boarder)


Reproducible: Always

User Profile Reset: No

Additional Info:
Tested Microsoft Word 2013 and Wordpad of window 7 and both showing the same behavior.

But Libre Office should do it better that. 

Fix proposal #1:
Tapstops on right/middle aligned paragraphs should be rendered differently.


Fix proposal #2:
In case that is a kind of weird standard word processing software should follow
at least the document ruler should also follow it visually.

=> Now the tabstops at the ruler just stay were they are pointing to 'wrong' locations(if you're not smart enough for the weird logic behind scene) and so violating the WYSIWYG principle.


User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:53.0) Gecko/20100101 Firefox/53.0
Comment 1 David Fritzsch_LibreOffice 2017-05-31 23:18:34 UTC 
Created attachment 133763 [details]
The problem with the Tabstops - and how it should be.
Comment 2 Buovjaga 2017-06-09 16:53:49 UTC 
This would change a default behaviour and I guess break a lot of documents.
Adding UX to CC.
Comment 3 Heiko Tietze 2017-06-12 06:58:07 UTC Comment hidden (obsolete)
Comment 4 Heiko Tietze 2018-07-26 08:46:55 UTC 
We discussed David's proposal in the design meeting and agree that the issue is a bug. The attached document shows nicely how the ruler should indicate tab stops.
Comment 5 QA Administrators 2019-07-30 03:16:50 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2021-07-30 06:21:51 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2023-07-31 03:05:21 UTC Comment hidden (obsolete)
Comment 8 Regina Henschel 2023-08-07 20:19:16 UTC 
I see the bug still in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: b3053b63c65372627c5fb4df6b4ddcd5e12e16f7
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL threaded

When fixing the bug, make sure that the behavior is correct for right-to-left writing mode too. It might be that the current behavior was introduced for RTL documents.
Comment 9 QA Administrators 2025-08-07 03:10:31 UTC Comment hidden (obsolete)
Comment 10 Michael Markl 2026-01-06 17:58:39 UTC 
Disclaimer: I am no expert on document processing software.

I can confirm, the behavior is still the same on the latest LibreOffice version. For a right-aligned paragraph, the ruler still shows the tabstop as if the paragraph was left-aligned.
It seems to me that the calculation of the tab stops for center- and right-aligned paragraph mostly just pretends that the paragraph was left-aligned but with a different starting position, and calculates the tab stop widths according to that.
I agree that this is confusing (especially since the tab stops positions are rendered in the ruler as they would be for left-aligned paragraphs).
However, I am unsure whether this behavior should be changed:

(i) Behavior of the tab stops: The behavior of the alignment should probably not be changed, as that might break documents where tab stops are used together with center/right-aligned paragraphs. (However, I can see arguments for why the behavior of tab stops in right-aligned paragraphs do not make sense currently; the position (and directionality) of the tabs could effectively be "mirrored". For center-aligned paragraphs the concept of tab stops do not seem compatible at all, at least in my mind; I still wonder what the expected behavior should be here; the expected behavior in the example attached does not resonate with me: why is the part after the tab centered as if the part before the tab did not exist?).

(ii) Rendering of the tab stops in the ruler: I do not see how the rendering of the tab stop in the ruler can be improved here; of course, the tab stops could "jump" to the actual position based on the current starting position of the currently selected line(!) in the paragraph, but that would make editing the tab stops via the ruler infeasible (and probably the reason why / how the tab stops jump whenever the text (and hence the starting position of the line) is edited is not intuitive either).


Also, Microsoft Word still shows the same behavior (more precisely, Microsoft® Word for Microsoft 365 MSO (Version 2502 Build 16.0.18526.20546) 32-bit).

LibreOffice Version from About Dialog:
Version: 25.8.4.2 (X86_64)
Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df
CPU threads: 16; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Raster; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: threaded