Add support for SVG image rendering

[fipro78]

Since the Eclipse 2025-06 (4.36) SWT supports rendering of SVGs.

https://eclipse.dev/eclipse/markdown/?f=news/4.36/platform.md

To use SVGs in your runtime, you need to add the new fragment org.eclipse.swt.svg and its dependency com.github.weisj.jsvg.

The NatTable GUIHelper needs to be extended to support the .svg file ending. And for SVG files, the resolution suffixes are not needed, as the scaling can be done directly on the SVG. There is no need for differently scaled images then.

It should be possible to introduce that change without updated dependencies. In case SVG support is not available in the JFace and SWT versions in the runtime, ImageDescriptor#getImageData() should return null, as the image data could not be created. In that case a fallback needs to be added, so that the existing PNG files are used.

Unfortunately the SVG support is not very fail safe. There are various errors that happen for different issues in the runtime.

• The fragment org.eclipse.swt.svg is missing in the runtime

  org.eclipse.swt.SWTException: Unsupported or unrecognized format [No SVG rasterizer found]
  

• The fragment org.eclipse.swt.svg is available but the required dependency com.github.weisj.jsvg is not available in the runtime

  java.util.ServiceConfigurationError: org.eclipse.swt.internal.image.SVGRasterizer: Provider org.eclipse.swt.svg.JSVGRasterizer could not be instantiated
  

  This happens on determining the FileFormat when the org.eclipse.swt.internal.image.SVGFileFormat class is loaded.
• The fragment org.eclipse.swt.svg is available but the required dependency com.github.weisj.jsvg is not available in the correct version
  • org.eclipse.swt.svg:3.130.0 requires com.github.weisj.jsvg:[1.7.0,2.0.0)
  • org.eclipse.swt.svg:3.131.0 requires com.github.weisj.jsvg:[2.0.0,3.0.0)
    If the combination does not match in the runtime, you will get the following error

    java.lang.NoSuchMethodError: 'com.github.weisj.jsvg.geometry.size.FloatSize com.github.weisj.jsvg.SVGDocument.size()'
    

From an OSGi perspective I am also missing the capability headers as described in OSGi Compendium - Service Loader Mediator, but maybe it is not necessary or useful in case of a fragment.

The above issues should only come up when setting up the runtime manually, e.g. if you create a plain SWT application or maybe a plain OSGi application using Bndtools. Although I haven't tested the later. But for plain SWT applications the above issues came up on testing.

You can of course argue that a developer that wants to load SVGs in the application needs to ensure that the runtime supports this, and the errors directly show the developer that something is missing. But as NatTable is a framework and developers might not really be aware of the SVG support, or do not even have it because they rely on an older Eclipse version, the SVG support needs to be guarded with a try {} catch (Error e) and a fallback to the default PNG/GIF images.

@HannesWell @HeikoKlare
I am not sure if you are aware of those issues and if this is a design by intention. I just wanted to note down my findings somewhere. From my perspective the above issues are a violation of the getImageData() contract, as it should return null in case the image data can not be loaded.

[HeikoKlare]

Thank you for sharing all these insights, @fipro78.

Let me try to answer at least some them.

• The fragment org.eclipse.swt.svg is available but the required dependency com.github.weisj.jsvg is not available in the runtime

  java.util.ServiceConfigurationError: org.eclipse.swt.internal.image.SVGRasterizer: Provider org.eclipse.swt.svg.JSVGRasterizer could not be instantiated
    
  This happens on determining the `FileFormat` when the `org.eclipse.swt.internal.image.SVGFileFormat` class is loaded.
  

This was recently fixed and is not happen in current I-Builds anymore:

• Throw ERROR_UNSUPPORTED_FORMAT when SVGRasterizer could not be loaded eclipse-platform/eclipse.platform.swt#2867

So with the 2026-03 release, you will not face that anymore.

The fragment org.eclipse.swt.svg is available but the required dependency com.github.weisj.jsvg is not available in the correct version

• org.eclipse.swt.svg:3.130.0 requires com.github.weisj.jsvg:[1.7.0,2.0.0)
• org.eclipse.swt.svg:3.131.0 requires com.github.weisj.jsvg:[2.0.0,3.0.0)

I am not sure if I fully understand that point. The org.eclipse.swt.svg fragment has proper version bounds for the JSVG dependency defined. If you do not have the correct matching version available, how can that be properly wired at all?

From an OSGi perspective I am also missing the capability headers as described in OSGi Compendium - Service Loader Mediator, but maybe it is not necessary or useful in case of a fragment.

We have defined a provided capability in the SVG fragment: https://github.com/eclipse-platform/eclipse.platform.swt/blob/9602bf011b2fbdef2868be4f306ca1438c94af57/bundles/org.eclipse.swt.svg/META-INF/MANIFEST.MF#L15
In all Platform bundles that make use of SVGs, we added an according required capability to ensure that some provider of the capability is present. Maybe that could have been done via serviceloader extender as well, but I am not sure if that would be better or worse in any way. I am even quite sure that we discussed about that back then and for some reason did not choose that approach.

