opencloud-eu
[FR] SVG Preview
Initial Checklist
- [x] I understand this is a feature request and questions should be posted in the Community Discussions
- [x] I searched issues and couldn’t find anything (or linked relevant results below)
User Story
As a user, I want the Web UI to support rich previews of SVG files so that I can easily view diagrams and graphics directly into without downloading them.
User Value
- Quickly preview SVG diagrams directly in the browser
- Enhance overall usability for teams working with vector graphics
Acceptance Criteria
- Web UI shows an inline preview (thumbnail) of SVG files
- Clicking an SVG opens a full-size, zoomable preview viewer
Not MVP but ... to talk about
- Multipage SVGs (Inkscape format) are supported and can be navigated between pages within the preview
original Request
IT would be cool if the Web UI could show a preview of SVGs and when clicking also would show a fullsize Zoomable preview (for example great for diagrams that are svgs) Also would be important that for SVGs with a transparent background to have a toggle somehwer to set the background color for the preview, as dark on dark and light on light might be hard to read.
Also Inkscape supports Multipage SVGs - would be cool if that would be supported as well
Transferring to the opencloud repo, since support for different mime types on the preview endpoint / thumbnail service is a backend thing... although your additional ideas for svg won't work then. The preview endpoint returns JPEG content, always. Still, supporting SVG at all would be a start.
@rhafer do you know if we can just enable support for SVG in libvips? Documentation reads like SVGs have special handling in libvips, so it would be more effort. Correct?
The preview endpoint returns JPEG content, always. Still, supporting SVG at all would be a start.
Browsers support displaying SVGs natively, so wouldn't it be better to use this as an advantage and just include them with an img tag? a toggle for the background div having a specific color would also just be a simple thing in either js, or as a checkbox with a css rule on its state.
The preview endpoint returns JPEG content, always. Still, supporting SVG at all would be a start.
Browsers support displaying SVGs natively, so wouldn't it be better to use this as an advantage and just include them with an img tag? a toggle for the background div having a specific color would also just be a simple thing in either js, or as a checkbox with a css rule on its state.
"it depends" 😅 we use more or less the same logic in the file list for thumbnails / tiles view for tile previews. We can't render svg there, because svg files can be quite large. We must rely on small image sizes for the listings. That's why we need the thumbnail service in the backend anyway - and using the preview endpoint (with a larger resolution) for the preview app then requires no code changes at all in the preview app.
On top of that we could offer a functionality in the preview app to load image files directly instead of using a (larger) preview from the thumbnail service, but that's a completely different story. Could even be solved separately. Effort <-> user-value ratio is higher solving it in the backend, so with quite limited people and a full roadmap I'd start with the backend solution.
We can't render svg there, because svg files can be quite large Didnt think about that, after all, most of the time svgs are extremly small.
Effort <-> user-value ratio is higher solving it in the backend, so with quite limited people and a full roadmap I'd start with the backend solution.
Thats also a really good Point
@rhafer do you know if we can just enable support for SVG in libvips? Documentation reads like SVGs have special handling in libvips, so it would be more effort. Correct?
That depends on how the libvips used in our base images is built (it requires libvips to be linked against librsvg AFAICS). We'd need to check that.
But also SVG is one of those formats that can embed Javascript code (similar to PDF) a feature which opens a bit of a can of worms in terms of security. So we need to carefully consider if and how we want to enable that.
opens a bit of a can of worms in terms of security
Defnitly if implemented, should be Opt in. https://en.wikipedia.org/wiki/Secure_by_design
I personaly don't have any usecase for JS in SVGs or PDFs (only for CSS in SVGs -> prefered color scheme)
Though https://mujs.com/ and https://pkg.go.dev/cmd/cgo exist
though keeping this in mind:
Effort <-> user-value ratio is higher solving it in the backend, so with quite limited people and a full roadmap I'd start with the backend solution.
it might be better to leave embeded JS out for now, as it won't be something most people will need and it comes with a lot of effort to get right.
(maybe JS support is something for an extension/app)
