trunk: incorrect objectBoundingBox for FER (rev >= 12362)

[su_v]

Follow-up report to
- Bug #1188336 “blur of 1% is clipped too much”
  <https://bugs.launchpad.net/inkscape/+bug/1188336>

The SVG 1.1 specification defines for the objectBoundingBox used for filter effects regions:
«(…) The bounding box is computed exclusive of any values for clipping, masking, filter effects, opacity and stroke-width. (…)»
<http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBox>

Current trunk however uses the visual bounding box (i.e. including the stroke-width) to calculate the effective filter effect region. This can result in very different output regions of filter effects, depending on the style properties of the filtered objects.

Compare attached files:
- sample SVG file
- reference rendering Batik 1.7 (Squiggle)
- screenshot Chromium 31.0.1640.0 (224635)
- bitmap export rev 12359
- bitmap export rev 12362
- bitmap export rev 12586

The output of r12359 matches the rendering of Batik and Chromium, the later ones (r12362, r12586) render a differently sized filter effect region.

Note: the sample file uses circles with different geometric sizes, but identical visual bounding boxes due to varying stroke widths.

Related commit:
Revision 12362: use visual bbox in calculation of filter area (Bug 1188336)
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12362>

[jazzynico (jazzynico)]

Confirmed on Windows XP, Inkscape trunk revision 12583.

[Alvin Penner (apenner)]

working on it, may take a while...

[Alvin Penner (apenner)]

fix committed to rev 12621.

This breaks the previously reported fixes for Bug 1188336 and Bug 168943. However, one could argue that perhaps these previous reports were not actually valid bugs, in view of the svg spec. In any event, I believe the result should now be compatible with comment 1 above. The new rendering is also compatible with Adobe SVG Viewer 3.0 running in IE8, Windows XP.

[bbyak (buliabyak)]

This may be the correct behavior per the spec, but this means a strictly horizontal or vertical line now becomes invisible as soon as you apply any filter to it, which is extremely painful for the user. Moreover, and this I think this may be a new bug, it remains invisible even if I rotate it. Only curving it makes it visible. Is that correct?

[Alvin Penner (apenner)]

that is correct. If you draw a horizontal line and apply a blur, it will stay narrow regardless of the stroke, and will also stay narrow even if you rotate the line. Similarly if you draw a line at 45 degrees and give it a wide stroke and apply a blur, the blur will remain wide even if you then rotate the line to be exactly horizontal. I think that what is happening is that the filter properties , height, width are defined once, on the initial draw, they are then transferred into the defs section and never again modified even if you rotate the line.
      As far as I can see, this bug report and Bug 168943 are fundamentally incompatible with each other. They cannot both be resolved at the same time. The problem goes back to the manner in which the filter area is defined. The filter dimensions (x,y) are defined as a dimensionless number which must be multiplied by the bbox. This means that if you use a geometric bbox you will satisfy this bug report and break Bug 168943. And if you use a visual bbox then the opposite happens.
     As far as I am concerned this is a deficiency in the svg spec. The svg spec should allow for the possibility of both an offset and a scale factor so that the filter width would be a + bx where x is the width of the bbox and a and b are both adjustable. b already exists, but the new a could play the role of the stroke width if desired.
   I think the problem is that a lot of filters are meant to be applied as rectangular backgrounds which work on the fill, not the stroke. But blur is most interesting when it works on the stroke not the fill. In any event, I think the svg group should consider thinking about this problem because the current situation is quite dissatisfying.

[Alvin Penner (apenner)]

- sorry, I should have specified what I meant by rotate. Rotate means using the Select tool, not the Node tool
- also, good to see you back, bulia!

[su_v (suv-lp)]

Discussion about whether or not to follow the SVG 1.1 spec in this case probably ought to be moved to the mailing list. I'm closing this one as 'Fix Released' for now, since it never affected a stable release.

Note: apparently there had been other changes recently which affect the filter effects region/bounding box and which haven't been fully reverted yet, see the PS in this mail:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/41660/focus=41684>
which refers to changes as discussed in this thread:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/41362>

[Alvin Penner (apenner)]

>> Discussion about whether or not to follow the SVG 1.1 spec in this case probably ought to be moved to the mailing list.

sounds good to me, this is well above my pay grade...