Wrong bounding box calculated for objectBoundingBox units

[Jaspervdg]

The SVG 1.1 specification defines an object's bounding box (for use with
objectBoundingBox units) as:

"The bounding box is computed *exclusive* of any values for clipping,
masking, filter effects, opacity and *stroke-width*."

See:
http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBox

Inkscape DOES take stroke into account however, and this can give the wrong
results when a gradient uses objectBoundingBox units for example (see the
attachment).

I verified that Batik (and Firefox) indeed behave like I suggest (they
don't take stroke into account when calculating the bouding box).

The attached SVG file shows the problem. It contains four rectangles with a
linear gradient, the upper two use objectBoundingBox units, the lower two
userSpaceOnUse units. With Batik (and Firefox) all gradients match exactly,
in Inkscape the topmost gradient is stretched.

BTW, in some cases it is useful to incorporate stroke in the bounding box
(see thread "bbox calculation" on the developers mailinglist and bug
#166659 (sf1230603)).

[Bryce Harrington (bryce)]

Originator: NO

Thanks for the bug report. Mental, can you provide your thoughts on
this?

[Mental-users (mental-users)]

Originator: NO

There are several different sorts of bounding boxes we're interested in,
among them:

 - geometric bounding box (e.g. as used by SVG)
 - visual bounding box (including stroke, filter region, and so forth)

The bounding box API needs to reflect this.

[Bug Importer (bug-importer)]

I think this is kinda-sorta related to feature request 1595501: "Bounding
box not depending on the stroke width".

[jazzynico (jazzynico)]

Marking this report as duplicate of Bug #171599 "Bounding box not depending on the stroke width" (fix released in 0.46).

[su_v (suv-lp)]

> With Batik (and Firefox) all gradients match exactly,
> in Inkscape the topmost gradient is stretched.

The gradient in the example file is not correctly rendered in the current stable release Inkscape 0.48.2 (apparently this report is not precisely a duplicate of Bug #171599).

Inkscape 0.48+devel r10747 does render all gradients correctly aligned, but the gradient tool still displays the gradient stops positioned at the corners of the visual bounding box of the stroked rectangle:

      <linearGradient id="MyGradient">
        <stop offset="0" stop-color="#F60" />
        <stop offset="1" stop-color="#FF6" />
      </linearGradient>

(…)

    <rect fill="url(#MyGradient)" stroke="black" stroke-width="200"
          x="150" y="150" width="600" height="300"/>

In my understanding of the reported issue, the stops of this gradient should be positioned to match the geometric bbox not the visual bbox (in accordance to how the gradient is rendered):

«If attribute ‘gradientUnits’ is not specified, then the effect is as if a value of 'objectBoundingBox' were specified.»
<http://www.w3.org/TR/SVG11/pservers.html#LinearGradientElementGradientUnitsAttribute>

-> proposing to unlink as duplicate from Bug #171599 since the issue is not fully addressed yet (even with the new renderer).

[Jaspervdg (jaspervdg)]

I agree, this is about an SVG conformance issue rather than a UI issue, so if it still renders incorrectly it should be unlinked and reopened.

[su_v (suv-lp)]

> so if it still renders incorrectly it should be unlinked and reopened.

Current trunk does render the gradient itself correctly (unlike 0.48.2), but the gradient handles for editing are still wrong (relative to the visual bounding box, and thus detached from the actual gradient).

Attaching a screenshot comparing Inskcape 0.48.2 to Inkscape 0.48+devel r10747 [1] with a slightly modified version of the test case. Note the gradient stops at the top of the upper rectangle (with a wide semi-transparent stroke).

@Jasper - should this be tracked in a follow-up report, and your report closed as 'Fix Committed' with milestone 0.49? Or keep this one open until the gradient handles match what is actually rendered?

[1] tested with cairo 1.10.2 and 1.11.2, on Mac OS X 10.5.8 (i386)

[su_v (suv-lp)]

Modified test case rendered in Squiggle (Batik 1.7)

[Jaspervdg (jaspervdg)]

If you want to be strict, then yes, the handles are probably a different issue, as apparently the rendering of the gradient was fixed. And the shown handles not corresponding to the actual positions seems like a pretty bad issue to me.

[su_v (suv-lp)]

WRT to "objectBoundingBox" for gradientUnits and gradient handles: see also
Bug #1031785 radial gradient control handles are wrongly placed

[su_v (suv-lp)]

Gradients are rendered correctly in trunk -> changing status to 'Fix Committed', setting milestone to 0.49.

Gradient editing (initial position and incorrect conversion from "objectBoundingBox" to "userSpaceOnUse" units) still needs to be addressed (tracked separately).