search

imazen / imageflow

High-performance image manipulation for web servers. Includes imageflow_server, imageflow_tool, and libimageflow
https://docs.imageflow.io/
GNU Affero General Public License v3.0
4.14k stars 140 forks source link

Wish: Support for converting from SVG #593

Closed iJungleboy closed 2 years ago

iJungleboy commented 2 years ago

This may seem odd, but we could really use convert-from-SVG support.

Two main reasons:

  1. In a CMS environment there are many cases where users just add images and it should "just work". ATM the CMS would have to detect an SVG and not resize, or alternately detect no SVG and add url-parameters for resize. This would reliably allow to crop the image to the proper size, which won't work in a page which expects the picture to have the right size, just to be surprised by an SVG which does its own thing.
  2. Many share-this-page scenarios require Open-Graph headers which always require jpg/png etc. Again in many scenarios the page should just take the primary image - which in a community / CMS setup can sometimes be a SVG - and then should be able to use that as well. But Open-Graph can't work with SVGs, so it would be a perfect fit to some-illustration.svg?format=jpg&width=200 etc.
lilith commented 2 years ago

We dropped support for vector rasterization because of speed and security - it's really something that needs to be done ahead of time, within a sandbox, instead of on-the-fly. Svg, eps, pdf - all have had bad security flaws and huge or malicious files can swamp a server.

On Wed, Jan 5, 2022, 9:59 AM iJungleboy @.***> wrote:

This may seem odd, but we could really use convert-from-SVG support.

Two main reasons:

  1. In a CMS environment there are many cases where users just add images and it should "just work". ATM the CMS would have to detect an SVG and not resize, or alternately detect no SVG and add url-parameters for resize. This would reliably allow to crop the image to the proper size, which won't work in a page which expects the picture to have the right size, just to be surprised by an SVG which does its own thing.
  2. Many share-this-page scenarios require Open-Graph headers which always require jpg/png etc. Again in many scenarios the page should just take the primary image - which in a community / CMS setup can sometimes be a SVG - and then should be able to use that as well. But Open-Graph can't work with SVGs, so it would be a perfect fit to some-illustration.svg?format=jpg&width=200 etc.

— Reply to this email directly, view it on GitHub https://github.com/imazen/imageflow/issues/593, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2LH43DQBPE3NRL4H3QDTUUR2G7ANCNFSM5LKL74IA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

iJungleboy commented 2 years ago

So what I understand is that SVGs and PDFs can contain both very large amounts of complex data - causing performance problems, as well as inner workings (scripts and other features) which tend to be part of rendering libraries, resulting in security problems. Is this correct.

If yes, that's a very good point and makes sense, and from what I understand it probably won't be implemented inside ImageFlow because it too would need to use third party libraries, risking a big security footprint etc.

But it doesn't help yet :).

Do you have a suggestion how this could be automated? Possibly in "sandbox" or something? I envision something where the ImageFlow Server (proxied in .net or something) would determine it's an SVG, then have some code which a) checks if there is already a high-res pic available and if not, creates it, then b) would take this as the basis for any resizing.

lilith commented 2 years ago

That is exactly correct.

Docker has made sandboxing easier, but such a feature is going to always be difficult from an installation/configuration standpoint.

Imageflow doesn't have a plugin system, and that's by design. But I suppose it would be possible to send it a JSON configuration describing how to send a file to an external program and get the result.

So this problem would involve

There's also the alternative of making a server API for rasterization as a separate product and integrating over HTTP. This adds complexity, though, since HTTPS/TLS support is hard cross-platform (that's why Imageflow no longer supports URLs in jobs), and adds attack surface and doubles binary sizes.

iJungleboy commented 2 years ago

@lilith thanks for this

I guess I'm on my own then - will se how we can do / prioritize this. Many thanks for your inputs.