Aligning stroked and strokeless items & bounding box issues

[yareckon]

Platform: (debian) Inkscape 0.47pre2 r22153, built Oct 30 2009

I have been trying to align objects with various strokes and dimensions, and I am frustrated by some inconsistencies. Please look at my screenshot first as I walk you through this.

I am trying to visually align figures like in the screenshot, some with strokes, some without etc... The square path is a drawn rectangle with a thick stroke, converted to a path, and one line segment is removed on the left side. The circle is a strokeless circle with solid fill.

Goal:
I want the first pixel (left most or right most) of the first object (whether it is a stroke or a fill in vector land) to line up with the first pixel of the second object (stroke or fill).

The inkscape documentation states that align lines up the outer edges of bounding boxes:
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Align.html#Align-Align

When I have visual bounding boxes, this is the case, the bounding box for the circle brackets the circle perfectly, but the bounding box for my squarish path sits one half stroke width off to the left of the line segment that is no longer there.

The align tools in visual bounding box mode left align the circle to the squarish path's false left bounding box.

So, I tried to change to geometric bounding boxes, which indeed placed the bounding box for the squarish path in the middle of the stroke on the stroked path, and directly against the fill on the open side of the path. Again, I tried to align the circle and squarish path on it's open side. Same result, and now there is not even the excuse that the wrong bounding box was the cause.

I tried vertically aligning the squarish path and circle to each other while still in geometric bounding box mode. The align tool disregarded the bounding box mode and worked exactly like it would have in visual bounding box mode.

Removing the stroke from the squarish path made the open side and the segmented sides work alike in terms of bounding box and alignment. I seem to recall that stroke end caps styles have no effect on this problem.

So we have two problems:

1) Inkscape's align tool always aligns to visual bounding box, regardless of bounding box mode set. We should change documentation of the tool to reflect this, or change align's behavior to respect the geometric bounding box when in that mode. Could be useful for aligning interior points or something.

2) Visual bounding box is always offset 1/2 stroke width from a path even if that path has an open outermost edge with no path segment present. This is likely a bug in the bounding box model, and I would recommend changing this visual box model to actually match the visual outlines of the path it brackets.

[yareckon (yareckon)]

The screenshot is from geometric bounding box mode.

[su_v (suv-lp)]

1) bbox setting ignored for aligning objects
IIRC this is a known issue (same goes for gradient handles)... but I could not find an earlier report about it yet.

2) visual bbox wrong for butt cap lines - related bug reports:
Bug #165935 “length/bounding box of open butt cap lines too large”
Bug #165972 “Bounding box too large”
Bug #166659 “Bounding box does not include long miters”

(BTW: setting 'Round join' and 'Round cap' as stroke style *does* have an influence and produces correct alignment to the visual bbox - the geometric bbox is still ignored of course)

[yareckon (yareckon)]

Sounds like a good explanation. The round caps, do work, but still cause issues for my use case.

Mostly this bug prevents me from creating slices of graphics for later reassembly (say building left and right sides of a tab for css sliding door technique) because I can't align the fill or strokes properly without getting a little transparent strip half the width of the stroke in aligned sections and later in the export. I can make a custom export box in the export bitmap dialogue to work around this, but who wants to do this all the time if export selection was working?

I normally open in Gimp afterwards to trim the transparency off. Arguably I should be slicing the graphics up in gimp in the first place, but I'd love to be able to do direct to web with one tool.

I think that I would rather use visual bounding boxes for both align and export, so for me the big bug is the bounding box spacing that half extra stroke on the end of paths with but caps.

Thanks for your help! Anything else I can do on this?

[yareckon (yareckon)]

Reading the comments in the below thread seems to indicate that there is a shortcut being done for performance reasons when the program calculates the bounding box of a path. If I understand things properly, the performance shortcut (add half a stroke width?) for calculating this box is resulting in extruding points being lopped off and flat sides like mine being padded improperly.

