netstandard compatibility

[maitredede]

Hi,
Is it possible to refactor SVG a bit so core SVG parsing is compatible with netstandard, and rendering is split into other libraries ? So there can be an implementation for the framework (the actual one), and implementations for dotnet core (based on ImageSharp for example).
Thanks.

[tebjan]

hello @maitredede, the library is open source. you are welcome do refactor it to your liking. if got something running, don't hesitate to open a pull request.

[wyshmily]

@maitredede do you have a solution now?

[maitredede]

@wyshmily The solution would be to fork and refactor.

The System.Drawing library is deeply integrated inside SVG, so does System.Web. Removing dependencies on both needs to rethink the library.

This will be really time-consuming.

[mmosca]

It may be possible to still depend on System.Drawing basic types and refactor the rendering itself to use something else. .Net Core does have a lot of the types in System.Drawing available, just not the GDI rendering code.

…

On Tue, Nov 14, 2017 at 8:46 PM, Damien DALY ***@***.***> wrote: @wyshmily <https://github.com/wyshmily> The solution would be to fork and refactor. The System.Drawing library is deeply integrated inside SVG, so does System.Web. Removing dependencies on both needs to rethink the library. This will be really time-consuming. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#346 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWdr9Ntpj4BOvhNrw6ihzqhpcL1Zh4uGks5s2e35gaJpZM4Qcg-u> .

[maitredede]

The Gdi rendering part is in preview. I think it should be better to split SVG handling and rendering to allow custom rendering engines. For example I would be pleased to have a rendering based on ImageSharp. Le 22 nov. 2017 19:24, "Marcelo Bezerra" <notifications@github.com> a écrit :

…

It may be possible to still depend on System.Drawing basic types and refactor the rendering itself to use something else. .Net Core does have a lot of the types in System.Drawing available, just not the GDI rendering code. On Tue, Nov 14, 2017 at 8:46 PM, Damien DALY ***@***.***> wrote: > @wyshmily <https://github.com/wyshmily> The solution would be to fork and > refactor. > > The System.Drawing library is deeply integrated inside SVG, so does > System.Web. Removing dependencies on both needs to rethink the library. > > This will be really time-consuming. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#346 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ AWdr9Ntpj4BOvhNrw6ihzqhpcL1Zh4uGks5s2e35gaJpZM4Qcg-u> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#346 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABrwIFzoH7MWnspPOuYZyWwTJRmsoQ8yks5s49pPgaJpZM4Qcg-u> .

[JimBobSquarePants]

Having had a quick look at the library it would take serious refactoring to allow enough abstraction to use another rendering engine like ImageSharp since the integration is so tightly coupled.

Since System.Drawing will never be part of the NetStandard and is being worked on now as part of the Windows Compatibility Pack to help with migrations only I would recommend making such an abstraction a priority if NetStandard support is a goal for the library.

[jaedson-barbosa]

Hi, I'll try to port that for the .NET Standard, but that port won't have the renderer system, it just will generate the SVG files using a black and white image.

[wieslawsoltes]

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

[tub5]

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

[mrbean-bremen]

@wieslawsoltes, @gvheertum: any thoughts on this?

[wieslawsoltes]

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

[gvheertum]

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.

[gvheertum]

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.

[mrbean-bremen]

Note: I have copied over that discussion to the separate discussion issue #910.