Make a Bitmap Copy does not account for stroke width changes

[matrix29bear]

When changing the stroke width of a filled object, the new stroke width is not recognized when using the "Make a Bitmap Copy" command.

How it normally works.
Easy way to verify. Make a square. Use the TRANSFORM command to skew the square left or right (10 is a good quick choice). Now select, "Make a Bitmap Copy". The bitmap copy will be exact as expected.

Now to verify bug.

Take original pathed square select "Fill & Stroke" then "Stroke Style". Select the dropdown menu next to "Width", change to "pc" and then change the "Width" to "5.0". You will note the bounding box now does not encompass entirely the top corner and the opposite angle bottom corner because the new stroke width is not being calculated correctly and compensated for.

Now select, "Make a Bitmap Copy".
You will be missing the pointy spot of the top (left or right depending on how you skewed the box) corner and the point on the lower opposite side corner.

[matrix29bear (matrix29)]

Not a huge bug, but I figure you folks would want a non-crash bug (buggy filters anyone?) that should be fairly easy to tackle and stick in a chokehold.

[su_v (suv-lp)]

Reproduced with Inkscape 0.48.1 and 0.48+devel r10313 on Mac OS X 10.5.8 (i386)

The issue not related to skewing (preserved transform, stroke scaling bug #) or stroke width: like in bug #166659 for bitmap export, long miters are not considered when making a bitmap copy.

'Edit > Bitmap copy' should probably use 'RENDERING_BBOX' too (slower, but includes all stroke widths):
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/selection-chemistry.cpp#L2668>

Linking as duplicate to Bug #168385 “Make a Bitmap Copy cuts off parts of object.” (duplicate status of bug #166659 reverted). Please add a comment here and revert the duplicate status if you don't agree and think these are different issues.