Filter effect on many strokes renders incorrectly

[Scott Pakin]

I applied a custom filter to a large number of strokes (430). The filter is supposed to draw its subject black with a blue outline, but Inkscape 0.48 ignores the effect and Inkscape trunk draws it as black with no outline. This is on Ubuntu 14.10 (Utopic Unicorn) for x86_64.

As a few points of comparison, GNU Emacs 24, Opera 28, and Chromium 41 display the SVG file correctly. Mozilla Firefox 37 does not (black with no outline, like Inkscape trunk).

The problem seems to be related to filters applied to strokes. Converting the strokes to paths in the attached SVG file corrects the rendering.

[su_v (suv-lp)]

Batik 1.7 (Squiggle), Firefox 37 and Inkscape 0.91/trunk all agree how to implement the current SVG 1.1 specification for SVG filter effects, and render the drawing correctly (AFAIU).

The filter effects region (FER) as defined in the current SVG 1.1 spec is relative to the geometric bounding box of the object (default: 120%) [1]: filtering horizontal or vertical lines (stroked or not) will result in a filter effect without visible output region (the width or height of the FER is zero), and thus causes the filtered lines to disappear entirely.

To work around this limitation in the current SVG 1.1 specification, do not attempt to filter one-dimensional objects (straight horizontal or vertical lines); instead for example put the lines into a container (e.g. a group), and apply the filter effect to the group - this works as expected in Inkscape 0.91 and 0.91+devel.

The issue is long-standing (not a regression in 0.91), and roots in the SVG 1.1 specification. The details of the implementation in Inkscape varied over time - the old renderer in Inkscape <= 0.48 was using the visual bounding box instead of the geometric one for the FER, which was fixed (to conform with the current spec) in the new renderer for 0.91.

Proposing to link as duplicate to
* Bug #168943 “Blurring a zero-height or zero-width path”
  https://bugs.launchpad.net/inkscape/+bug/168943

A related discussion can also be found in the comments of
* Bug #1229971 “trunk: incorrect objectBoundingBox for FER (rev >=...”
  https://bugs.launchpad.net/inkscape/+bug/1229971

--
[1] The SVG 1.1 specification defines for the objectBoundingBox used for filter effects regions:
http://www.w3.org/TR/SVG11/filters.html#FilterEffectsRegion
«(…) 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
The 'filterUnits' default to 'objectBoundingBox' unless specified as 'userSpaceOnUse' explicitly. Inkscape's filter effects use 'objectBoundingBox' (FER expressed in fractions or percentages of the bounding box on the referencing element).

[Scott Pakin (pakin)]

> « 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

Wow, that's really unintuitive. I never would have thought that a horizontal line with a stroke-width of 4 would result in a bounding box with height 0.

> Proposing to link as duplicate to
> * Bug #168943 “Blurring a zero-height or zero-width path”
> https://bugs.launchpad.net/inkscape/+bug/168943

Hmm...I don't see these as duplicates, even though both are due to the same issue of applying filters to 1-D objects. Bug 168943 focuses more on Inkscape crashing while bug 1444262 focuses more on incorrect (or, as I now know, highly unexpected) rendering. Maybe just mark my bug report "works as intended" or somesuch?

[su_v (suv-lp)]

Bug #168943 is where this (known) issue is tracked for Inkscape. But since you disagree:

On 2015-04-16 07:26 (+0200), Scott Pakin wrote:
> Maybe just mark my bug report "works as intended" or somesuch?

Closing as 'Invalid' (aka "not a bug") based on the reporter's request (launchpad's bug tracker does not offer a bug status "works as intended").