Created attachment 68878 [details] Its a window screenshot, this is the wrong indent in list items. Problem description: When I make lists, these has indent "constant" but after list 9 item the items has big indents. Steps to reproduce: 1. Make a list until it exceeds 10 items Current behavior: Wrong formatting Expected behavior: Fix this bug :) Platform (if different from the browser): Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0
Yes, that's an old problem inherited from OOo, see Sample document Unfortunately I never had a good Idea how that problem can be solved. I thought we should already have a bug for that, but I was not able to find it.
Created attachment 68898 [details] Sample Document The sample document shows the different distances between numbering and content when you open it with 3.5
for me not reproducible with LO 4.0.1.2 (Win7 Home, 64bit) Does this issue still persist for you with the latest release of LO?
Confirmed with: LO 4.0.2.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Could not reproduce with two digits, but reproducible with three digits.
Created attachment 86690 [details] 3 digits numbered list bug still present in 4.1.1.2 under Win7 64bit. see my sample document. larger indent after item 100. I'm not also very happy about the alignment of first 10 items.
Restricted my LibreOffice hacking area
** 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 (4.4.2 or later) 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) http://downloadarchive.documentfoundation.org/libreoffice/old/ 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
(In reply to tommy27 from comment #5) > Created attachment 86690 [details] > 3 digits numbered list > > bug still present in 4.1.1.2 under Win7 64bit. see my sample document. > larger indent after item 100. I'm not also very happy about the alignment of > first 10 items. Repro from scratch. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58 Locale: fi-FI (fi_FI)
As I understand it's NOT a bug, this is correct behavior. MS Word does the same. The formatting is dependent on font type, font size, another paragraph settings. On "10" line default tab stop is too small. Therefore it's necessary to make first tab longer. To fix this formatting issue user makes usually first custom tab stop at the appropriate position. After that text in number list started from the same position. This works in MS Word, but unfortunately it's not working in LibreOffice because of that bug ( https://bugs.documentfoundation.org/show_bug.cgi?id=94028 ). LO could by default create first custom tab stop automatically, that would fix this issue. But here we will have another problem. If the listing contained 8 lines, the tab position was one width. After a while another 3 lines were added, then automatically tab position need to be expanded. This potentially could break formatting of previous lines. IMHO, user should make decision about width of first tab.
** 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) http://downloadarchive.documentfoundation.org/libreoffice/old/ 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! Warm Regards, QA Team MassPing-UntouchedBug-20170103
bug still present in LibO 5.2.4.2
Bug also present in 5.3.0.3 (on Manjaro 64-bit).
IMO, the problem here is not a bug, but a poor default choice. By default, lists have two tab stops, the first one to indicate number position and alignment and the second one to indicate first line indent for text. The first tab for numbers is aligned "to the left" and that means that when the number is wider than the space left by the indent tab the text get pushed to the right. The easiest solution to this problem is to change the alignment for the number's tab stop to be aligned to the right, so instead of 9. Text 10. Text which is the current default behaviour, you get a nicer list like 9. Text 10. Text which is the default behaviour of lists in LaTeX. So maybe this bug report could be changed into a feature request to change the default value for numbering alignment on lists.
(In reply to RGB from comment #13) > IMO, the problem here is not a bug, but a poor default choice. > > By default, lists have two tab stops, the first one to indicate number > position and alignment and the second one to indicate first line indent for > text. The first tab for numbers is aligned "to the left" and that means that > when the number is wider than the space left by the indent tab the text get > pushed to the right. The easiest solution to this problem is to change the > alignment for the number's tab stop to be aligned to the right, so instead > of > > 9. Text > 10. Text > > which is the current default behaviour, you get a nicer list like > > 9. Text > 10. Text > > which is the default behaviour of lists in LaTeX. > > So maybe this bug report could be changed into a feature request to change > the default value for numbering alignment on lists. Let's ask UX.
(In reply to RGB from comment #13) > IMO, the problem here is not a bug, but a poor default choice. Some work has been done regarding default list styles in bug 106988. But the issue here will not finally be solved by any style. Think about roman numbering like MMXVII that quickly exceeds the first tab width. The only solution is the dynamically adjust the tabs, which requires a format change (for consistency). Nonetheless we should take care about this issue when defining new default styles in order to make them work in the usual environment for 1..99.
*** Bug 90182 has been marked as a duplicate of this bug. ***
Dear Jordy, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Unchanged in LO 6.5+.
*** Bug 83103 has been marked as a duplicate of this bug. ***
*** Bug 87848 has been marked as a duplicate of this bug. ***
*** Bug 100112 has been marked as a duplicate of this bug. ***