Created attachment 43775 [details]
Spreadsheet with large row heights showing that scrolling is broken.
A spreadsheet with large row heights (e.g. a big description) - even larger than your screen height - should of course still be easy to work with. However for no good reason LibreOffice's scrolling in spreadsheets is designed to snap to rows and this makes it hard - or almost imposslble - to work with spreadsheets with large row heights.
Of course scrolling should be like in a webbrowser - natural and smooth - but instead LibreOffice moves in big jumps like a broken mouse.
Try scrolling up and down in the attached spreadsheet - and perhaps even type a big amount of text and while typing use the scrollbar to position the text/cursor where you want vertically. It's impossible.
[Reproducible] with "LibreOffice 3.3.1 – WIN7 Home Premium (64bit) German UI [OOO330m19 (build 8 / tag 18.104.22.168)]".
Old OOo problem, but I just can't find the corresponding Issue No.
Only talks about mouse wheel scrolling
Affected is not only vertical, but also horizontal scroll, if you create a column with 50 cm width, you cant do a horizontal scroll the middle of the column.
As reporter said, reason is that the first top left cell shown in the spreadsheet always will snap to visible range area, you will never see only a part of the cell at the top or left end of the visible area.
I do not know whether there might be good reasons for the current behavior.
We have been living with that problem from the beginning of OOo, so it's not a blocker.
MS EXCEL VIEWER has the same limitation.
Assigning to Kohei; as always, feel free to assign back to list if you feel having this on your list is not useful. Please add a comment if you have insight in how hard it would be to fix this.
Actually google docs (and, I think, Excell) has the same frustrating problem too.
It's interesting that since Microsoft started this trend "everybody" has mimicked it without questioning wether it's good - or - more likely - bad.
(In reply to comment #3)
> Actually google docs (and, I think, Excell) has the same frustrating problem
> It's interesting that since Microsoft started this trend "everybody" has
> mimicked it without questioning wether it's good - or - more likely - bad.
I wouldn't call this "mimicking without questioning" (which I take slight offence with since that implies we developers don't think), but rather it's hard to overcome that given how spreadsheet works.
BTW Excel solved this in 2007.
"Bug 40917 - UI: scrolling only by full row height" is not exactly the same issue, but I believe a common solution would be fine.
(In reply to comment #5)
> "Bug 40917 - UI: scrolling only by full row height" is not exactly the same
> issue, but I believe a common solution would be fine.
BTW scrolling by full row height is done for a reason, and it's not practical to solve it without causing other, more serious issues mostly in the performance area. So, don't expect Bug 40917 to be solved anytime soon, if ever.
BTW this is what Anurag Jain's GSOC work - support multi-line formula input bar - aims to resolve. There was a bug filed for that (can't remember the number), and I would say it's more appropriate to mark this as a duplicate of that bug.
*** Bug 41139 has been marked as a duplicate of this bug. ***
Noel is currently looking into the new input bar.
*** Bug 46505 has been marked as a duplicate of this bug. ***
Reproducable on v22.214.171.124 - view still jumps horribly.
Also if you have a cell/row heigher than the window with the content vertically aligned to the bottom it's IMPOSSIBLE to see that text since it's ALWAYS outside the screen becuase you can't scroll in steps smaller than the row height.
A real showstopper this one.
(In reply to comment #11)
> A real showstopper this one.
'showstopper' really? especially since you say Excel or Google docs do the same thing, its been like this forever etc. etc.
I think your scenario is not that common, this hardly this qualifies as a showstopper. Further more as Kohei explained this is by design ( admittedly there is room for improvement ) therefore I am making this an enhancement.
Anyway since the new inputbar does allow you to view and edit text that would normally be hidden in this scenario the situation has been improved somewhat.
Since the reporter seems not to think the inputbar addresses this issue I am returning this to the pool.
I agree - it's a "showstopper" only in the - admittedly rare - situation where the cell exceeds the window-size.
The formular bar I agree makes it possible to see the text after all - not nicely but barely.
*** Bug 114849 has been marked as a duplicate of this bug. ***
*** Bug 84099 has been marked as a duplicate of this bug. ***
*** Bug 70525 has been marked as a duplicate of this bug. ***
Sadly this behaviour is really annoying. Smooth scrolling would be nice.
Unfortunately the docs for developers are not very good, I would really like to improve some stuff for LO :( Maybe someone can contact and help me (I use a Mac).
(In reply to lupurus from comment #17)
> Sadly this behaviour is really annoying. Smooth scrolling would be nice.
> Unfortunately the docs for developers are not very good, I would really like
> to improve some stuff for LO :( Maybe someone can contact and help me (I use
> a Mac).
A few pointers:
https://opengrok.libreoffice.org (core project)
I checked all the pages, but developing for Mac is so badly documentated. I gave up, because it was too frustrating. Couldn't find out how to create the Xcode-project.
I landed on this page from one of the duplicates. I would like to extend the issue to "Cell with large dimensions make LibreOffice Calc impossible/unpleasant to work with".
In my daily work I have to deal with CSV and other form of spread sheets that have lengthy texts as the cell values (typically column names) and when I scroll horizontally the jump are as big as the width of the column that just had disappeared!
It would be wise to have an option in the preferences to let user choose between "smooth scrolling" and "legacy scrolling".
I'll be happy to provide testcase if the explanation I provided is not clear enough.
This is a serious issue and it is slightly worrying that it has been almost 8 years since this issue have been reported and yet no tangible action have been taken so far!
An obvious workaround is to zoom out on the sheet. If that reduces legibility too far, then use assorted text function to split the text into different cells nearby, or reformat the cells using wrap etc. as appropriate.
(In reply to Libomark from comment #21)
> An obvious workaround is to zoom out on the sheet. If that reduces
> legibility too far, then use assorted text function to split the text into
> different cells nearby, or reformat the cells using wrap etc. as appropriate.
Modifying the layout of the document is not always an option. My most recent occurrence of this issue was updating finding status on a STIG viewer spreadsheet export (which needed to be re-imported into the tool).