-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[expo-image][ios] SVG rendering issues #23669
Comments
Thank you for filing this issue! |
Wondering if there is any timeline on this? It would be really useful for my app as currently can't use the SVGs I want with this package as they are getting distorted. |
@jozan im curious if you were able to render these SVG images with react-native-skia maybe Expo could switch to use skia under the hood. |
i haven't tested on skia. the repo is still up for anyone to try. |
The SDWebImageSVGCoder plugin this library relies on uses an undocumented Apple API called CoreSVG, which it calls through base64 obfuscated methods to fool Apple's static analysis. CoreSVG unfortunately seems to be incomplete, though how incomplete seems to be a bit of a mystery. I'm dealing with an issue where it doesn't show an embedded image rendered in a pattern using The maintainers claim CoreSVG is at least better than SVGKit, which they were using previously. They've also come out with SDWebImageSVGNativeCoder, which uses an Adobe library to render a standardized SVG subset called SVG-Native. They claim better compatibility with that standard, but the standard only covers part of the overall SVG spec by design, so that has a list of caveats. Skia's SVG renderer seems cool, but also has a list of caveats, as documented on the page you linked to. So, which one is going to work best depends on what subset of SVG is needed. I wonder if it would make any sense to allow an expo-image user some control over which SDImage SVG plugin is used, among the three available. Unfortunately, for my use case I'm loading arbitrary SVGs supplied by users, so that subset may be pretty open-ended (though not infinitely so, I don't need interactivity, animation, scripting, etc.). It's getting judged against browser support for those same SVGs. And if it doesn't work, it looks bad in front of a lot of people. The SVGView project, which seems even more incomplete than some other solutions, had at one point the ambition to reach 100% feature completeness, and so runs their renderer against a test suite of samples provided by W3C. It'd be interesting to try to establish which of these does the best on the most commonly used set of SVG features as judged by the same benchmark and/or a feature matrix derived from the documented caveats provided by some of these, but that does seem like a lot of work, and requires defining "most commonly used." I feel like someone has to have a more or less complete SVG renderer, at minimum web browsers do. Maybe I'll shell out to a web view for this. |
Minimal reproducible example
https://github.com/jozan/svg-expo-image-rendering-ios-repro
Summary
on iOS there are rendering issues with svgs when using
expo-image
. i've attached a repro repo which uses managed expo workflow with sdk 49.icon sets that are used as examples:
i have attached some screenshots show that some svgs render blank and some have weird rendering issues. as we can see, rendering fails on some very simple paths. i have highlighted some of the issues on the screenshots for quick reference.
we can also see that on the heroicon there are lots of blank icons. almost all of the blank icons are
outline
type icons that are simple paths.note
some of the rendering issues can be fixed by running
svgo
on svgs which alters paths. this fixes all heroicon icons that are type ofsolid
. sadly this doesn't fix any of the rendering issues on ionicons. this is not done on any of the svgs in the repro repo nor is its set up.pinging @tsapeta since we had brief conversation about this issue on expo's discord and he mentioned having some initial plans to change the underlying native svg rendered at some point the future. however, there is no timeline for this as of now.
Environment
The text was updated successfully, but these errors were encountered: