Bug 48245 - Snapping to grid does not work accurately (depending on zoom level)
Summary: Snapping to grid does not work accurately (depending on zoom level)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.4 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Snap
  Show dependency tree / graph
 
Reported: 2012-04-03 07:05 UTC by Edu
Modified: 2023-06-04 03:16 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
A sample of this behaviour and the grid options (65.10 KB, image/png)
2012-04-03 07:05 UTC, Edu 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Edu 2012-04-03 07:05:30 UTC 
Created attachment 59423 [details]
A sample of this behaviour and the grid options

I've tried to draw with the grid activated, and although the measure of the grid works, the drawing is not fixed correctly to the grid points.

Steps to reproduce:
1. Go to: Tools -> Options -> Writer -> Grid, and set the parameters that the attached picture shows
2. Draw a line between two point of the grid

Current behavior:
The line doesn't adjust correctly to the grid points

Expected behavior:
The line should start and finish exactly in points that grid shows

Platform:  Windows 7 x64
              
Browser: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.142 Safari/535.19
Comment 1 sasha.libreoffice 2012-08-07 09:05:58 UTC 
Thanks for bugreport
[reproduced] in 3.3.4, 3.5.5, 3.6.0rc on Fedora 64 bit
Though snapping to grid works, it is shifted against of dots of grid. This problem is Writer-specific, in Calc and Draw snapping is correct.

Change version to 3.3.4 as most early reproduced
Comment 2 QA Administrators 2015-01-05 17:52:20 UTC Comment hidden (obsolete)
Comment 3 Buovjaga 2015-01-28 18:24:40 UTC 
Reproduced.

Win 7 Pro 64-bit Version: 4.5.0.0.alpha0+
Build ID: 784d069cc1d9f1d6e6a4e543a278376ab483d1eb
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-25_23:07:36
Comment 4 Robert Großkopf 2015-04-30 19:30:57 UTC 
Also reproduced with
Version: 5.0.0.0.alpha1+
Build ID: fc0d494b8936ab11abca761810de8a03f579edf5
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-20_05:29:00
(OpenSUSE 13.2)

Grid of Writer is used also for forms. So its the same problem while designing forms in Base. Isn't possible to set a form-control on the grid-points. Width and hight of the control will follow the grid. So the grid seems to work, but the basis of the used grid isn't the same as the basis of the shown grid.
Comment 5 QA Administrators 2016-09-20 09:37:44 UTC Comment hidden (obsolete)
Comment 6 Timur 2018-02-27 15:26:07 UTC 
Please explain how exactly this can be reproduced.
Comment 7 Buovjaga 2018-02-27 17:40:04 UTC 
Timur:

(In reply to Edu from comment #0)
> Steps to reproduce:
> 1. Go to: Tools -> Options -> Writer -> Grid, and set the parameters that
> the attached picture shows
> 2. Draw a line between two point of the grid

So, just tick all the boxes in the options before drawing a line. "Visible grid" makes it so you see tiny pixels representing the grid.

Now, Insert - Shape - Line or from View - Toolbars - Drawing. Deselect the line after drawing it to better see, how the ends of the line are not touching a grid point.

As I was reproducing it again, I noticed it works OK, if you are zoomed in. So something like 300% zoom gives a good result. It does get quite hard to see the grid pixels when going deeper, though (but that is bug 104628).

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: 0b49701fa5c22abba6b9b4a60ddd2720973dd858
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on February 27th 2018
Comment 8 QA Administrators 2019-06-03 02:49:56 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2021-06-03 03:55:19 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2023-06-04 03:16:00 UTC 
Dear Edu,

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://web.libera.chat/?settings=#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug