🦋 Changeset detected

Latest commit: 84289a0

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing jcayzac:svg-rasterization (84289a0) with main (37ab65a)¹}

Summary

✅ 9 untouched benchmarks

Fixed a few things:

• svg > raster works simply by removing the guards enforcing format to be svg if the input is SVG.
• svg > svg was broken because I stupidly removed some other check. Reverted now.
• raster > svg still gives an unsupported conversion error too.

Thanks for the PR!

I think this may be problematic as is. There are quite a few SVG features which Sharp doesn't support and because the default format is WebP, that could lead to user images breaking with the default props.

A main goal of the image APIs is to optimise file size to improve page load times for users, so I'd also be a bit nervous that this change could mean default props producing larger output file sizes than input, which is undesirable. There are some circumstances where rasterizing an SVG can produce smaller output (small icons with relatively complex paths e.g.) but it's not super common.

It could also be a bit awkward to work with images in this model if you didn't want SVGs to be rasterized. For example, if a user can provide an image in any format, you'd have to sniff out the SVGs and use conditionals to explicitly render them as such.

Hi @delucis!

Could you clarify what you mean? Images only get rasterized if the user explicitly sets format to a raster format. They never get rasterized "by default", so I don't understand all the above comments.

I think it might be good to better understand the use case here and why rasterizing SVGs would be valuable. Could you share a bit more?

OpenGraph images and other microdata thumbnails used in many places don't support SVG. You need to provide raster equivalents to the crawlers.

There are some circumstances where rasterizing an SVG can produce smaller output (small icons with relatively complex paths e.g.) but it's not super common.

That's definitely not a use case. I don't know why anybody would want to rasterize an SVG image they're showing on their website. It's not what people rasterize SVG images for.

Ah I have introduced a bug: webp is indeed added when format is omitted. It should not be added if the source format is svg, to preserve current behavior. Else, I'd need to enforce an explicit format for SVG, which would be a breaking change.

Fixed default format for SVG so nothing happens by default, preserving today's behavior.

@delucis Regarding use case, I'd like to generate a cache-bustable PNG favicon from an SVG "source of truth" favicon since SVG favicon's are not well supported. I can also imagine generating cache-bustable OpenGraph PNGs from SVG sources as well. These are two areas where having a raster image is actually preferred.

Something to consider adding to the docs: Sharp will throw an error when attempting to rasterize SVGs with embedded fonts.

Moving this to next in #15180