Keep path's custom informations after a boolean operation

Bug #187449 reported by the_only_dude
8
Affects Status Importance Assigned to Milestone
Inkscape
Triaged
Undecided
Unassigned

Bug Description

hye,

i'm the inksmoto main developper (xmoto level editor which is an inkscape
extension
look at that to see the different possibilities:
http://wiki.xmoto.tuxfamily.org/index.php?title=Inkscape-0.4.0

Xmoto is a gpl game:
http://xmoto.tuxfamily.org/ )

some times ago, Ted Gould told me that:

"What I would recommend for this is add a custom X-moto namespace on the XML file.
Inkscape will honor this, and keep it in the file. So something like this:

<path d="M 1 1 M 2 2 M 3 3 z" xmoto:vertex-settings="rrg" />

Where 'r' and 'g' mean something about the vertexes of the path."

So i add some path information in my own xmoto namespace:
<path
ns0:xmoto_label="edge:downtexture=street|edge:texture=street"
id="rect2388"
d="M 314.29911,415.20982 L 314.29911,98.084821 L 128.58036,98.084821L
128.58036,415.20982 L 314.29911,415.20982 z"

style="stroke-linejoin:miter;stroke-opacity:1;fill-opacity:1;stroke:lime;stroke-linecap:butt;stroke-width:1px;fill:#66ddaa"
/>

with the namespace definition:
<svg
xmlns:ns0="http://xmoto.tuxfamily.org/"
(the name ns0 is automatically choosen by lxml)

But, when i do a boolean operation on this path, my ns0:xmoto_label
disapeared in the new paths created after the boolean operation...
<path

style="fill:#66ddaa;fill-opacity:1;stroke:#00ff00;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 575.875 242.375 L 390.125 242.375 L 390.125 423.9375 L 575.875
423.9375 L 575.875 242.375 z "
id="path3184" />
<path

style="fill:#66ddaa;fill-opacity:1;stroke:#00ff00;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 390.125 106.8125 L 390.125 242.375 L 575.875 242.375 L 575.875
106.8125 L 390.125 106.8125 z "
id="path3179" />

i've tried with both inkscape 0.45.1 and 0.46 svn from yesterday and the
behaviour is the same...

there's a bug that prevent keeping my informations after a boolean operation.
(i've also tried putting my informations into inkscape:label, but it's
dropped too after a boolean operation)

Here is a response by bbyak from the forum about it:

The reason is that boolops create new paths and don't know that they need to copy over all the attributes of the old paths. It should not be too difficult to fix, if you want to look into it try src/splivarot.cpp where all boolops are.

Tags: boolops svg
Revision history for this message
Bryce Harrington (bryce) wrote :

Ted, could you take a look at this one?

Changed in inkscape:
assignee: nobody → ted-gould
status: New → Incomplete
Revision history for this message
the_only_dude (thisaccountisadeactivatedaccount) wrote :

hye,

here's a patch which solve the problem.
it changes only src/splivarot.cpp

the diff was generated with:
 ~/inkscape-svn$ svn diff -x -u > custom_attr.diff

Revision history for this message
the_only_dude (thisaccountisadeactivatedaccount) wrote :

There's also the problem when you convert a rectangle/ellipse to path, the custom attributes are lost

Revision history for this message
Ted Gould (ted) wrote :

Mental, I think this is more likely to be code you're familiar with. Can we do with with some "magic namespace" stuff instead of listing the attributes?

Changed in inkscape:
assignee: ted-gould → mental
Revision history for this message
bbyak (buliabyak) wrote :

I tested this patch but it has a big problem: if you combine stars or ellipses and not paths, it copies over the sodipodi:type attribute and all the rest, and thus the result turns out to be a star as well, exactly the same as original. So boolean operation visibly fails. I agree that listing the attributes is not really a good idea. Mental, what would you suggest?

Revision history for this message
the_only_dude (thisaccountisadeactivatedaccount) wrote :

As Ted Gould suggests it, a way of doing it should be to copy attributes which use a custom namespace

standart namespaces are:
u'sodipodi' :u'http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd',
u'cc' :u'http://web.resource.org/cc/',
u'svg' :u'http://www.w3.org/2000/svg',
u'dc' :u'http://purl.org/dc/elements/1.1/',
u'rdf' :u'http://www.w3.org/1999/02/22-rdf-syntax-ns#',
u'inkscape' :u'http://www.inkscape.org/namespaces/inkscape',
u'xlink' :u'http://www.w3.org/1999/xlink',
u'xml' :u'http://www.w3.org/XML/1998/namespace'

Revision history for this message
the_only_dude (thisaccountisadeactivatedaccount) wrote :

here's a new patch doing the 'magic namespace'.

here's how it works:
add a new attribute to SPXMLNs: bool is_custom
the namespaces from repr-util.cpp are the standart ones, those added by sp_xml_ns_uri_prefix are custom ones.
(new function sp_xml_ns_is_custom to test if a prefix belongs to a custom one.)

when doing a bool operation or converting an object to path, it uses the sp_copy_custom_attributes function which copy the attributes from custom namespaces to the new object.

the sp_copy_custom_attributes function has been added to the repr-util.cpp file.

diff genrated with:
gorse@gorse-desktop:~/bordel/inkscape-0.47-svn/inkscape$ svn diff -x -u > custom_attr_namespace.diff
from svn 21209.

Revision history for this message
MenTaLguY (mental-deactivatedaccount) wrote :

I don't think it's safe to blindly copy over attributes that we don't understand; they won't always make sense in the new context.

Revision history for this message
MenTaLguY (mental-deactivatedaccount) wrote :

So here's what I'm thinking at present; we add something like this to the SVG (probably in <defs>):

<inkscape:extension-attributes>
  <inkscape:extension-attribute ns="http://xmoto.tuxfamily.org/" name="vertex-settings" policy="preserve" />
</inkscape:extension-attributes>

And then any attribute so indicated would be preserved.

tags: added: svg
su_v (suv-lp)
tags: added: boolops
su_v (suv-lp)
Changed in inkscape:
assignee: MenTaLguY (mental) → nobody
status: Incomplete → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.