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.
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.
Created attachment 118781 [details]
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.
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: 184.108.40.206 (32-bit)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: fi-FI (fi_FI)
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!
(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
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.
(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.
I confirm this bug. The problem exists in LO 220.127.116.11 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.
Created attachment 120950 [details]
shows problem with first/second tab stop (different tab stop settings)
Created attachment 120951 [details]
shows problem with first/second tab stop (different tab stop settings) (render)
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 18.104.22.168. 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.
Created attachment 120953 [details]
breaks numbering formatting in docx (msword 2010 / lo 22.214.171.124) side by side
This screenshot shows problem if there are many tab stops in paragraph settings
Created attachment 120955 [details]
breaks numbering formatting in docx (msword 2010 / lo 126.96.36.199) side by side (2)
This screenshot shows problem if there is one tab stops in paragraph settings
This bug prevents fixing formating issue described here https://bugs.documentfoundation.org/show_bug.cgi?id=56258 . See my comments there.
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".
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice
(5.1.6 or 5.2.3 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
I still see the bug in this environment:
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.
Created attachment 130137 [details]
Another test document created with LO 188.8.131.52 (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.
see also bug 111932 (only comment 6 for to skip off-topic parts). There is a problem in the order of actions.