BUG : fix svg corner case #4388
Conversation
Under certain conditions the ``id`` of the `clipPath` node emitted by the svg writer will be the same for multiple files. If both svg fragments are embedded in the same document, then one of them is removed, the clipping of the remaining fragment can become inconsistent. See ipython/ipython#8133 Closes matplotlib#4349
|
There are probably less extreme methods of introducing this randomness, but this in guaranteed to work. |
|
Tested and works great. |
|
I'm 👍 on this |
|
That is a great explanation for why adding randomness to the svg nodes shouldn't impact users. |
|
Not so fast -- this means that if the same clipping path is used multiple times in the same figure, it will be stored multiple times. It's actually intended to be deterministic for this very reason. What we need instead, I think, is a random but document-specific hash. The simplest way to do this might be to generate the salt in the BackendSvg constructor and store it in a member variable, reusing it each time. |
|
@mdboom The key used for internal look up and the key used in the svg output are already different values, see https://github.com/tacaswell/matplotlib/blob/fix_svg_id/lib/matplotlib/backends/backend_svg.py#L449. The cache dictionary is keyed on an internally unique key (based on the cilp path details) and stores the tuple of the clip ptach + the oid (which is what is now randomized). |
|
Ah -- sorry for missing that detail. Looks good to me, then. |
|
If everyone likes this, can someone merge it 😉 |
BUG : fix svg corner case
Under certain conditions the
idof theclipPathnode emitted bythe svg writer will be the same for multiple files. If both svg
fragments are embedded in the same document, then one of them is
removed, the clipping of the remaining fragment can become inconsistent.
See ipython/ipython#8133
Closes #4349