Blurring a zero-height or zero-width path

[Bug Importer]

Filter effects applied to a horizontal or vertical line don't produce visible output.

=====
Original description:

On ubuntu, the latest autopackage version (inkscape200709061136 - haven't
tested other packages or versions, or operating systems) crashes when a
straight path with all the nodes aligned vertically or horizontally is
blurred. The crash will not occur if the path has a curve, or all the nodes
are not aligned vertically or horizontally. The crash occurs whether the
line is drawn with the nodes aligned and then blurred, or if a line with
nodes not aligned vertically or horizontally is blurred, and then the nodes
aligned.

To cause this crash:
1. Using the bezier tool, draw a straight line constrained vertically or
horizontally
2. Blur the line (I did this with the fill and stroke dialog. Maybe
manually blurring would not cause the crash?)

gdb output:

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: Is nothing

aborting...

Program received signal SIGABRT, Aborted.
[Switching to Thread -1225590560 (LWP 19970)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7059df0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb705b641 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb739270a in g_logv () from /usr/lib/libglib-2.0.so.0
#4 0xb7392749 in g_log () from /usr/lib/libglib-2.0.so.0
#5 0x0852ffb3 in Glib::exception_handlers_invoke ()
#6 0x08534e93 in Glib::SignalProxyNormal::slot0_void_callback ()
#7 0xb759e9d9 in g_cclosure_marshal_VOID__VOID ()
   from /usr/lib/libgobject-2.0.so.0
#8 0xb759162b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#9 0xb75a23f1 in ?? () from /usr/lib/libgobject-2.0.so.0
#10 0x0ada1190 in ?? ()
#11 0x00000000 in ?? ()

[Buliabyak-users (buliabyak-users)]

Originator: NO

for me it does not crash, but does not blur either

[Niko Kiirala (kiirala)]

Originator: NO

Even showing an non-blurred line is likely wrong in this case. The filter
effects area is not supposed take into account any stroke the object may
have, so the bounding box of a horizontal line will have height of zero.

Since the filter effects area is usually calculated as percentage of the
object bounding box, the filter effects area will be also zero-height and
thus the filter result shouldn't be visible at all.

[Buliabyak-users (buliabyak-users)]

Originator: NO

niko: not showing filter result or not showing anything at all? is the
showing of unblurred line correct then? what does batik do?

[Niko Kiirala (kiirala)]

Originator: NO

I'd believe, it shouldn't show anything at all. With Batik, the result
seems to be a thin and faint line. Like if it's first blurred and then cut
to height of one pixel.

An example attached, showing five blurred lines, of which the one in
center is horizontal, others are tilted a bit.
File Added: blur-viivat.svg

[Gerben Venekamp (venekamp)]

I think I understand what you are saying, no path should be blurred or the Gaussian Filter Effect should be applied to. However, this is not what I would expect, hence my bug report #213376, albeit duplicate. Of course one cannot apply any blurring to a one dimensional object, but then again one cannot see such objects in reality. This is why you need an attribute like stoke which has a width and thereby making the one dimensional object really two dimensional and thus visable and hence the blurring should be applied to it.

[Shirokage (x-o-0-x)]

I confirm this bug on windows XP service pack 3 with inkscape 0.46 stable.

I experimented with the xml and found that this only happens if the path is a straight line to begin with. When inkscape first draws a path it sets the points (d attribute of the <path> element), but if you rotate it after that it applies rotation merely by adding a transform attribute. If you draw a horizontal or vertical path to begin with, blurring never shows up even if you rotate it, unless you rotate it manually by editing the xml attribute d. On the other hand, if you draw one that's angled to start with and then make it horizontal or vertical by using the mouse or adding transform="rotate(a,b,c)" as I did, the blur works. So apparently whether it's zero-height or not depends on the points in the d attribute. I'd say this does need to be fixed because unless the path is 0 pixels thick, it shouldn't be considered "zero height". If blur is calculated in this way I think it could cause other problems too.

[Shirokage (x-o-0-x)]

A quick addition I just discovered. I played with creating some simple straight lines by mouse and discovered that only if you rotate the line right after creating it, before changing the color or stroke style or stroke size or anything else, then inkscape actually changes the value of d as you rotate it. This means the program is inconsistent in how it applies rotation, which I think it should not be, so I'm gonna add this as a separate bug if it doesn't already exist.

[Shirokage (x-o-0-x)]

okay i'ma have to correct myself, wish this was like a forum and i could edit my posts. guess i got ahead of myself b/c after some more experimenting i'm finding that the only thing that causes a change in how paths are rotated is whether or not they have a blur. so i'm backing out on the bug report and I asked about it in questions. Maybe there's some reason why it has to do that.

But, I did nominate the zero-height/zero-width path blur pattern for release, cuz I'd say it needs to be fixed in some form or another.

[iliis (samuelbryner)]

I'm not sure, if this the same bug, but it looks somewhat the same:
Inkscape 0.47pre4 r22446 (Oct 14 2009), on Ubuntu 9.10

- enable align to grid
- draw a rectangle
- blur it
- resize it with the object tool to zero height/width/both (NOT with the rect-tool)

gdb:
ERROR:display/nr-filter-units.cpp:44:void Inkscape::Filters::FilterUnits::set_resolution(double, double): assertion failed: (y_res > 0)
Program received signal SIGABRT, Aborted.
0x00ea5422 in __kernel_vsyscall ()

bt:
#0 0x00ea5422 in __kernel_vsyscall ()
#1 0x031fe4d1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x03201932 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x079b7ddc in g_assertion_message () from /lib/libglib-2.0.so.0
#4 0x079b843d in g_assertion_message_expr () from /lib/libglib-2.0.so.0
#5 0x081e61d8 in ?? ()
#6 0x081c42cf in ?? ()
#7 0x08198e0c in ?? ()
#8 0x0819991d in ?? ()
#9 0x08198c2f in ?? ()
#10 0x0819991d in ?? ()
#11 0x08198c2f in ?? ()
#12 0x0819991d in ?? ()
#13 0x08198c2f in ?? ()
#14 0x0856e698 in ?? ()
#15 0x081be572 in ?? ()
#16 0x081be572 in ?? ()
#17 0x081c0914 in ?? ()
#18 0x081c0bd3 in ?? ()
#19 0x081c0fd6 in ?? ()
#20 0x081c105e in ?? ()
#21 0x0798f0f1 in ?? () from /lib/libglib-2.0.so.0
#22 0x07990e78 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#23 0x07994720 in ?? () from /lib/libglib-2.0.so.0
#24 0x07994b8f in g_main_loop_run () from /lib/libglib-2.0.so.0
#25 0x00ba2419 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#26 0x002dd5e7 in Gtk::Main::run_impl() () from /usr/lib/libgtkmm-2.4.so.1
#27 0x002dd3e2 in Gtk::Main::run() () from /usr/lib/libgtkmm-2.4.so.1
#28 0x0808863b in ?? ()
---Type <return> to continue, or q <return> to quit---
#29 0x08164f9a in ?? ()
#30 0x08087ac2 in ?? ()
#31 0x031eab56 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#32 0x08086b71 in ?? ()

is this really the same bug? or should i file a new one?

[su_v (suv-lp)]

not reproduced with Inkscape 0.46+devel r22575 on OS X 10.5.8

@iliis - AFAICS this was reported in bug #449709 “0.47pre3-1.win32 crash when resizing "about Inkscape" dialog" <https://bugs.edge.launchpad.net/inkscape/+bug/449709> and fixed in rev. 22517 (that's after 0.47pre4 was branched).

[Kjohrf (kjohrf)]

Just hit this in 0.47 again.

[Ricardo Graça (devius)]

Hello. I have the same problem. I'm on OpenSUSE 11.2 x64 and tried both Inkscape 0.46 and 0.47 with identical results. On my system it doesn't crash but it simply doesn't blur the path if all its nodes are aligned vertically or horizontally.

How to reproduce:

1. With the bezier tool draw a line with its nodes constrained to horizontal or vertical alignment.
2. Optionally you can just creat a path with two random (non-constraned) points and blur it and it works. However when you move one of the points the whole path loses its blur when passing the horizontal or vertical alignment.

It would be nice if this bug was fixed because it means I can't make a simple horizontal or vertical arrow with a blured drop-shadow out of a simple path.

[Ricardo Graça (devius)]

Oops. It seems I can't delete or edit my post. There's another bug worth reporting :P
Anyway, obviously you have to apply some percentage of blur to the line mentioned in step 1.

[su_v (suv-lp)]

Setting bug status to 'Confirmed' because of the number of duplicates and comments confirming the unexpected behavior.

[Jaspervdg (jaspervdg)]

To clarify:

As the bounding box used to determine the filter effects region must not include strokes the filter effects region for a purely horizontal or vertical line will be empty if filterUnits is objectBoundingBox, this would suggest that NOTHING should be shown. Inkscape shows the unblurred line (interestingly the filter does get handed a pixblock with a zero area...).

On the user experience side of things, having blur use filterUnits=objectBoundingBox leads to unexpected behaviour. (But using userSpaceOnUse could lead to other unexpected behaviour, disappearing objects, when styles get copy/pasted.)

[Kjohrf (kjohrf)]

I just hit this bug yet again in 0.47 on WinXP. Just made a 2 node vertical straight bezier line, and set the blur to 1.0. I can see the bounding box increase in size, but no blur.

[Gerben Venekamp (venekamp)]

This is still the case for version 0.48. Try now to rotate the vertical line and the burring will happen as one would expect until you position the line perfectly horizontal or vertical.

[Jonas T. (jo-t)]

This bug still exists in the latest (K)Ubuntu 11.10 with version 0.48.2 r9819.

[chuinzux (zroutik)]

Dear devs, dear users,

No blurring tkes place for 0-height or 0-width lines in Inkscape 0.48.3.1 r9886.

A workaround:
Create a line of a desired length (=future height/width) in a 45deg direction. In 45deg direction it is easy to create a line with the mesh (shift+3) and the length can be also easily set. Blur it as wished. Turn the object with the Transform tool into the vertical/horisontal position. Job done.
The end points can be further adjusted into the wished distance (click on the point and a) ctrl+drag b) move by arrows on the keyboard).

Cheers,
M

[Alvin Penner (apenner)]

I believe this is fixed in rev 12362

[jazzynico (jazzynico)]

> I believe this is fixed in rev 12362

Confirmed on Windows XP.

With 0.48.4, the bounding box grows but the line stays unchanged.
With revision 12311, the line disappears.
With revision 12362, the blur is applied as expected.

[Alvin Penner (apenner)]

the changes made in rev 12362 have been reversed in rev 12621, due to Bug 1229971.

[Domus (dominique-domussoft)]

Looking forward to the tenth anniversary of this bug. Will there be an event?

[mray (mrayyyy)]

Hi - thanks for reporting this bug, I've manually migrated it to Inkscape's new
bug tracker on GitLab, and closed it here.

Please feel free to file new bugs about the issues you're seeing at
http://inkscape.org/report.

Moved to: https://gitlab.com/inkscape/inbox/issues/324
Closed by: https://gitlab.com/mray