Closed
Description
Right now, an error is reported if you try to use a file that does something like the following:
<svg>
<path fill="url(#MyGradient)" d="..." />
<linearGradient id="MyGradient" ...>
...
</linearGradient>
</svg>
This is done to make sure we don't have to maintain a full DOM or traverse the XML more than once.
However, it should be possible to keep an in memory structure of defs (probably a Map
of some sort) we expect to see but haven't seen yet, and go back and back-fill them (and then remove them from the structure after we found the def they're looking for) with only a little bit of memory overhead.
Metadata
Metadata
Assignees
Labels
No labels
Activity
IchordeDionysos commentedon Aug 28, 2019
Would really appreciate if this would be implemented.
We are having way to many/dynamic SVGs to change them all :)
NotThatBowser commentedon Sep 2, 2019
Would be useful. Affinity Designer produces SVGs with defs at the bottom, for example.
dnfield commentedon Oct 21, 2019
I thought I had a way to do this, but all the ways I've been able to come up with are pretty inefficient.
If we defer resolution until drawing time (e.g. a lot of things that are now static properties become functions/getters that may not work during the parse phase), we can avoid reparsing the document but may get into strange situations where we have lots of indirection going on via functions. For example, getting a Drawable's
fill
might actually be a function that calls a function that calls a function that returns the data by calling a few other functions to resolve its properties.If, on the other hand, we always parse defs in any order, we have to go to a DOM based model of parsing and do a lot of jumping around the document/tree, which will be very inefficient on particularly large SVGs.
This should be something that could be preprocessed away and avoid these complexities/inefficiencies.
hash404 commentedon Oct 22, 2019
I wonder if you there's a way to add build time pre-processing to avoid inefficiencies.
Something like how built_value.dart (https://github.com/google/built_value.dart) generates Dart files, could you have flutter_svg generating a compressed SVG that matches the format required by the package?
dnfield commentedon Oct 22, 2019
That's definitely doable, and something I've considered exploring but haven't had time to prioritize - or evidence that it would really bump performance enough to be worth it. And unfortunately it wouldn't help with network based images
I suppose a middle road might be having something like that and then allowing for a less efficient parsing algorithm - which would make precompiled images a bit faster but dynamic images even slower.
dnfield commentedon Jan 28, 2020
I thought I had updated this again, but I guess not.
Supporting this introduces a lot of complexity. In particular, references can have other references, which can have other references, etc.
To fully support this would require some substantial reworking - the simplest cases of only one level of nesting aren't too bad, but when those nested references have other nested references, it becomes a big ugly list of closures everywhere to resolve things, and will be much less efficient both time and space wise, not to mention getitng a lot harder to reason about.
I'm really hesitant to support this. But I also understand it's frustrating when you have an SVG you don't control that just comes this way.
ngaurav commentedon Jan 29, 2020
Why not just provisionally add support for single level nesting? Once done we can get a better idea if we need multi-level nesting support. Maybe multi-level nesting is very rare compared to single-level nesting.
ngaurav commentedon Jan 29, 2020
On second thought, If a file only has single-level nesting then it can programatically preprocessed to rearrange out-of-order declarations.
IchordeDionysos commentedon Jan 29, 2020
And if you can't? @ngaurav
Stored on another server/too many of them.
dnfield commentedon Jan 29, 2020
@IchordeDionysos - you could preprocess the SVG from the server before you pass it to this library.
In fact, maybe that's the right way to handle this - write a preprocessing package to rearrange defs. That way people who want to pay the performance and complexity costs (or have no choice) can, without forcing them on people with more sane SVGs.
13 remaining items
agueroveraalvaro commentedon Jun 7, 2021
is there a solution please? :)
cesc1802 commentedon Jun 22, 2021
i facing with this issue and figma design tool :( anyone can help me?
hpbl commentedon Jul 6, 2021
@willhaslett did you find a solution?
OlegNovosad commentedon Jul 25, 2021
The workaround for me was to move the
<defs>
up, as the first children in the<svg>
element. E.g.:Before:
After:
ebwood commentedon Aug 30, 2021
Any solution? Still not working.
tmdb.svg
26 remaining items