Bug 72912 - VIEWING: Snap grid and cell grid misalignment
Summary: VIEWING: Snap grid and cell grid misalignment
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.2.3 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Grid-Helplines
  Show dependency treegraph
 
Reported: 2013-12-20 12:27 UTC by lujomu
Modified: 2021-05-01 03:56 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Spreadsheet with cell height/width and horizontal/vertical grid spacing set to 0.5 cm. Scrolled to the last row/colum, where the effect is very obvious. (6.75 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-12-20 12:27 UTC, lujomu
Details
Screenshots showing the issue (143.74 KB, image/png)
2014-11-10 07:40 UTC, Kevin Suo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lujomu 2013-12-20 12:27:05 UTC
Created attachment 91038 [details]
Spreadsheet with cell height/width and horizontal/vertical grid spacing set to 0.5 cm. Scrolled to the last row/colum, where the effect is very obvious.

Problem description:
If set to the same values, the grid (for 'snap to grid') does not match up with the cell width/height exactly.

Steps to reproduce:
1. Set the cell height and width to '0.50 cm' for all cells.
2. Make the grid visible (Options > LibreOffice Calc > Grid).
3. Set the grid horizontal and vertical grid spacing to '0.50 cm' (Options > LibreOffice Calc > Grid).

Current behavior:
The grid dots do not align with the cell lines. Especially the farther you scroll away from the first row/column.

Expected behavior:
The grid should match the cells exactly. So that if you draw a rectangle over a cell with snapping enabled, the lines of the rectangle should align with the cell.
              
Operating System: Windows 8
Version: 4.1.2.3 release
Comment 1 Dominique Boutry 2014-01-13 13:59:11 UTC
Reproduced with LibO 4.2.0.1 rc1 on Win7.

I wonder if it is a bug... I found no place in any worksheet software where the specification of the grid drawing should be mastered by the user at the pixel. Contrary to a drawing tool.
Comment 2 Kevin Suo 2014-07-19 09:00:40 UTC
In my opinion, althrough the cell height is set the same as "grid", but for cells, the cell borders also has some "height".
That's why there are 10 extra rows below the last "grid".
Comment 3 lujomu 2014-07-20 21:11:37 UTC
(In reply to comment #2)
> In my opinion, althrough the cell height is set the same as "grid", but for
> cells, the cell borders also has some "height".

That would make sense, but that would mean that the distance from one cell border to the next (cell height + border width) would have to be greater than the distance between two grid dots, which they are not. (This can easily be observed when scrolling down from the top of the sheet: In the beginning the grid dots are close to the cell borders, but as you scroll down they "move" downwards away from the cell borders. If the grid distance would be smaller than the border distance, the grid dots would "move" upwards.)

> That's why there are 10 extra rows below the last "grid".

For me the grid goes all the way to the last row/column.
Comment 4 Kevin Suo 2014-11-10 07:34:19 UTC
This bug was confirmed already, and is reproducible with version 4.3.3.2, Win 7 X86.
Set status to NEW.
Comment 5 Kevin Suo 2014-11-10 07:40:13 UTC
Created attachment 109193 [details]
Screenshots showing the issue

See screenshot, comparing the Snap Grid lines (with small dots) with the row height.
Comment 6 QA Administrators 2015-12-20 16:11:19 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2017-01-03 19:47:38 UTC Comment hidden (obsolete)
Comment 8 lujomu 2017-01-03 22:57:55 UTC
Bug is still present in v5.2.3.3 on Windows 10 Pro x64.
Comment 9 QA Administrators 2018-01-04 03:35:52 UTC Comment hidden (obsolete)
Comment 10 lujomu 2018-01-10 15:18:08 UTC
Bug is still present in v5.4.4.2 on Windows 10 Pro x64.
Comment 11 QA Administrators 2019-05-01 02:45:50 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2021-05-01 03:56:45 UTC
Dear lujomu,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug