When I Set Step rotation preferences to 22.5 degrees it increments by 22 degrees or something.

Bug #525508 reported by David L K on 2010-02-21
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Damjan Velickovski

Bug Description

Version 0.47 Inkscape

When I Set Step rotation preferences to 22.5 degrees it increments by 22 degrees or something.

Steps to create bug

Create a straight line.
Set Step rotation preferences to 22.5 degrees
Duplicate object
Press [ 16 times until you think it should have gone 360 degrees since 22.5 x 16 = 360
It is short by several degrees.

Others step increments work fine. (18 degrees for example)

Thank you for your time.

David

Display adapters
Mobile Intel(R) 915GM/GMS,910GML Express Chipset Family

OS Name Microsoft Windows XP Home Edition
Version 5.1.2600 Service Pack 3 Build 2600
OS Manufacturer Microsoft Corporation
System Manufacturer TOSHIBA
System Model Satellite M40X
System Type X86-based PC
Processor x86 Family 6 Model 13 Stepping 8 GenuineIntel ~1496 Mhz (Celeron)
BIOS Version/Date TOSHIBA V1.60, 09/06/2005
SMBIOS Version 2.34
Windows Directory C:\WINDOWS
System Directory C:\WINDOWS\system32
Locale Canada
Hardware Abstraction Layer Version = "5.1.2600.5512 (xpsp.080413-2111)"
Time Zone Eastern Standard Time
Total Physical Memory 512.00 MB
Available Physical Memory 101.33 MB
Total Virtual Memory 2.00 GB
Available Virtual Memory 1.96 GB
Page File Space 1.44 GB
Page File C:\pagefile.sys

Related branches

Alvin Penner (apenner) wrote :

yes, it is incrementing by precisely 22 degrees, not 22.5.
If you set the increment at 22.5 and hit [ 45 times then you will get a perfectly vertical line corresponding to 990 degrees which is a multiple of 22.

similarly, it looks as if 7.5 will show the same or similar behaviour.

Changed in inkscape:
status: New → Confirmed
~suv (suv-lp) wrote :

Only affects rotating by keyboard shortcuts ('[', ']') but not when 'Ctrl+dragging' the rotation handles with the mouse, which uses the same preference setting: «Constrain a rotation or skew to a multiple of the Rotation snap angle.»
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Transforms.html#Transforms-Mouse-SRS-RotatingSkewing>

(tested with 0.48+devel r9931 on OS X 10.5.8)

tags: added: preferences transformations
Changed in inkscape:
importance: Undecided → Medium
~suv (suv-lp) wrote :

Reproduced with 0.46, 0.47, 0.48.x and current trunk r12188 - only affects the transformation via hard-coded keyboard shortcut.

Seems like a candidate for an 'easy-fix' to me (somewhere the decimal part of the "180/snaps" result gets lost or truncated to an integer value?) - @Johan, would you agree?

Related code:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/12185/src/select-context.cpp#L888>
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/12185/src/select-context.cpp#L983>
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/12185/src/selection-chemistry.cpp#L1619>
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/12185/src/2geom/transforms.h#L212>

tags: added: easy-fix
Damjan Velickovski (dummyan) wrote :

This is my first patch ever so please criticize me as much as you can (I'm serious on this). I was in doubt whether to make smallest change possible or to reorginize some of the code. I went with the first option. I hope with time I will find a balance between the amount of changes and general impact of the code.

Alvin Penner (apenner) wrote :

thanks for the contribution!

I have tested your patch and it appears to work correctly, as expected. However, after looking at the data stored in the preferences.xml file, it appears that this variable is always stored as an integer, and so it would be reasonable to retrieve it that way as well. As far as the floating point behaviour of the calculated result is concerned, that can sometimes be imposed by using decimal points explicitly in an expression.
    A proposed patch of this type is attached, and appears to get the desired result. Would you have any objections if this alternative patch were used?

jazzynico (jazzynico) on 2013-04-05
Changed in inkscape:
status: Confirmed → In Progress
Alvin Penner (apenner) wrote :

@Damjan - do you have any objections if we commit the alternative patch from comment 5, or do you have a specific reason for preferring the original patch from comment 4?
    - in either case you will be given credit for the fix, since you took the initiative to fix it and since your original proposal worked.

Damjan Velickovski (dummyan) wrote :

I have no objections, I had some difficulties in navigating the code so I somehow missed to check how the data is actually stored. It is actually good to see a better approach because with that I learned a better approach.

Alvin Penner (apenner) wrote :

good to hear,
committed to bzr rev 12274.

Changed in inkscape:
status: In Progress → Fix Committed
~suv (suv-lp) on 2013-04-09
Changed in inkscape:
assignee: nobody → Damjan Velickovski (dummyan)
milestone: none → 0.49
~suv (suv-lp) wrote :

The changes from r12274 merge cleanly into <lp:inkscape/0.48.x>, and fix the reported problem as expected.
The attached patch was tested successfully with 0.48.x r9963 on OS X 10.7.5.

Proposing to include the fix in 0.48.5.

tags: added: backport-proposed
~suv (suv-lp) wrote :

Fix backported to lp:inkscape/0.48.x in revision 9994.

Changed in inkscape:
milestone: 0.49 → 0.48.5
tags: removed: backport-proposed
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers