Created attachment 122245 [details] Shows Problem Tested on: Bodhi Moksha Problem on: Version: 5.2.0.0.alpha0+ Build ID: 182375f7a90ca53919fd2892f7856aee4d678dd0 CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; Locale: en-US (en_US.UTF-8) No Problem on: Version: 5.2.0.0.alpha0+ Build ID: d95d9d7f908419f397941ef60ac6ced3261c9b87 CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-01-19_00:40:21 Locale: en-US (en_US.UTF-8) [regression - relatively recent, build is from yesterday so problem from last 8 days] +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Steps: 1) Turn on bullets 2) Right click -> bullets and numbering 3) Position Tab; 4) Level (1-10) 5) Number Followed By: Space 6) Outline Tab; 8) Bottom left option (I., A., i., a), bullet) 9) Push ok; 10) Write three levels worth of text ("test" [enter][tab]; "test" [enter][tab]; "test Observed: Second level goes way too far to the right so tab space between second level("A. test") and third level ("i. Test") is not sufficient.
Reproduced in 5.2. Works ok in 5.0.4. Win 7 Pro 64-bit, Version: 5.0.4.2 (x64) Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78 Locale: fi-FI (fi_FI) Version: 5.2.0.0.alpha0+ Build ID: 259c1ed201f4277d74dfd600fed8c837cbf56abc CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-27_00:45:12 Locale: fi-FI (fi_FI)
Regression so bumping to high - trying to narrow commit range to nail this down before too much more is done in this area of the code.
This seems to have begun at the below commit. Adding Cc: to Nusaiba Al-Kindi; Could you possibly take a look at this one? Thanks 384f0ccc06147b1fabb0bbe513c17b5a0ee166a2 is the first bad commit commit 384f0ccc06147b1fabb0bbe513c17b5a0ee166a2 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Fri Jan 22 05:06:32 2016 -0800 source 6517141b6233c5f9667031bc92f66109fddf5b76 source 6517141b6233c5f9667031bc92f66109fddf5b76 :040000 040000 c5f61eceaaaf998e0988ce1f12b46d0bcca975eb 61a355244aa17a656e77e15dbf5de9b14199cd4c M instdir author Nusaiba Al-Kindi <noseeba1@gmail.com> 2016-01-21 11:38:03 (GMT) committer jan iversen <jani@documentfoundation.org> 2016-01-21 19:39:22 (GMT) commit 6517141b6233c5f9667031bc92f66109fddf5b76 (patch) tdf#42788: FORMATTING - Numbering/ordered list
Adding JanI also since he pushed the commit. @Jan - it seems like this patch broke outlining in 5.2 (second level indentation is entirely wrong) Do you think the patch should be reverted?
The problem is in a single file: editeng/source/items/numitem.cxx which was changed in https://gerrit.libreoffice.org/#/c/21439 Unless someone object, I prefer to make an easyHack out of it, instead of reverting it.
Still no fix - I'm really hoping this doesn't get out into fresh release as it is pretty disruptive for people using outlines extensively...
Hi, can I already take this easyHack?
Hi, can I still take this easyHack? (sorry for the error)
Yeah I think so - the patch was just reverted so you'll want to look at what the patch was supposed to do and then fix what it did wrong. JanI can input more but I'm pretty sure that's where we are.
Well, I found the problem, an it was the change itself. When he tried to right align the Roman Numbers, he set the eNumAdjust variable to SVX_ADJUST_RIGHT instead of SVX_ADJUST_LEFT, and only with this change problems whit the numbering appears. So there are two solution, one is to revert the change, as if we delete this part, this didn't do anything else, the other is to try to change other variables in order to obtain the results we want (what I already didn't know so well).
In my opinion , let's try to change others variables to get the result expected. I am having a look and I found: /core/include/editeng/numitem.hxx 122 short nFirstLineOffset; // First line indent 123 short nAbsLSpace; // Distance Border<->Number 124 short nCharTextDistance; // Distance Number<->Text So, the variable 'nAbsLSpace' seems to be the variable that we should modify in this case. Am I right ? But I am still looking for the place where the current code is setting this variable.
Created attachment 123745 [details] A posible solution. well, I think I found a solution to either the problem with the Roman Numbers and the problem with the fix https://gerrit.libreoffice.org/#/c/21439 The only downside is that if someone take the option to change the align of the Roman Numbers manually, he will see again the problem with the Roman Numbers (which really is that the program add an extra tab when the Roman Number is long enough to pass through the line of the first tab. It also happen with any other numbering that cross that line). I prove it and it works in Ubuntu 14.04, x64.
another option that will solve all problems is to put the default align to Right instead to Left.
The attachment 123745 [details] does not work. I cannot open it. Am I doing something wrong?
It's a .zip file with the two files I modified, ready for merge and build with the source code you can download from the web. (sorry, is the way I thought it will be easier).
(In reply to Alfredo from comment #15) > It's a .zip file with the two files I modified, ready for merge and build > with the source code you can download from the web. (sorry, is the way I > thought it will be easier). Please submit the patch to our gerrit system, that way you get acknowledgement for the patch. Se more: https://wiki.documentfoundation.org/Development/GetInvolved I also cannot open your attachment. rgds jan i
ok, there it's https://gerrit.libreoffice.org/#/c/23427/
(In reply to Alfredo from comment #17) > ok, there it's https://gerrit.libreoffice.org/#/c/23427/ I'm going to build tonight with this and I'll report back as I use outlines daily.... Do you think it'll fix outlines that are borked due to the bug? So far, opening the files in older versions of LibreOffice maintain the broken bullets....which sucks (several 50+ page outline files that are much harder to follow :-/ )
Nevermind - the commit was abandoned so I can't test.
(In reply to Joel Madero from comment #19) > Nevermind - the commit was abandoned so I can't test. The gerrit abandon and your possibilities to test are 2 very different things ! Of course you can test as you like in your local environment, and once you have a fix. The patch was abandoned, because the error it caused was disturbing to many people, in fact had I seen it I would never have merged it in the first place. I let the patch stay merged for quite a while, giving you a chance to fix the patch directly. Abandoning a patch happens regulary, but does not mean anything but "this disturbes master, please submit a new fix".
I'm not fixing the patch, I was just going to test the patch. Since it broke things, I'll wait for another fix.
I have coded a fix already. I am going to submit it. Basically if we decided to align to the right roman numbers, every line in that list has to be aligned to the right. We cannot have in a list some lines with their numbers aligned to the right and others to the left. That is the solution I have coded and I am going to submit to review.
I am dealing with SSH connexion to submit the patch. if anyone is an expert at this and want to have some fun fixing my SSH problem let me know. Meanwhile I keep on sort this out (SSH)
(In reply to Jose from comment #23) > I am dealing with SSH connexion to submit the patch. if anyone is an expert > at this and want to have some fun fixing my SSH problem let me know. > Meanwhile I keep on sort this out (SSH) Better to ask on #libreoffice-dev IRC channel
I have committed already the patch. So, "Outline spacing wrong on 2nd Level". Which is normal as in the same list, the labels in some lines are aligned to the right (Roman Numbers) and the labels in other lines are aligned to the left (letters, decimal numbers..) which gives the appearance that there is something wrong with the indentations. It is not the best way to solve this problem but it works. The solution is in lo/core/editeng/source/items/numitem.cxx where I say that if the first line is aligned to the right because is a roman number the rest of the lines in that list will be aligned to the right as well , no matter if they are not roman numbers.
With two people simultaneously committing patches and them being rejected/conflicted out it's becoming difficult to see where this bug stands. Can I get a link to the merged commit that I can pull to test results?
Here is the like to my patch: https://gerrit.libreoffice.org/23542
To get it from github: git pull ssh://jose55@gerrit.libreoffice.org:29418/core refs/changes/42/23542/3
Joel,are you willing to do my code review ? or ... how does this work ? Because in the list of bugs I see many 'verifies' but no 'code review'. Do I have to wait and that's it? Thanks
(In reply to Jose from comment #29) > Joel,are you willing to do my code review ? > or ... how does this work ? > Because in the list of bugs I see many 'verifies' but no 'code review'. > Do I have to wait and that's it? > > Thanks I can't do code review as I don't know the code well enough to determine if the patch is done right. All I can do is check to see if my particular issue is resolve (in otherwords I can't check for regressions or poorly written hacks). I'm currently building but likely won't have time until tomorrow to really investigate. For code review you'll just have to wait for one of the expert developers to check (probably JanI in this case)
Update on this - it's better but still not right. Compare 3.3 to current master. The indent is much more noticeable in 3.3 than current master (although current master is way better than the regression originally)
Created attachment 124470 [details] outline in 3.3 - better indentation between levels
Created attachment 124471 [details] Current Master Indenting
My mistake - I don't think I pulled the commit. Doing so now and building. Will check back (sorry for noise)
And - it conflicts so I can't cherry pick. As far as I can tell the patch is being rejected and needs updated.
(In reply to Joel Madero from comment #35) > And - it conflicts so I can't cherry pick. As far as I can tell the patch is > being rejected and needs updated. Yes the patch was rejected, because it had unfortunate side effects (reported by others), that is the reason the issue has status "NEW". It is a pity, because the patch was close, but it seemed that there was no-one who wanted to finalize it.
A polite ping, still working on this issue ?
Just a heads up - this is still an issue and still makes numbering almost useless. Looks like it's going to end up being in the next major release....which is unfortunate. Are we 100% sure that not just reverting the broken patch completely wouldn't be a better solution than waiting indefinitely (months on end at this point despite knowing what commit broke things)?
Sorry should have included: Bodhi Linux Version: 5.2.0.0.alpha1+ Build ID: 369ca1d72bc877c6ccce991c92ae1a246956ca57 CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-05-22_14:48:27 Locale: en-US (en_US.UTF-8)
I'm confident in saying this has been abandoned. Two pokes - and nearly 3 months without confirming that work is still being done. If this isn't the case feel free to set to assigned and add your name again to assignee
Alfredo was not in CC list, adding to make sure he abandoned this work.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8617010b851e000f336cf647f207557b5eeab8b7 Resolves: tdf#97404 outline space wrong on second level It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9cdf38e11f50e8b420e017b2dcf6b36f9f77c400&h=libreoffice-5-2 Resolves: tdf#97404 outline space wrong on second level It will be available in 5.2.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-2-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9a934b04754586111c5083983e8459616ec051db&h=libreoffice-5-2-0 Resolves: tdf#97404 outline space wrong on second level It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.