https://bugs.launchpad.net/inkscape/+bug/166659

I've brainstormed some strategies below ( if performance is the problem blocking switching to hi fidelity bounding boxes):

Solution 1-- Cache the box dimensions

Perhaps there could be a bounding box dimension saved as a temporary value in the object / path somewhere so that the value doesn't have to be regenerated everytime someone selects the object or nudges it over with the cursor? I know cached values are a recipe for trouble if other code paths don't recognize or clear them, but I would really appreciate a correctly (=expensively) calculated bounding box for a path to be available for align and bitmap export. It's costing human time rather than CPU time at the moment.

Solution 2 -- have 2 Modes

Have a drag around mode and a high fidelity mode for bounding box setting. One could be used for align and export where bounding box quality matters, and other functions could take the shortcut. Or a table of dangerous cases could be made, and if such a shape is present in the document, high fidelity mode could be switched on for the document or object at a performance hit. Personally I see this as a fountain of new bugs, but weirder architectures have happened (see browser rendering modes)

Solution 3 -- find a better hack

Maybe there is a better performance shortcut that we can build in that avoids more problems than the current shortcut, but isn't as calculation intensive as the real calculation?

Solution 4 -- Just change to hi-fidelity mode and cite Moore's Law

How much more expensive for a hi-fi bounding box are we talking here? If calculating the proper box takes 1000% more time in hi fidelity mode, but this is only called every few seconds, we may be talking about a 1% slowdown or even less. Then again, it may be too big of a hit to ignore. Developers need to decide based on actual numbers. I use inkscape on a 1.25Ghz powerpc and a Core2 Duo 3Ghz system and the difference is huge today. I would however give 1% performance on either box for this feature. Some would not, and I may be a small minority.

Solution 5 -- I keep Gimp in my workflow for now :)

[su_v (suv-lp)]

other possible workarounds:

- Don't use the the 'Align and Distribute…' dialog, align the objects by snapping to guides or grid instead:
- Adjust / fine-tune the snapping options on the Snap Controls Bar
- Switch between visual and geometrix bbox if needed
With geometric bbox you could turn off node snapping and only use bbox snapping. This works for your illustrated example, but would need different settings if the circle object has a stroke as well. Then you might be better of with visual bbox and both types of snapping enabled (bbox and nodes): snap open stroked rectangles with the nodes to the guides/grid, snap closed stroked shapes with the bbox to the guides/grid.

- use a different web slicing method: the recently updated 'Inkscape-Slicer-Extension' (info: <https://bugs.launchpad.net/inkscape/+bug/169985>, download: <http://github.com/mattharrison/Inkscape-Slicer-Extension>) gives you better visual control about the slices and allows overlapping slices as well as omitting possible gaps (at least theoretically - I didn't try it myself since I don't have a more complex or real-world example at hand).

> Anything else I can do on this?
Hire someone who can contribute a patch? ;-)
1) bbox setting ignored for aligning objects:
Making the 'Align and Distribute…' dialog respect the bbox settings might be easier to fix (*maybe* - I'm not a developer myself) than the second bug:
2) visual bbox wrong for butt cap lines:
I think the developers who work on snapping and related modules are well aware of the deficiencies, but some issues are hard to fix (as explained in the above linked reports) or require some broader code refactoring to be finished first (like replacing currently used functions with newer ones from lib2geom). A quote from an (unrelated) bug triggered by bbox issues: «The bigger picture IMHO is that we still need to replace all occurrences of NRRect by Geom::Rect, in each SPItemClass.» <https://bugs.launchpad.net/inkscape/+bug/318726/comments/4>

[su_v (suv-lp)]

my last comment was written unaware of comment #5 - will read it & possibly comment later...

[yareckon (yareckon)]

thanks, I really appreciate both the workarounds and the technical discussion.

[Alvin Penner (apenner)]

fix committed to rev 10966