I just upgraded all of my clients from 4.3.4 to 4.4.03 After opening an XLS spreadsheet, editing and saving it as XLS in 4.4.03 and then opening it in Excel (any version), the horizontal arrows look like they disappeared BUT they are closed together and located in the bottom right. If I save the 4.4.03 in ODS format I get the same results when opening it in LO 4.3.5....
Hi Mateo, You can reproduce that with every document? If not, you mind sharing the source xls file, your saved version and a screenshot of the behavior? Thanks! Kind regards, Joren
Yes. All spreadsheets created with LO Calc version 4.4.03 have this problem. It works fine when viewing within 4.4.03.
Aah yes, I can reproduce. Tested using Windows 7 x64 with LibreOffice Version: 4.4.0.2 Build ID: a3603970151a6ae2596acd62b70112f4d376b990 Locale: nl_BE I'll upload some screenshots. I doubt this is not a regression, but I don't have any other LibreOffice version installed on this computer. If you mind testing 4.3.x or older versions and you can't reproduce, feel free to add 'regression' as "keyword". Thanks for filing this bug. Kind regards, Joren
Created attachment 113064 [details] Original document in Excel
Created attachment 113065 [details] roundtripped document in excel.
The issues does not exist in either version of 4.3.4 or 4.3.5
# bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6 git bisect bad 4a3091e95fa263d3e2dd81e56e83996f0bb12287 # good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474 git bisect good 812c4a492375ac47b3557fbb32f5637fc89d60d9 # good: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81 git bisect good 5d0dfb8e62ae61a240f8313c594d4560e7c8e048 # bad: [7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5] source-hash-f93ce4f7eb90093d0ea3115d0a1c614612676dbd git bisect bad 7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5 # good: [1a63057f6378db7c6b8af1171b7b140f7583f246] source-hash-59f84b4a2c082382767f12e0c7a06a3f0b52e721 git bisect good 1a63057f6378db7c6b8af1171b7b140f7583f246 # good: [2fdc98d4cfbffea5b33224bd2106aeb3b74b84a7] source-hash-d4a8fa7db0ed4faae00408fbda2352379774cfc0 git bisect good 2fdc98d4cfbffea5b33224bd2106aeb3b74b84a7 # bad: [3ff4aa6b7f147a98388d57e35368311034bceab6] source-hash-35e260c4a3e886c4177b232871f9f2775cd5c5f5 git bisect bad 3ff4aa6b7f147a98388d57e35368311034bceab6 # good: [67b357d7f313d5ff960b6cf6646053b11e04ef7c] source-hash-bf640ba048704220292411e4f2bcc0d3c62caa32 git bisect good 67b357d7f313d5ff960b6cf6646053b11e04ef7c # bad: [40670b887ae1c990ca10b37710cba6ab54e74300] source-hash-fe9f8144c7a1a5e51544b4dacb8a2d7e70b321ee git bisect bad 40670b887ae1c990ca10b37710cba6ab54e74300 # good: [bae1511898673d4c0ef583d050fc6c1a3661a775] source-hash-27d79b12e17a93f6e4eab2a3c09d423a4a04a63d git bisect good bae1511898673d4c0ef583d050fc6c1a3661a775 # first bad commit: [40670b887ae1c990ca10b37710cba6ab54e74300] source-hash-fe9f8144c7a1a5e51544b4dacb8a2d7e70b321ee 40670b887ae1c990ca10b37710cba6ab54e74300 is the first bad commit commit 40670b887ae1c990ca10b37710cba6ab54e74300 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun Oct 19 01:33:23 2014 +0000 source-hash-fe9f8144c7a1a5e51544b4dacb8a2d7e70b321ee commit fe9f8144c7a1a5e51544b4dacb8a2d7e70b321ee Author: Markus Mohrhard <markus.mohrhard@googlemail.com> AuthorDate: Mon Aug 25 16:11:54 2014 +0200 Commit: Markus Mohrhard <markus.mohrhard@googlemail.com> CommitDate: Tue Aug 26 13:34:03 2014 +0200 move method documentation to the header file Change-Id: I7d4f77c50a8b6b2b0d7c0868c73b0cb13f952421 :100644 100644 616f22676ee6e170445be33047a61e6a0bfca9bf 92780d1a277a2de1d7d320a562288a6da8ddd7e0 M ccache.log :100644 100644 6f8fab3a1532ca6e4875551815665c188d1b0539 d848246be29eb9c2fdf416eb3dd849f584f43c07 M commitmsg :100644 100644 1f86582d0cef6d5e72fa1c1a1342b2f469fa67ba 2ab4ff0d03499f61bea71951794580ea61e5fa80 M make.log :040000 040000 c7a9f52bf117560a8661f7128b9ce5bdacf18b86 1869ed0462a878bfb2afb3ebff5293a623932d21 M opt
This is a result of the new slider in branch 4.4 which has no fixed width(it takes the whole width of the program window). When opening a file created in 4.4 on any previous branch or other programs, because the slider width is not set, then it is probably set to 0 (zero) This is particularly problematic for people exchanging files with Excel users
Is it going to be fixed in any of the 4.4 versions? As long as MS Office is being used by most businesses, then compatibility issues like this will cause people to revert back to using MS products... I will test 4.3.6
Most probably the regression was caused by commit 1d1d1c62caf2ee6a96946e96d782e03f3ef80439 Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> Date: Mon Aug 25 18:20:58 2014 +0200 fdo#36772 Move the scrollbar and sheet tabs in a separate row. Change-Id: I57d891d9f6e89dafb4840a577ba55baa734fdcc2
Took the liberty of changing the bug title. The spelling error (scoll instead of scroll) caused this annoying regression not to be found when searching for "scroll bar" in the bug tracker.
Same problem exists in 5.0.0.5. I opened an xls spreadsheet in Calc, edited it, saved it. Opened it in Excel 2013 and the horizontal slide bar is completely closed. Most users says its missing, but its just completely closed and by clicking on the 3 dots in the far right and dragging to the left it opens the horizontal sliding bar backup.
5.0.3.2 has same issue. Will this ever get fixed????
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
(In reply to Andras Timar from comment #10) > Most probably the regression was caused by > commit 1d1d1c62caf2ee6a96946e96d782e03f3ef80439 > Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> > Date: Mon Aug 25 18:20:58 2014 +0200 > > fdo#36772 Move the scrollbar and sheet tabs in a separate row. > > Change-Id: I57d891d9f6e89dafb4840a577ba55baa734fdcc2 Yes. This patch broke the interoperability around that feature completely. We now need to decide if interoperability or the scrollbar in an own row are more important. IMHO it is interoperability but I suppose the UX people think otherwise. For now I will hard code a factor of 0.5. It is no longer possible to handle that correctly as the scrollbar is no longer resized. It used to be that tab bar and scrollbar were on the same row and therefore we could store the relative size of them.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6342041cdd700922af5e07cde0d1bd8e6ea42f0a hard code value for scrollbar to tabbar ratio, tdf#89058 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.
While this is currently only a work around I consider this "fixed". Without going back to a one row layout we can't get perfect interoperability again.
This also affects XLSX export according to the code.