URI acceptance and loops with respect to SVG spec [167247]
Hi all,
I recently started to work on bug 167247 [1]. This bug is about circular references in svg [For now, i'm working with local references, not references to the "containing file" itself as described in first comment of the bug report]
I narrowed it to the URIReference::_acceptObject method: some references are accepted, when they create loops (and should be rejected). The relevant part of the spec[2] states:
''' IRI references that directly or indirectly reference themselves are treated as invalid circular references. '''
which i translated like this:
''' Once we have an object, it can accept a href to another object, iff the graph of objects where directed edges are either parent->child relations , **or** href'ing to href'ed relations, stays acyclic. '''
This prevents us to have loops like (read this as a regexp) "/a use to a group( whose descendant is a use to a group)+ containing the original/", which was NOT prevented by the previous check who checked only for descendance, not linking loops.[5]
This will also prevent such loops as "a clippath containing a rect which has(refers to) a clippath which contains a use to a rect which has the first clippath as clipping".
(There were also crashes with patterns using themselves indirectly, masks, etc that will be solved with this method, or any crashes with any looping combination of hrefable elements)
*But* (yes, there is always a but) that would also prevent behaviour like "a rect clipped by its clone" even when there is no "rendering loop" (understand this as "no segfault for now") which would have to be done with a LPE that keeps a copy of the rect in the clippath, not a <use>. [3] I don't know precisely if that is what is intended by "directly or indirectly references themselves", but i believe so.
( Also, I'm looking for a nicer way to get the "original" of a pseudo-element inside a <use> (those elements that have element->cloned == true) than what's in my patch[4] (which is : go up to the element that does not have ->cloned set to true, look at the path you've followed in the tree, getOriginal(), follow the same path in the reverse order, repeat while you're ->cloned) )
Thanks,
participants (1)
-
Marc Jeanmougin