[MGNLDAM-497] Add SVG support Created: 05/Mar/14  Updated: 16/Feb/23  Resolved: 12/Mar/15

Status: Closed
Project: Magnolia DAM Module
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.0.8

Type: Improvement Priority: Neutral
Reporter: Richard Gange Assignee: Federico Grilli
Resolution: Duplicate Votes: 1
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File NoOpAssetRenderer.java     XML File config.modules.dam-app.config.editAssetAppConfigurations.svgUploadConfig.xml     XML File config.modules.dam.config.renderers.no-op.xml    
Issue Links:
causality
relation
is related to MGNLDAM-558 Prevent SVGs from being edited in Dam... Closed
is related to MGNLDAM-1114 SVG Dimensions Open
supersession
is superseded by MGNLDAM-555 Add asset renderer that does nothing ... Closed
is superseded by MGNLUI-3362 Add SVG support for thumbnail resources Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

When using SVG images in Magnolia exceptions are being thrown in the log and the image is not appearing on the page.

Steps to recreate this issue:
1. Add an SVG image to the dam
2. Add a text image component to a page
3. Use the uploaded image in the component
4. Save the dialog and observe the exception in the log



 Comments   
Comment by Magnolia International [ 13/Mar/14 ]

It'd be kinda silly to convert an SVG to a bitmap format though. It should be clearly determined if what we want to do is

  • ability to use SVG images (and let the browser "resize" it) in general
    • should such images go through the imaging module at all (i.e whose responsibility should it be to bypass operations - client code, or imaging code ?)
  • ability to use SVG as input and (apply operations such as resize, and others, and) convert to bitmap
Comment by Magnolia International [ 13/Mar/14 ]

After reading the linked support issue:

  • This is more of DAM issue than MGNLIMG's, really.
  • With DAM-2.0 (and perhaps even with 1.x, but I don't know the configuration details by heart), one would configure a different AssetRenderer for SVG's. One that would simply "do nothing", rather than pipe the asset through the imaging module.
Comment by Edgar Vonk [ 06/Aug/14 ]

Hi, we also run into the lack of proper SVG support in Magnolia 5. I will raise a separate support request issue just to keep track. What we want is to use SVG's as they are meant to (as is). Resizing in the browser. Vector graphics are completely different from normal images and Magnolia should not attempt to do anything with them (like image variations). Also editing of SVGs themselves should not be possible I guess.

Comment by Christian Ringele [ 06/Aug/14 ]

I linked to the support ticket SUPPORT-3857

In the support ticket Edgar and me discussed what should be expected when adding a SVG to DAM.
As it is a vector based image, as Gregory writes, image operations don't make sense.
We both think the best and cleanest solution would be:
When uploading a SVG image, the "Edit Image" option should disappear.
As image options make no sense on a SVG, this would directly solve the problem in a clean way.

The "biggest" problem, that should be solved, is the tons of exception thrown when choosing the Edit Image option.
Not providing the option will also solve this.

Comment by Magnolia International [ 06/Aug/14 ]

Again, this is a DAM or even STK issue rather than Imaging module, since we don't want these to go through Imaging in the first place.

Comment by Christian Ringele [ 06/Aug/14 ]

Again, why?
Have you looked at the linked support ticket?

What the issue tries to disciple is:
The dialog itself has problems handling the SVG image in the "Edit Image" function of the DamUploadField.
Or probably I miss understood it. At least thats the problem of the support issue:

  • Add an image to DAM of type SVG
  • Click on "Edit Image"
    Same problems as above described by Rich when clicking 'save' in the component dialog (also using the LinkField for DAM providing a preview and also the edit built in function).
Comment by Magnolia International [ 06/Aug/14 ]

There are several small issues:

  • rendering. Fix attached. One can configure a "NoOpRenderer" which simply does nothing with svg's. That might depend on the AssetProvider (*keep in mind one can configure renderers on providers as well), but it's probably a safe-enough default config to configure it with the attached bootstrap file.
  • the "details" view already works (surprisingly, actually, since it should go and display a thumbnail of the image, not the full binary, but apparently that's what it does)
  • not having an "edit" option in the details is configurable too - see config.modules.dam-app.config.editAssetAppConfigurations.svgUploadConfig.xml. It just needs to be before the other imageUploadConfig which catches all assets of type image/*.
  • the broken preview in tree view, i suspect should be fixed in the default image provider in ui
Comment by Edgar Vonk [ 13/Sep/14 ]

Hi Magnolia,

Is there a news on this issue? It seems to be quiet after Gregory's last update. Are the files attached to this issue a good temporary patch until the fix comes into the product in your opinion?

Comment by Federico Grilli [ 25/Feb/15 ]

For the release notes/docu:
This release introduces info.magnolia.dam.core.renderer.NoOpAssetRenderer,
an AssetRenderer which does nothing to the Asset (i.e returns an AssetRendition which just delegates to the original asset, but can configured to support only certain mimetypes. It can thus be configured to "bypass" other renderers for certain types. To that purpose it should always be the first one in the list of configured asset renderers at /modules/dam/config/renderers. By default it is configured at /modules/dam/config/renderers/noOpRenderer and will skip image/svg+xml mime type.

Comment by Federico Grilli [ 12/Mar/15 ]

The issue has been fixed as part of the BL-286 story for Dam 2.1/Magnolia 5.4 whose relevant tickets will be backported to 2.0.8

Comment by Espen Jervidalo [ 12/Mar/15 ]

Issue fixed by two linked tickets. Closing this one.

Generated at Mon Feb 12 05:00:25 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.