It should be possible to introduce that change without updated dependencies. In case SVG support is not available in the JFace and SWT versions in the runtime, ImageDescriptor#getImageData() should return null, as the image data could not be created. In that case a fallback needs to be added, so that the existing PNG files are used.

If I understand this correctly, the abstract use case is to have SVGs and PNGs co-exist in a framework and chose SVGs if an according loader is present in the application running on that framework and to fall back to PNGs if it is not. Is that correct?
While we did not actively exclude that, I don't think we intended to support this. Since such an approach introduces additional complexity, complicates testing, and since we are not aware of any relevant drawbacks of using SVGs either (except for that you must have the SVG library present in your application), I am not sure if one should really follow that approach instead of just moving over to SVGs.

Regarding the contract of ImageDescriptor#getImageData(), you might be right. So maybe the behavior in case no SVG rasterizer is present should be the same as if no SVGFileFormat was present at all, such that the image is simply not loaded instead of having this new type of exception thrown. But with the argumentation given above, the question is whether trying to load an SVG with not SVG rasterizer being present is actually a relevant use case (or if it would be okay if one then needs to deal with that exception). I have no opinion on that right now.

[fipro78]

So with the 2026-03 release, you will not face that anymore.

That's great!

If you do not have the correct matching version available, how can that be properly wired at all?

You can use SWT also without OSGi. In that case you build your runtime yourself without tooling support. And then you can get into this situation. But probably it is good to see that error, as the developer tried to add svg support to the runtime, but it is not correct. So that is more an observation rather than asking to fix it.

We have defined a provided capability in the SVG fragment

I have seen it. But it is a custom capability, not the service loader defined ones. For example there is no requirement on the service loader itself. It works in eclipse as the service loader is already there. But building a new OSGi application for example with bndtools will probably miss the ServiceLoader requirement on resolve. In eclipse collections I added the ServiceLoader annotation to get the capability headers created.

I am not sure if one should really follow that approach instead of just moving over to SVGs

True if you only look forward. But NatTable is used in various setups. Some are on a current eclipse version, some are not. Some are based on eclipse rcp, some are plain swt applications. If I decide to move completely to svg support for the internal images (e.g. Checkboxes) then all projects that are not able to use the svg support for whatever reason will not be able to use the la tested nattable version. That might happen some time especially when the monitor specific scaling is supported. But now it would be a rather hard decision to drop the PNG support in favor of SVG.

About the contract. Well, while you can of course argue that a developer should know what he does, there are also legacy applications that rely on a contract. Guess an application like an image viewer where a user can select a file to load via file dialog. Before a user could select any file, and if it could not be loaded, the api returned null which is all the developer needed to take care of. Updating the platform is now changing this behavior and the application will crash if the user selects an svg file but the fragment is missing. While the exception is probably correct when using the ImageLoader it is not correct when using
ImageDescriptor#getImageData().

But thanks for the link of the PR to fix the service exception. Maybe I can adapt the solution to check if SVGs are supported and make the code simpler afterwards.

[HeikoKlare]

You can use SWT also without OSGi. In that case you build your runtime yourself without tooling support. And then you can get into this situation. But probably it is good to see that error, as the developer tried to add svg support to the runtime, but it is not correct. So that is more an observation rather than asking to fix it.

I understand the issue but to be honest I don't know how to better resolve the issue either. I don't think there is any good way for managing dependencies for the non-OSGi use case of SWT (in particular since SWT itself does not have any dependencies but just the new SVG fragment). So it's definitely nice to know that this can produce issues, but as you said, probably nothing we can or need do anything about now.

If I decide to move completely to svg support for the internal images (e.g. Checkboxes) then all projects that are not able to use the svg support for whatever reason will not be able to use the la tested nattable version.

I understand that. I think GEF Classic also has some workaround to support older Eclipse versions without SVG support. They have a central util to check for SVG support being present: https://github.com/eclipse-gef/gef-classic/blob/dc93d2538d8093997db8629f19ca94467afc18d2/org.eclipse.draw2d/src/org/eclipse/draw2d/internal/ImageUtils.java#L57
And then make all further image retrieval depend on whether SVG is supported or not (rather than wheter the specific file can be loaded in its SVG version or not).

Before a user could select any file, and if it could not be loaded, the api returned null which is all the developer needed to take care of. Updating the platform is now changing this behavior and the application will crash if the user selects an svg file but the fragment is missing. While the exception is probably correct when using the ImageLoader it is not correct when using
ImageDescriptor#getImageData().

From the FileFormat implementation I would have actually assumed that a similar exception would have been thrown when trying to load any other non-image file type (just like when trying to load an SVG file with no rasterizer being present). That does not seem to be the case, but unfortunately I had no time to debug the different behaviors so far.