![](https://secure.gravatar.com/avatar/07227c9eef9320ee712520d819ec5c36.jpg?s=120&d=mm&r=g)
Hi,
I've just put a couple of grid-related patches in the tracker; I mention them here in case anyone wants to disagree ;-)
1. Anchor points are snapped to the grid; otherwise when you're drawing a line with the pen tool you get every point except the first snapped to the grid, which seems a little odd.
2. Resolve the issue whereby changing grid snap units from pixels to mm is not noticed. Fuller explanation is in the comments I added and in the patch tracker.
My other grid-related problem is that pasting a snapped object results in the pasted version not being snapped to the grid. I plan to fix this so that pasted objects are placed such that their points have the same offset from the nearest grid points as the original. Any objections?
Cheers
Carl
![](https://secure.gravatar.com/avatar/cb05f8930948859ba6f5eafcdc14e722.jpg?s=120&d=mm&r=g)
On Tue, Apr 13, 2004 at 06:08:35PM +0100, Carl Hetherington wrote:
- Anchor points are snapped to the grid; otherwise when you're drawing a
line with the pen tool you get every point except the first snapped to the grid, which seems a little odd.
This patch doesn't appear to help this problem. I tried it with and without, and the line-drawing tool does the same thing no matter what. Strangely, the freehand tool doesn't have this problem, with or without the patch.
![](https://secure.gravatar.com/avatar/cb05f8930948859ba6f5eafcdc14e722.jpg?s=120&d=mm&r=g)
On Tue, Apr 13, 2004 at 06:08:35PM +0100, Carl Hetherington wrote:
- Anchor points are snapped to the grid; otherwise when you're drawing a
line with the pen tool you get every point except the first snapped to the grid, which seems a little odd.
Okay, after some dumbness on my part, I figured out this patch. I changed it very slightly to conform to the calling conventions of the function the change was in, but the bug is still fixed: the bezier line tool wasn't snapping it's initial point to the grid. Excellent find!
- Resolve the issue whereby changing grid snap units from pixels to mm
is not noticed. Fuller explanation is in the comments I added and in the patch tracker.
This turned out to be two bugs, and I initially only fixed the one I uncovered, rather than the one the patch fixed. ;) Since I'm so unfamiliar with grids and snapping, Carl had to clarify this problem for me before I understood what was going on. But, as a result, now two bugs are fixed.
Thanks for putting up with me Carl! :)
One strange behavior still exists, and this just might be "by design". In "Dialogs / Document Preferences / Grid" if I switch "Snap units" from "px" to anything else (or back), the "Snap distance" stays the same. If I change "Snap units" from anything not "px" to anything else not "px", unit conversion is performed. Is this just a "feature" of the pixel unit?
![](https://secure.gravatar.com/avatar/07227c9eef9320ee712520d819ec5c36.jpg?s=120&d=mm&r=g)
[snip]
Thanks for putting up with me Carl! :)
No problem, thank you for sorting the patches out :-)
One strange behavior still exists, and this just might be "by design". In "Dialogs / Document Preferences / Grid" if I switch "Snap units" from "px" to anything else (or back), the "Snap distance" stays the same. If I change "Snap units" from anything not "px" to anything else not "px", unit conversion is performed. Is this just a "feature" of the pixel unit?
I noticed this and had a look into it, but I didn't make much sense of anything.
The first odd thing is that spus_unit_activate() (called when a different unit is chosen) only attempts to update its adjustment values if the "base" of the new unit is different from that of the old. The "base" is the type of unit e.g. dimensionless (%ages), absolute (mm, cm) etc. (see the top of helper/units.h).
I'm not sure why it doesn't try a conversion.
The other strange thing is that sp_unit_selector_init sets up ctmscale and devicescale to both be 1. I think this means that any conversion between device and absolute units will be wrong anyway. It looks to me like sp_unit_selector_init needs to get its scale factors right, perhaps getting the correct values from the OS, or whatever.
The first odd thing may be a consequence of the second, who knows.
Cheers
Carl
participants (2)
-
Carl Hetherington
-
Kees Cook