trunk: visual bbox size affected by document units (too large with 'm' and 'ft') (rev >= 12554)

Bug #1244861 reported by su_v on 2013-10-26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Johan Engelen

Bug Description

Changing the default units for the current document may affect the size of the visual bounding box (the visual selection cue is noticeably enlarged after switching default units from 'px' to 'm' or 'ft', with an empty margin around the actual stroked object)

Steps to reproduce:
1) launch current trunk with default (new) preferences, new document based on the default (not localized) template
2) draw a rectangle (e.g. as wide as the page, height about one third of the page height)
3) keep rectangle selected (with default prefs it has a blue fill, and a black stroke, 1px wide)
4) open document properties and change default units from 'px' to 'm' (or 'ft')

Expected result:
The size of the visual bbox selection cue relative to the outer edges of the selected stroked object does not change.

Actual result:
After changing the document units, the selection cue is enlarged. This enlarged visual bbox persists after saving, and reloading the document. New stroked objects drawn in the document after the unit change also show an unexpectedly larger visual bbox.

Confirmed with r12723 on Ubuntu 13.04 (VM) (inkscape-trunk PPA) and with r12726 on OS X 10.7.5.

Based on tests with archived builds (on OS X):
- not reproduced with rev <= 12552,
- reproduced with rev >= 12554,
this regression was introduced with the merge of the GSoC unit-improvement branch in revision 12554:

su_v (suv-lp) on 2013-10-26
description: updated
Johan Engelen (johanengelen) wrote :

is this bug still there suv? (after r12749?)

su_v (suv-lp) wrote :

@Johan - yes (verified with r12761).

jazzynico (jazzynico) wrote :

Confirmed on Windows XP, inkscape trunk revision 12840.

Changed in inkscape:
status: New → Triaged
importance: Undecided → Medium
su_v (suv-lp) wrote :

Still present with r13026.

Variation of 'Steps to reproduce':
1) launch trunk (default new prefs, default new doc based on EN locale)
2) apply 'Extensions > Render > Gear > Gear…' (default settings)
3) select the created group
3) change document units to 'm'

-> size of the selection cue of the visual bbox changes unexpectedly (increase).

Johan Engelen (johanengelen) wrote :

Note that there are other bugs because of limited precision when doing
1) launch trunk (default new prefs, default new doc based on EN locale)
2) apply 'Extensions > Render > Gear > Gear…' (default settings)
3) select the created group
4) change document units to 'm'
First, (in my case), the inner circle of the gear is rendered quantized to a diamond shape. Moreover, when node editing the gear path, after some wiggling there is a continuity error in 2geom and inkscape crashes. I think both are because of limited (possibly 'allowed') precision.

Johan Engelen (johanengelen) wrote :

Fixed in rev. 13286. (at least for the test case. this will still happen for even smaller numbers for the stroke width......)

Changed in inkscape:
assignee: nobody → Johan Engelen (johanengelen)
status: Triaged → Fix Released
Alvin Penner (apenner) wrote :

as far as I can tell, this fixes the bbox problem, thanks Johan!

there is a remaining problem, namely: quote<First, (in my case), the inner circle of the gear is rendered quantized to a diamond shape.>
This can be fixed in the file 2geom\ellipse.cpp, routine Ellipse::transformed, line 236.
replace the line:
    if ( are_near(AM.det(), 0) )
with the line:
    if ( are_near(std::sqrt(AM.det()), 0) )

This line bypasses normal processing if the object is too small. This is using the determinant to measure the size of the object but the measurement is quadratic in the size scale, when it should be linear. Taking the square root avoids the problem. Unfortunately, this is in 2geom, so I am reluctant to commit this change, thought I would ask for comment here.

Johan Engelen (johanengelen) wrote :

Alvin, can you have a look again at 2geom? I think your fix is no longer needed (the code seems to compare the sqrt of determinant now). Note that the determinant can be negative, so sqrt(fabs(det)) is needed; this is what the descrim() method does.

Alvin Penner (apenner) wrote :

it appears that the bug report comment 7 that I made was wrong, the actual code in 2geom is:

    if ( are_near(std::sqrt(fabs(AM.det())), 0) )

it looks as if this has already been applied to trunk, although I don't know when this happened.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers