Replace System.Drawing.Common

[mrbean-bremen]

This is a spin-off of #346, where the discussion about this evolved.

---

Originally posted by @tub5 in #346 (comment):

To make it compatible with netstandard2.0 System.Drawing.Common can be used.

Please note this is not ideal on Linux due to System.Drawing.Common not being properly supported

---

Originally posted by @wieslawsoltes in #346 (comment):

System.Drawing.Common is basically dead for anything else then Windows https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/system-drawing-common-windows-only

No idea what we can do now

---

Originally posted by @gvheertum in #346 (comment):

Maybe with the new crossplatform frontend libraries that are emerging like MAUI, I think eventually some of the drawing logic might come into the .net standard scope somehow. Although maybe not these specific libs. (Edit: they mention maui in the article, but that means we need to migrate code).

We could try wrapping the libraries for non windows environments and reroute to an alternative (basically making our own system.drawing), but this might break stuff and adds complexities along the way (and this means we are proxying a lot of stuff). So perhaps this could be an experimental path (since the behavior and output will most likely differ in the first versions).

But perhaps before doing much research and work we could check whether non windows environments are common and what stuff is being used that might cause issues.

edit: Changed some bits due to confusion on my side. I wonder why they explicitly break builds if there are wrappers for non windows system available. I’m curious whether this will also break if the SVG all is already built and served over nuget, because that might not throw the error and magically might make the library work without further issues.

---

Originally posted by @gvheertum in #346 (comment):

According to the Microsoft article there is a “work around” to prevent the error being emitted when working on non windows systems

System.Drawing.EnableUnixSupport runtime configuration switch to true in the runtimeconfig.json file

They might remove this switch in the future, but for now this buys time when building against framework 6.

[AlexandreBazeaud]

any update on this ?

[Happypig375]

Use https://github.com/wieslawsoltes/Svg.Skia

[mrbean-bremen]

@wieslawsoltes - could Svg.Skia generally be the replacement for Svg under non-Windows systems? Or even under Windows systems? I think we should make it clear in the README/documentation what will not work and what could be used instead (like Svg.Skia).

[wieslawsoltes]

I think you can recommend Svg.Skia in cases where System.Drawing is not available.

[wieslawsoltes]

Svg.Skia has few advantages like almost full support for filter effects and it can be hardware accelerated.

[wieslawsoltes]

This is my attempt wieslawsoltes/Svg.Skia#94 things are bit broken right now, will take some time to fix those.

[p-svacha]

Has there been any progress or workaround on this issue?

I'm trying to use this library to create svg's from scratch within Unity. The whole svg creation process works without problems but whenever I try to convert the svg into a string with SvgDocument.GetXML() I get a "PlatformNotSupportedException".

Or as another approach, is there a way to get an SvgDocument as a string without having to use System.Drawing.Common?

Using another library is of course also an option but so far I haven't found any that supports creating svg's from scratch as well as this one does.