Problematic 0px <svg:line> to guides conversion

[Robert Kosten]

I have created the attached file manually as a business card template. After opening and converting the "guides" group, trying to draw a rectangle leads to an immediate crash with "Internal error". Changing the stroke-width of the guides to 1px solves the problem, but creates two guides for every line, while I need only one. I assume the same happens with 0px, creating two congruent guides, and that confuses the snapper as to where to snap...

Exact steps to reproduce:
Open the file
Click somewhere in the middle of the page (follow the visible cut marks, the guides have a stroke-width of 0px)m you should select the "guides" group
Object -> Ungroup
Object -> Objects to Guides
Select Rectangle tool
Try drawing a rectangle (within the upper left card area)

Environment:
Ubuntu 9.04 x86_64 Desktop (with a lot of KDE stuff installed as well)
Linux garak 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux
Inkscape 0.46 (Apr 8 2009)

Locale:
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

GDB Output:
ERROR:line-snapper.cpp:42:virtual void Inkscape::LineSnapper::_doFreeSnap(SnappedConstraints&, const int&, const NR::Point&, const bool&, std::vector<NR::Point, std::allocator<NR::Point> >&, const std::list<const SPItem*, std::allocator<const SPItem*> >&) const: assertion failed: (i->first != NR::Point(0,0))

Backtrace:
#0 0x00007fd976b38fb5 in raise () from /lib/libc.so.6
#1 0x00007fd976b3abc3 in abort () from /lib/libc.so.6
#2 0x00007fd979cda4f3 in g_assertion_message () from /usr/lib/libglib-2.0.so.0
#3 0x00007fd979cdaa82 in g_assertion_message_expr () from /usr/lib/libglib-2.0.so.0
#4 0x000000000058bd86 in ?? ()
#5 0x00000000005667de in ?? ()
#6 0x00000000005669fa in ?? ()
#7 0x0000000000557e77 in ?? ()
#8 0x000000000051f9e2 in ?? ()
#9 0x000000000076ef60 in ?? ()
#10 0x00007fd97a55d27d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#11 0x00007fd97a572e3b in ?? () from /usr/lib/libgobject-2.0.so.0
#12 0x00007fd97a5742bd in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#13 0x00007fd97c153f65 in gtk_signal_emit () from /usr/lib/libgtk-x11-2.0.so.0
#14 0x0000000000750c30 in ?? ()
#15 0x00007fd97bfeadf8 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#16 0x00007fd97a55d27d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#17 0x00007fd97a572b1e in ?? () from /usr/lib/libgobject-2.0.so.0
#18 0x00007fd97a5742bd in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#19 0x00007fd97a574953 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#20 0x00007fd97c0f309e in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#21 0x00007fd97bfe3693 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#22 0x00007fd97bfe47b3 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#23 0x00007fd97bc5df3c in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#24 0x00007fd979cb420a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#25 0x00007fd979cb78e0 in ?? () from /usr/lib/libglib-2.0.so.0
#26 0x00007fd979cb7dad in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#27 0x00007fd97bfe4bc7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#28 0x000000000044f749 in ?? ()
#29 0x000000000044fb95 in ?? ()
#30 0x00007fd976b245a6 in __libc_start_main () from /lib/libc.so.6
#31 0x000000000044ecc9 in ?? ()
#32 0x00007fff86459908 in ?? ()
#33 0x000000000000001c in ?? ()
#34 0x0000000000000001 in ?? ()
#35 0x00007fff8645b739 in ?? ()
#36 0x0000000000000000 in ?? ()

[Diederik van Lierop (mail-diedenrezi)]

Could you please try to reproduce this with one of the development builds? You can find those for Ubuntu here:

http://ubuntu.cafuego.net/dists/jaunty-cafuego/inkscape/

or here:

http://launchpad.net/~inkscape-nightly/+archive

I've just tried to reproduce this myself with the latest build on Fedora, to no avail. So either I'm a moron or this has been solved already ;-)

[Luca Bruno (lucab)]

Can you please try to reproduce this with latest SVN with debug symbol and attach a full backtrace?

[Adonis Papaderos (ado-papas)]

It seems that the problem has to do with converting svg:lines to guides. The problem rises even if only one line is transformed into guides. Inkscape creates 4 guides for each line setting the orientation attribute of 2 of them to 0,0 resulting in a crash of the application.

Using GUI lines are represented with a path tag, which converts normally to 1 guide.

As a temporary workaround lines can be first converted to paths, and then converted to guides.

[Adonis Papaderos (ado-papas)]

Seems that inkscape-nightly, although it does not crash, it still produces the same set of guides for each line.

[Diederik van Lierop (mail-diedenrezi)]

In general Inkscape will use the bounding box of an object to create the guidelines, resulting in 4 guidelines. Only for some specific objects (3dboxes, paths, and rectangles) code has been implemented to (optionally) use the line segments which constitute that specific object. It should be quite simple to make sure that for svg:line only a single guide is created; Some questions immediately arise though:
1) what other objects should be taken into account too?
2) where in the preferences dialog are we going to place the checkbox to control whether the boundingbox is used or not (see for example tools -> shape -> rectangle. IMO we should have only one single checkbox, instead of one for each object individually.
3) wouldn't it make sense to put this guide creating code in the sp_shape class, which is the base class of many (or all?) of these objects. See for example sp_shape_snappoints, which does something similar. It can then still be overridden by a specific class if needed

In case any one is going to work on this, start digging in sp_item_convert_item_to_guides and in sp_rect_convert_to_guides.

[Diederik van Lierop (mail-diedenrezi)]

Thanks Adonis, excellent patch! It has just been committed to trunk, see rev. #21459.