SVG Image sources behave unpredictably.

[Noemata]

The image below below:

Is produced with the following XAML:

        <Grid>
            <Grid.RowDefinitions>
                <RowDefinition Height="Auto"/>
                <RowDefinition Height="*"/>
            </Grid.RowDefinitions>
            <Grid x:Name="VersionStack" x:FieldModifier="public" Grid.Row="0">
                <Grid.RowDefinitions>
                    <RowDefinition Height="Auto"/>
                    <RowDefinition Height="64"/>
                    <RowDefinition Height="Auto"/>
                    <RowDefinition Height="Auto"/>
                    <RowDefinition Height="Auto"/>
                    <RowDefinition Height="Auto"/>
                    <RowDefinition Height="Auto"/>
                </Grid.RowDefinitions>
                <TextBlock Grid.Row="0" Text="InformationxR" Style="{StaticResource SubtitleTextBlockStyle}" Margin="0,0,0,10" />
                <Image Grid.Row="1" Width="300" Height="160" Source="/Assets/InformationxR.svg" Stretch="UniformToFill" HorizontalAlignment="Left" Margin="20,0,0,0" />
                <TextBlock Grid.Row="2" Text="Version" Style="{StaticResource SubtitleTextBlockStyle}" />
                <TextBlock Grid.Row="3" Margin="20,10,0,10" x:Name="Version" Foreground="{ThemeResource ApplicationSecondaryForegroundThemeBrush}" />
                <TextBlock Grid.Row="4" Text="Copyright © 2019 by" TextWrapping="Wrap" Style="{StaticResource SubtitleTextBlockStyle}" />
                <HyperlinkButton Grid.Row="5"  NavigateUri="http://www.imajion.com">
                    <Image Width="480" Height="300" Source="/Assets/ImajionLogo.svg" Stretch="Uniform" HorizontalAlignment="Left" Margin="14.5,-110,0,0" />
                </HyperlinkButton>
                <RichTextBlock Grid.Row="6" HorizontalAlignment="Left" Margin="20,-110,0,0">
                    <Paragraph FontSize="20" Foreground="{ThemeResource ApplicationSecondaryForegroundThemeBrush}" FontWeight="Normal" FontStyle="Normal" FontStretch="Normal" TextAlignment="Left">
                        <Run />
                        All rights reserved.
                    </Paragraph>
                </RichTextBlock>
            </Grid>
        </Grid>
    </Grid>

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.

[jevansaks]

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?

[Noemata]

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.

[Noemata]

Once this is fixed, you'll need to preserve the old bug, unfortunately. The consequence of not getting it right the first time.

[verelpode]

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...

<svg xmlns="http://www.w3.org/2000/svg" style="margin-left: calc(50% - 0.5em)" viewBox="0 0 1024 1024" width="1024" height="1024">
    <g transform="scale(0.03125)">
        <path d="..."/>
    </g>
</svg>

Then it might help if you simplify the SVG by removing the unreliable features as follows:

<svg xmlns="http://www.w3.org/2000/svg">
    <path d="..."/>
</svg>

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.

[Noemata]

@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.

[codendone]

@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

[verelpode]

@Noemata

The harsh reality ... expectations are appropriately high, thus you have to deliver on your API promise.

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.

[Noemata]

@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.

[verelpode]

@Noemata
OK, if you can share a particular SVG file, then we can look inside and see exactly what Inkscape produced, and get a clearer idea of why it's malfunctioning in your program, and see whether or not the problem lies in usage of unreliable or unsupported features or some other reason. (BTW, I'm just a fellow developer with interest in SVG in UWP apps, not a MS staff member.)

[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.

[jevansaks]

(BTW, I'm just a fellow developer with interest in SVG in UWP apps, not a MS staff member.)

And thank you @verelpode for your help digging in on this issue! :)