Bug Hunting Session
Bug 94028 - numbering style with number followed by TAB does not work correctly
Summary: numbering style with number followed by TAB does not work correctly
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.5.2 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Bullet-Number-Outline-Lists Paragraph-Tab-Stops
  Show dependency treegraph
 
Reported: 2015-09-08 13:27 UTC by Ulrich Windl
Modified: 2019-09-20 07:33 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Test Document (12.17 KB, application/vnd.oasis.opendocument.text)
2015-09-17 06:18 UTC, Ulrich Windl
Details
PDF from LibO 5.0.1 (20.11 KB, application/pdf)
2015-09-17 11:43 UTC, Buovjaga
Details
shows problem with first/second tab stop (different tab stop settings) (14.76 KB, application/vnd.oasis.opendocument.text)
2015-12-02 10:24 UTC, Andrey Skvortsov
Details
shows problem with first/second tab stop (different tab stop settings) (render) (23.84 KB, application/pdf)
2015-12-02 10:24 UTC, Andrey Skvortsov
Details
breaks numbering formatting in docx (14.36 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-12-02 10:59 UTC, Andrey Skvortsov
Details
breaks numbering formatting in docx (msword 2010 / lo 5.0.3.2) side by side (211.97 KB, image/png)
2015-12-02 11:02 UTC, Andrey Skvortsov
Details
breaks numbering formatting in docx (msword 2010 / lo 5.0.3.2) side by side (2) (213.31 KB, image/png)
2015-12-02 11:03 UTC, Andrey Skvortsov
Details
Another test document created with LO 5.1.6.2 (Windows), saved with LO 5.2.3 (Linux) (9.27 KB, application/vnd.oasis.opendocument.text)
2017-01-04 07:53 UTC, Ulrich Windl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2015-09-08 13:27:17 UTC
When using numbering styles where the number is followed by a TAB, the position of the first character after the number is not at a TAB position defined in the paragraph style.
For example I have exactly one left TAB defined at 1cm, but the first line is indented by about 0,5cm after the number. When manually inserting a TAB at the beginning of the line, the position seems correct.
Sometimes, but no all the time, it helps to change the list style to use "none" after the number, save the style, and later return to "TAB" after the number.
Comment 1 Buovjaga 2015-09-15 15:14:52 UTC
Can you give exact steps to repro and/or an example document?

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Comment 2 Ulrich Windl 2015-09-17 06:18:58 UTC
Created attachment 118781 [details]
Test Document

A sample document showing the problem: There is one tab after the number, but the indent of the first line does not match the tab stop in the paragraph style. I can't give a better description.
Comment 3 Buovjaga 2015-09-17 11:43:39 UTC
Created attachment 118794 [details]
PDF from LibO 5.0.1

Doesn't exactly match the description (the first line is NOT indented by about 0,5cm after the number, but more like 0,3 cm), but I guess I confirm.

Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: fi-FI (fi_FI)
Comment 4 Ulrich Windl 2015-09-18 06:21:33 UTC
I still don't understand why you set a bug to "minor" if some very basic formatting is broken.
To add some fun to this bug: If I open the ODT with Microsoft Word 2010 (although it says the file is damaged), the formatting is correct!
Comment 5 Buovjaga 2015-09-18 06:51:37 UTC
(In reply to Ulrich Windl from comment #4)
> I still don't understand why you set a bug to "minor" if some very basic
> formatting is broken.
> To add some fun to this bug: If I open the ODT with Microsoft Word 2010
> (although it says the file is damaged), the formatting is correct!

Because this is a tracker for bugs so all the things that we deal here are broken and everything is relative: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Comment 6 Timur 2015-10-13 15:06:25 UTC
I guess final position of a tab after a number depends first on paragraph style (here: before 1 cm, first -1 cm) and then numbering style (here: aligned 0 cm, tab 0,5 cm).
Not sure this is a valid bug. Maybe a question for Ask LO.
Comment 7 Ulrich Windl 2015-10-14 09:02:14 UTC
(In reply to Timur from comment #6)
> I guess final position of a tab after a number depends first on paragraph
> style (here: before 1 cm, first -1 cm) and then numbering style (here:
> aligned 0 cm, tab 0,5 cm).

That's part of the problem: The user cannot see the TAB position in the dialog of numbering style: The fields in the position tab belob the tabulator are empty! So the typical user thinks the TABs defined in the paragraph style are used.
Comment 8 Andrey Skvortsov 2015-12-02 10:23:02 UTC
I confirm this bug. The problem exists in LO 5.0.3.2 on Windows/Linux (amd64). 

My observation shows that if numbering is selected, then to the paragraph defined custom tab stop settings added another tab stop at the same position as first DEFAULT tab stop. Because of that usually only first two tab stops are affected. All the rest tabs are correct.

I created simple ODT document, that shows problem with different positions of the first custom tab stop position. Additionally PDF render of the document is uploaded.
Comment 9 Andrey Skvortsov 2015-12-02 10:24:21 UTC
Created attachment 120950 [details]
shows problem with first/second tab stop (different tab stop settings)
Comment 10 Andrey Skvortsov 2015-12-02 10:24:53 UTC
Created attachment 120951 [details]
shows problem with first/second tab stop (different tab stop settings) (render)
Comment 11 Andrey Skvortsov 2015-12-02 10:59:52 UTC
Created attachment 120952 [details]
breaks numbering formatting in docx

Another issue related to that is compatibility with docx. If docx document with numbering is open in LO, formatting is broken. 

To show that I've created simple docx document and side-by-side screenshots of word 2010 and LO 5.0.3.2. Pay attention to the tab stop settings shown on the ruler on all screenshots.

If you open and save this document in LO as docx and open it in MS Word again, you'll see on ruler, that LO inserts additional tab stop in docx. As result after saving document in LO formatting is broken in MS Word too.
Comment 12 Andrey Skvortsov 2015-12-02 11:02:11 UTC
Created attachment 120953 [details]
breaks numbering formatting in docx (msword 2010 / lo 5.0.3.2) side by side

This screenshot shows problem if there are many tab stops in paragraph settings
Comment 13 Andrey Skvortsov 2015-12-02 11:03:07 UTC
Created attachment 120955 [details]
breaks numbering formatting in docx (msword 2010 / lo 5.0.3.2) side by side (2)

This screenshot shows problem if there is one tab stops in paragraph settings
Comment 14 Andrey Skvortsov 2015-12-02 11:33:55 UTC
This bug prevents fixing formating issue described here https://bugs.documentfoundation.org/show_bug.cgi?id=56258 . See my comments there.
Comment 15 Andrey Skvortsov 2015-12-05 17:53:59 UTC
After further investigation I can say, that width of this "additional" tab, that is added if numbering is selected, is defined by option in "Menu->Format->Bullets and Numbering", tab "Position", field "at&:" and is by default 0.5".
Comment 16 QA Administrators 2017-01-03 19:42:09 UTC Comment hidden (obsolete)
Comment 17 Ulrich Windl 2017-01-04 07:49:08 UTC
I still see the bug in this environment:
Version: 5.2.3.3
Build ID: 20m0(Build:3)
CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; 
Locale: de-DE (en_US.UTF-8); Calc: group

I had created another test document (bug-94028) to verify: A numbered list with two items, each using the same paragraph format. The first item has wrong indent after line 2, while the second item has correct indent.
Comment 18 Ulrich Windl 2017-01-04 07:53:22 UTC
Created attachment 130137 [details]
Another test document created with LO 5.1.6.2 (Windows), saved with LO 5.2.3 (Linux)

The items of the numbered list were added with different versions of LibreOffice; maybe that makes the difference. Anyway, it's a bug.
Comment 19 Regina Henschel 2017-12-31 18:40:27 UTC
see also bug 111932 (only comment 6 for to skip off-topic parts). There is a problem in the order of actions.