SVG Image sources behave unpredictably. #825
Comments
Noemata
changed the title
|
This sounds like #312 which was an OS bug that was fixed in Windows 1903. I don't know if you're able to try this out on that build to confirm? |
|
FYI, on 1809 / 1903 without the margin tweak you get:
Where as the image in Inkscape is like so:
The SVG page dimensions are correctly adjusted to the image area in Inkscape, unlike the XAML above, which has an odd gap at the bottom. Also, if you apply horizontal/vertical centering, it doesn't behave correctly. Take any random, somewhat involved SVG image from virtually any source, and you'll most likely see this behavior with 1809 / 1903 and all previous OS releases that supported SVG. This bug has been around for quite some time now. Which means the regression testing is flawed either because it uses an extremely narrow range of SVG content, or the test cases do not test boxing at all. |
|
Once this is fixed, you'll need to preserve the old bug, unfortunately. The consequence of not getting it right the first time. |
|
If you open your SVG file in a text editor, you'll see the XML inside it -- does it contain any "weird" features? Unfortunately SVG was designed with a combination of reliable and unreliable features. For example, SVG files have the ability to contain embedded CSS (the CSS from HTML) -- a complex bad design. For example, if your SVG file uses unreliable and unnecessary features like this... Then it might help if you simplify the SVG by removing the unreliable features as follows: SVG is great when you avoid using the optional unreliable features such as embedded CSS, etc. SVG2 contains even more features. If every SVG feature is supported, then it guaranteed to malfunction under certain circumstances in certain situations, because the design includes so much unnecessary complexity that nobody will ever be able to write a 100% bug-free implementation of the entire SVG and SVG2 specifications. But if you limit yourself to the reliable portions of the specifications, then it works. |
|
@verelpode, thanks for the workaround suggestion. Given Microsoft is a top tier company, in this case I expect the SVG API's to either be identified as experimental or beta if they are in a half baked state, or they should support the SVG spec in full. The harsh reality of being in the top three OS tier is that expectations are appropriately high, thus you have to deliver on your API promise. IOS API's are more stable and conformant than equivalent UWP API's, so UWP suffers from a lack of adoption because of its stability and conformance gap. Lastly, if it works in Inksace (Open Source) and Adobe, it must work in UWP. If you don't support the output of commonly available tooling, what's the point? Imagine having to tweak an MS Word binary so it could load in some third party application. You would consider such a product as unusable, despite the fact that MS Word files have gone through many iterations in structure. |
|
@Noemata, can you share an SVG file you're seeing this problem with? Note that not all of SVG is currently supported, as documented here: https://docs.microsoft.com/en-us/windows/desktop/Direct2D/svg-support |
msft-github-bot
added
the
needs-assignee-attention
I agree except that unfortunately it is most likely impossible in the case of SVG. Asking for SVG to be 100% supported and compatible is like asking for all HTML web browsers to deliver 100% compatibility with each other, and to render exactly the same as each other. It should happen like you said, but in practice, it's never going to happen. SVG, SVG2, and HTML are not the kind of standards that can be 100% supported and compatible. To achieve 100%, a standard must exclude vague/unreliable features and it must be designed in a certain way, but SVG, SVG2, and HTML are not designed in such a way. I want what you said but it's impossible -- that's the harsh reality. Thus the workaround is to edit your SVG file and remove all usage of vague and unreliable features. |
|
@verelpode, I do not expect more than 95% SVG spec conformance. I do expect 100% tooling conformance with products like Adobe/Inkscape which have been around for ages. If you can't load Inkscape SVGs, which provides the loader/parser source code then you aren't really trying to be conformant. The designer folks aren't programmers, so we can't expect them to be tweaking the output from the tooling they use. Again, what's the point, if you can't support the tooling that's out there? I'm pretty sure Microsoft can do at least as well as Inkscape. Microsoft's Expression Design was pretty darn good, still is and it's got a boatload of mothballed code. Oh, Visio SVG's don't load correctly either. If Visio can load an SVG (Inkscape or Adobe) correctly, the XAML SVG capability should be at least as good. |
|
@Noemata |
|
@verelpode, most SVG files fail to behave correctly, including output from Visio. If Microsoft get's all Visio and Inkscape SVG output to load correctly, I'll consider that good enough for now. This is not something I need to prove further since it's so easy to generate complex output from either Visio or Inkscape for test purposes. A simple box isn't a valid test case, obviously. There are also the SVG v x.x test suites, which Microsoft clearly isn't using for validation purposes. These test suites provide expected output to validate conformance. Sorry, but I mostly disagree with your complexity premise @verelpode. Test suite conformance validation is available for the SVG spec, hence why I asked for Microsoft's test conformance strategy. Last but not least, Visio does better, and Microsoft can share this code with the XAML tooling folks. (https://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview). Almost forgot, Microsoft Edge loads 99% of SVG content flawlessly. |
And thank you @verelpode for your help digging in on this issue! :) |
|
@Noemata wrote:
I wasn't expecting you to prove anything, rather I just hoped that you would make it easier for me to help you, especially because it's not my job to help you and I do have a bunch of other tasks that I need to complete. Out of interest, I'd like to try your example in Visual Studio and investigate deeper, but you haven't given the complete example. You've given the XAML but not the SVG. It'd help if you also give a specific SVG file that demonstrates the problem. Yes I could go and install Inkscape and make and test various SVG files myself, but that's extra work and it's not my job -- I'm just a volunteer with little spare time. @jevansaks -- Thanks for the acknowledgement :) |
|
@verelpode, since I have no expectation of you being able to resolve API bugs I would consider it unfair to burden you with trying to fix this. But since you insist. I've stripped out the intermediate letters of the logo because I don't have permission to include the whole thing. The missing letters are immaterial to the result. I've also converted the logo to XAML in order to show how things should be rendered. Here is the SVG content for ImajionLogo.svg:
And here is the XAML: ` ` Finally, here is the SVG content as shown in Inkscape:
Notice that this very simple SVG file is not rendered at all by the UWP XAML engine. I had to muck with it to get it to render in UWP. Given the simplicity of the SVG content and the fact that it appears to adhere to the minimal requirements as stipulated by @codendone, I think its reasonable to expect this to just work without having to resort to manual adjustment. This SVG file loads correctly in Affinity Designer, Inkscape, a host of Adobe products and Visio. I'm not posting my manually adjusted version because it would not be representative of output from a typical third party editing tool. Snapshot taken from online docs for supported UWP SVG capabilities:
|
|
Source code for sample: |
|
@Noemata Your XAML contains: Thus your Image element is rendered as 300 pixels(DIP) high because the Height property is set to 300 -- yes, as simple as that. Did I misunderstand you? I don't see any bug, rather the rendering that you've described is the correct rendering. In your earlier message, you wrote:
Yes I get the same result as you, but it's not a bug. It's rendered correctly. Your Image element is set to Height="300" thus it consumes 300 pixels(DIP) vertically, regardless of the source image file, and regardless of whether it is .SVG, .JPG, or .PNG. |
|
Thanks for all the discussion here and especially the help from @verelpode. It sounds like the problem is understood now. I'm closing this issue, but @Noemata please reactivate if you believe there's still a platform bug here. |
msft-github-bot
removed
the
needs-assignee-attention
|
@jevansaks, thank you for your patience with my machinations. |
|
When you use the SVG Don't use that "feature" -- you need to change it to In software engineering, it's necessary for you (anyone) to acknowledge the fact that you're not Superman. Nobody has superhuman abilities. Therefore unnecessary complexity needs to be removed, otherwise the product becomes incomprehensible and unreliable. It doesn't matter how smart a person is. Even the smartest person in the world trips up when the software contains an unnecessarily complex combination of features (and anyway, a "smartest person" doesn't exist in reality). Keep it simple. Simple is smart. |
It comes from the initial size of the app window (the window size that can be changed by invoking To aid debugging, I've simplified this example by using
Following is uncropped, produced by making the window larger by invoking
The SVG image file is simply this: As I mentioned in my previous message, a solution is to use Even when all rendering bugs are fixed, I still highly recommend using i.e. Noemata expected the SVG ...without requiring the setting of any of the width, height, viewBox, preserveAspectRatio attributes. |
|
For further reference, the cropping bug still occurs when the SVG file begins with any of these examples: The cropping bug disappears if you use this: I don't have access to the SVG renderer source code, but if I did, I believe the first thing to do should be to look at how it ends up using the app window size in the rendering. To improve reliability, make it render entirely independently of the initial and current app window sizes. The app window size should be irrelevant. I also suggest adding a note in the public documentation to say that if the SVG file uses the |
|
preserveAspectRatio is not required when rendering SVG content in IE, it renders as expected, similarly with other 3rd party products that support SVG (Inkscape), so I suggest the default behavior on Windows should be that of IE as a minimal goal. |
|
I agree with @Noemata. It shouldn't be necessary for people to edit their SVG files to insert In other words, in order to make Even if a software engineer is an absolute expert, it doesn't matter; sometimes a complicated feature is garbage that should be switched off or eliminated or simplified, regardless of whether it's used by beginners or experts. |
|
Found another image the behaves strangely: <Image Stretch="Uniform" Source="https://upload.wikimedia.org/wikipedia/commons/8/84/Example.svg"/>It seems to clip itself when smaller and doesn't scale smoothly: |
|
@michael-hawker It looks like that svg doesn't scale at all, which means it will clip if the XAML Image isn't given the full 600x600 space that svg is requesting. Some svg files can be fixed by changing the svg tag in the file to have width="auto" height="auto" preserveAspectRatio="xMinYMin meet", but those don't help here. Thanks for the additional sample. XAML's svg handling clearly needs some work to automatically handle scaling without a bunch of custom hacks. |
|
Rather than having a custom SVG renderer, implementing an SVG to XAML converter would be very useful. Then the SVG content could be leveraged in all sorts of ways beyond just displaying it. It would also increase the likelihood of having a fully XAML friendly implementation of SVG support. Work like this has already been done for WPF. |
That'd be nice too, but would have to be on the designer pipeline export from whatever tool they're using without introducing a lot more overhead on a process stand-point. It'd be nice though, as then it'd be easier to animate/manipulate graphics in storyboards and such. |
|
The SVG renderer is clearly still broken, but I've had good luck with using Inkscape to save the files as XAML and using that in UWP, in case that helps anyone. |
|
It might make more sense to have a special SVG mode for the browser control instead of having a specialized SVG renderer for XAML. @michael-hawker's idea of having tooling support is a good one, but we still need an SVG renderer in XAML. My UWP TV broadcasting app needs it bigtime! PDF and SVG rendering should have a native feel within XAML! SVG in particular. |
This is a viable workaround, but it's hardly a solution. XAML files generated from SVGs can't be used in other non-UWP apps, while SVG is [supposed] to be supported by all of them. A better solution would be to embed that conversion code into XAML's SVG 'parser'. That way, you can supply an SVG and it will be converted to XAML at runtime, rather than requiring devs to put together a second set of images/icons. |
"embed that conversion code into XAML's SVG 'parser'" is exactly what I had in mind, by the way. |
|
I find UWP/.NET does not support styles and CSS like classes. Have you guys found an SVG optimizer that removes them and replace them with attributes? XAML exports from Inkscape could not be loaded in my UWP project, it choked on that Figures attribute for some reason. |
Actually Adobe Illustrator has an option to export SVGs without CSS styles. |
|
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
|
WinUI 3 still has limited SVG support. This issue is still present and critical. |
JJBrychell
added
feature proposal
|
Changing to feature proposal |
The image below below:
Is produced with the following XAML:
For the second SVG image, we're having to muck with Margin settings to get an approximation of the result we expect to get without such adjustments. The SVG image behaves correctly in every SVG editing tool we've tried, including all Adobe products, and Inkscape.
We encountered poor placement behaviour with many different SVG images. Occasionally, it almost works correctly, like the case with the first SVG image above, though adjusting centering has never worked as expected. Please provide an example of the test suite you use to qualify that this is working. We've never gotten proper placement to work as expected with anything but the simplest of SVG images.
The text was updated successfully, but these errors were encountered: