Home: Add support for SVG icons

[maartenba]

_From @jordimontana82 on April 10, 2016 11:44_

Hi,

I was looking at the Nuspec reference, and it looks like the only supported format for iconUrl property is a PNG of 64x64 pixels only.

Would be nice to include support for SVG formats too, cause we could use that to display high definition logos (specially logos containing fonts or similar) while at the same time files served will be small.

_Copied from original issue: NuGet/NuGetGallery#2981_

[NickCraver]

Throwing in that I'd like to see this for all of our libraries as well. We definitely want to render SVGs (and for the icons in Visual Studio to be HiDPI in general). Honestly I was surprised this wasn't supported already, it took me a bit to figure out why my test icons were rendering as the default.

Related: It seems like pieces of the client are HiDPI friendly while others are not, e.g. the refresh circular arrow is very pixelated.

[jainaashish]

Yeah, it seems like it would be a good addition but currently we are tied up with other important stuff so won't be able to get to this. We would still love to get a PR if someone wants to pick it up.

[zivkan]

Reopening this issue, as it's the best one we have to track SVG requests/interest.

Please upvote (👍 ) the original post to signal interest.

FYI, this work is non-trivial, as Visual Studio's Package Manager UI is based on WPF, which doesn't support SVG itself. Therefore, some 3rd party library would need to be used, but that's going to involve a whole lot of paperwork to make sure that the license is compatible, and that we provide attribution and distribution correctly in VS.

While we can take a community contribution for a library to draw SVG in WPF, there's a whole lot of work that the NuGet team will have to do in order to merge it, so it might be slow to accept. I'm not trying to discourage anyone from submitting a PR, just trying to set expectations.

At the time I'm writing this, the VAST majority of search requests to nuget.org is from Visual Studio, website search views on nuget.org is very small in comparison. So, we don't believe there's a benefit to unblocking pack from including SVG files for embedded icons at this time, because the vast majority of customers will see NuGet's default icon, and we think there will be enough package authors who will be confused about why their packages don't show their embedded svg icon, hence we don't want to enable svg pack until at least PM UI support is added.

[augustoproiete]

_At the time I'm writing this, the VAST majority of search requests to nuget.org is from Visual Studio, website search views on nuget.org is very small in comparison_

@zivkan This is very interesting to know. Thanks! I'll definitely pay more attention to how my packages are looking in Visual Studio (summary, description, etc.) after releasing new versions of libraries on nuget.org.

I wonder if this will change over time as more people move to SDK-style projects or if most devs will continue to prefer the UI in Visual Studio :thinking:.

I honestly don't remember the last time I opened the NuGet UI in Visual Studio... Probably many years ago. I always used install-package from the Package Manager Console and since moving to .NET Core & SDK-style projects I always go to nuget.org to find the right version of the package I need (check dependencies, TFMs supported, etc.), and then copy the PackageReference directly to my csproj :shrug:.

[tebeco]

FYI, this work is non-trivial, as Visual Studio's Package Manager UI is based on WPF, which doesn't support SVG itself. Therefore, some 3rd party library would need to be used, but that's going to involve a whole lot of paperwork to make sure that the license is compatible, and that we provide attribution and distribution correctly in VS.

Would it be possible to have this available publicly on nuget.org as statistics and metrics ?

• VS Version
• Nuget Client Version
• dotnet version (nuget embedded)

That would allow Author to have a visibility over that, could be for exampe updated once a week / month
That way we would all (contributor / author / maintainer) have the same shared information when working on open source project and see what's going on "under the hood"

[tebeco]

I would also like to quote @augustoproiete https://github.com/NuGet/NuGet.Client/pull/3773#issuecomment-732506565 from the PR #3773 here (so it would be tracked with this issue)

@zivkan Just an idea (which goes beyond this PR):

Phase 1 (initial svg support)

• Allow package authors to add an .svg icon in addition to .png, .jpg, or .jpeg to the NuGet package

  • Visual Studio (and other UI clients) can continue to use the regular icon inside the package as it is today
  • This would require a new element in the NuGet spec e.g. <packageVectorIcon /> (which would open the door for supporting other formats in the future such as .eps, .ai, etc.)
• Update the NuGet Gallery to use the .svg if one is available, fallback to one of the other icons
• It's the responsibility of the package author to provide both .svg and .png and ensure they match
• (Optional) Add validation to ensure they provided a .png, .jpg, or .jpeg in case they provided an .svg

Phase 2 (maybe, or just skip to phase 3)

• Update the NuGet Gallery to automatically generate a .png 128x128 from the .svg after upload

  • So that package authors don't have to worry about .png, .jpg, or .jpeg anymore. Just the .svg, which as @ZacharyPatten mentioned, is source control-friendly

Phase 3 (PM UI updates)

• Let Visual Studio update their UI to support .svg at their own pace
• Let JetBrains update their UI to support .svg at their own pace
• Let VS for Mac update their UI to support .svg at their own pace

Phase 4 (maybe one day, once major IDEs and UI clients understand packageVectorIcon)

• Deprecate .png, .jpg, and .jpeg in NuGet pack
• Stop generating .png from the .svg in the NuGet Gallery

[tebeco]

That would be lovely to move on something like this yes

because if I read this correctly (click to go the @zivkan answer in the PR) :

I don't know if adding PM UI SVG support to this PR is enough, or if we'd want to first add PM UI support, wait a release or two, so a significant number of customers are using a version of VS that supports it, and then unblock pack.

and the linked issue :

That would have been before Vs2017, and probably full support in vs2019, so the only way is to move forward because it's not going to solve backward compat if the "up to date" and "supported product" don't have opt in / support etc ...

I mean I'm not trying to enforce a full use of SVG everywhere, but just being able to use SVG in 2021 as another possible formet wherever it's possible.
This means that the fix on nuget.org is probably super fast to do (the DOM change) while Vs will still have png / ... but this part is up to VsTeams to keep up with the web technologies moving on.
It can't the forever things dragging down all the stack right ?

[tebeco]

I think we are all trying to move forward to see this land for every Author and Consumer, what can we do to help you about this ?
For example, can the Package Manager UI be Open Source so you would have contribution for Vs2017 and Vs2019 ?