Issue 86994

@shana:
Pls. specify your OOo localization,  OS and Platform
Pls. attach a sample document and a step by step instruction how to reproduce
your problem.

Created attachment 52091 [details]
Please see the work sheet named "PART 3" cell B4

I checked with "2.4 RC2  Multilingual German version WIN XP:
[680m8(Build9276)]", screen 1024x76, and can confirm the problem. 

Stepst to reproduce:
1. Open "Customer AAA.ods"
2. Doubleclick into 'A4', a cell that exceeds the viewable area on  screen
3. Mouse click into first word "Ddd" of cell
4. move down caret iwth arrow key 'down'until disappears out of view, and 
  then 3 seconds more
  expected: vie should scroll, so that caret remain visible
  actual: no scroll
5. No try to scroll down using vertical scroll slider
   expected: it should be possible to scroll to the bottom end of 'B4', 
             so that the caret becomes visible 
   actual: after the top of the cell reaches the top of the visible area of 
           the screen, the view jumps to Row 5
   
Related Issue 55020?
I am pretty sure that I saw another issue with just the problem reported here,
but I can not remember the issue number.

@shana:
Pls. specify your OOo localization, OS and Platform

*** Issue 94221 has been marked as a duplicate of this issue. ***

This issue still exists in OOo 3.2.0 m12 (build 9483),
on PC running Linux french version (with Gnome).
I would expect that this issue affects *all* platforms and localisations.
---
1) *The defect*
As well as skipping parts of multi-line cells, cell rows close to but smaller
than the window height are skipped in scrolling, and the user has to use the
mouse and keyboard arrows to move the skipped rows into view.

E.g., with a scroll increment of 3, and a series of cells more than half the
height of the window, starting with A4 (with only line 4 in view), scrolling
down one increment (with the mouse wheel) goes to A7, with only line 7 in view,
having skipped A5 and A6.  One then has to use the keyboard arrow to bring A5 or
A6 into view.

So we want to avoid skipping cell_rows or lines_inside_cells.

The simplist solution seems to be counting lines instead of cell rows.
Assuming a scroll increment of 3 lines, one scroll increment would be :
- 3 rows of 1 line, or
- 1 row of 2 lines, with or without another row of 1 line or
- 1 row of 3 lines
Anything else would scroll within one cell.
Except for scrolling within a cell, the top of the window would continue be the
first line of a cell.
---

2) *A useful related enhancement*
Add an option to set the scroll increment.

The scroll increment is now often set by the environment.
(Which may be configurable or not.)

User preferences for scroll increments could depend on the application being
used.  Thus it is better to have a configurable scroll increment in the
spreadsheet, instead of being the same for all OOo modues.
The way Calc works now, this is particularly important.
(But still useful if scrolling is based on lines instead of cell_rows.)
---
Note that issue# 92588 is a variation of this issue (but on the Macintosh platform).
(Counting by lines instead of cell rows would work for that issue as well.)