Bug 151562 - Text jumps down by a pixel after entering
Summary: Text jumps down by a pixel after entering
Status: RESOLVED DUPLICATE of bug 87420
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.4.2.3 release
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Cell-Edit-Mode
  Show dependency treegraph
 
Reported: 2022-10-16 10:11 UTC by fml2
Modified: 2022-11-10 22:27 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Base lines of the displayed value and the value being edited (2.99 KB, image/png)
2022-10-16 10:12 UTC, fml2
Details
Screencast MSO (33.22 KB, image/gif)
2022-11-02 14:56 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fml2 2022-10-16 10:11:35 UTC
I'm not sure whether it was like this in the previous versions of Calc, but now I notice the following:

If I enter a value into a Calc cell and then go to another cell (by pressing the Enter key or an arrow key or by clicking with the mouse) I see that the text jumps down by one pixel compared to where it was during the editing. I.e. the text base line is shifted down by one pixel.

Is this done intentiaonylly (to show that now the values is fixed)? Or is it a bug?
Comment 1 fml2 2022-10-16 10:12:50 UTC
Created attachment 183080 [details]
Base lines of the displayed value and the value being edited
Comment 2 fml2 2022-10-16 10:13:54 UTC
Version: 7.4.2.3 (x64) / LibreOffice Community
Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded
Comment 3 m_a_riosv 2022-10-16 11:56:36 UTC
But I'm not sure if it is really a bug or a way to remark the cell is being edited.
I have not can find another bug about this matter.

Not with
LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4

First with that I fave:
Versión 3.6.7.2 (ID de compilación: e183d5b)

Also with
Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 8991cbb7986d3967bc6c3719d95254ff04428d1a
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Jumbo
Comment 4 Heiko Tietze 2022-11-02 14:56:13 UTC
Created attachment 183378 [details]
Screencast MSO

Excel jumps numbers from right to left but when aligned left it still changes the border by a few pixels and also moves the content. Haven't tried other application but to just show the vertical I-beam cursor is not attracting enough attention. => NAB
Comment 5 Heiko Tietze 2022-11-02 15:00:34 UTC
The problem has been reported in bug 87420 for tall cells where the number is typically aligned to the bottom but jumps to top in edit mode. Quite some movement but still something is needed to indicate the switch to edit mode.

*** This bug has been marked as a duplicate of bug 87420 ***
Comment 6 fml2 2022-11-02 17:07:25 UTC
> Excel jumps numbers from right to left

Did you mean "from left to right"? This is partly true. If enter a number into aen empty cell in Excel, the editing is first aligned left. But when I finish editing (e.g. by pressing Enter) and the value is a number, the it jumps to the right. After that, when I edit the value (by going to the cell pressing F2), it remains aligned right. Vertical jumping is never present.


> but when aligned left it still changes the border by a few pixels and also moves the content.

The border is changed even if the value is aligned right, but the contents keeps its position -- vertically and horizontally.

IMO the current behaviour is too disturbing.
Comment 7 fml2 2022-11-02 20:19:47 UTC
I also disagree that this bug is a duplicate of bug 87420. There, the user changed the cell format.

In this bug I did not change anything in the cell format, just typed in a value.
Comment 8 Heiko Tietze 2022-11-08 08:34:35 UTC
(In reply to fml2 from comment #7)
> I also disagree that this bug is a duplicate of bug 87420. There, the user
> changed the cell format.

Bug 87420 discusses the fact that editing happens always top-aligned, which is your issue too but even more relevant of the cell height becomes larger. But if you insist to keep your ticket...
Comment 9 fml2 2022-11-10 22:27:05 UTC
Now I see that this ticket is really a duplicate. Sorry for the hassle.

*** This bug has been marked as a duplicate of bug 87420 ***