CoreSVG has logged an error. Set environment variabe "CORESVG_VERBOSE" to learn more.

[Phillipus]

(Moved from eclipse-platform/eclipse.platform.swt#2848)

• macOS 15.7.2
• RCP app targetting Eclipse SDK 4.38.0.I20251201-0920
• Temurin-21.0.9+10 JDK

I'm testing my RCP app using the the above config, launching, debugging etc. Sometimes when quitting the RCP app I occasionally see this message written to Eclipse's console:

CoreSVG has logged an error. Set environment variabe "CORESVG_VERBOSE" to learn more.

There is nothing written to the error log.

I guess this is nothing serious but thought I'd open this issue in case it is an indicator of something else. I can't reproduce it with known actions.

Found one instance of this message here.

Next step is to set CORESVG_VERBOSE to 1 and see if I can get the message again...

[Phillipus]

Next step is to set CORESVG_VERBOSE to 1 and see if I can get the message again...

The message is:

Failed to parse href for node name "svg"

[HeikoKlare]

Have you found a reproducible way to get this message, @Phillipus? I have seen it once in a while but not in the recent past.

I am a bit confused where MacOS' CoreSVG is used at all, as for the SVG support added to SWT the JSVG library is used, which, to the best of my knowledge, does not utilize any OS capabilities. And while we use native image loading on Windows if possible, I don't see anything similar in the Image implementation for MacOS. So this seems to be coming from somwhere else.

What I at least accidentally found with your latest message (searching for " href" in *.svg files of the SDK) is this improper SVG file: https://github.com/eclipse-platform/eclipse.platform/blob/master/debug/org.eclipse.debug.ui/icons/full/obj16/brkp_grp4.svg
It is composed of 3 BASE64-encoded PNGs, which is not how SVGs should be defined. There are already other images with similar content which can be adapted to replace those embedded PNGs, so I plan to propose a PR soon that improves that SVG. Unfortunatley, I don't think that's related to this issue as the href is not inside an svg node, but at least it's a side finding.

[laeubi]

@HeikoKlare I recently tried the SVG support in one of my products / setups as well and found that sometimes it seem to fall back to the native SVG support (because GTK and maybe also cocoa) already support SVG rendering on the OS level.

It is composed of 3 BASE64-encoded PNGs, which is not how SVGs should be defined.

While its maybe not intentional, this is perfectly valid SVG and how it is supposed to work to add embedded raster graphics see for example here:

https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorials/SVG_from_scratch/Other_content_in_SVG

[Phillipus]

Have you found a reproducible way to get this message, @Phillipus? I have seen it once in a while but not in the recent past.

No, it's random. Because the message is written to Eclipse's console I only see it when testing/running my RCP app (when the console is open). The message never occurs while running the app, only immediately after it's closed (or perhaps while it's closing).

I am a bit confused where MacOS' CoreSVG is used at all

So am I.

as for the SVG support added to SWT the JSVG library is used, which, to the best of my knowledge, does not utilize any OS capabilities.

Agreed. I looked at the source for JSVG and concur.

What I at least accidentally found with your latest message (searching for " href" in *.svg files of the SDK)...

The message is Failed to parse href for node name "svg" so I guess the problem is with a href attribute on the root svg tag.

If you Google the message (or ask an AI agent about it) it's coming from Apple's CoreSVG private framework and not just from Eclipse.

I wonder if the JVM is using it?

[HeikoKlare]

I recently tried the SVG support in one of my products / setups as well and found that sometimes it seem to fall back to the native SVG support (because GTK and maybe also cocoa) already support SVG rendering on the OS level.

That's interesting. I know that GTK uses an image-loading implementation that accesses native capabilities (in NativeImageLoader, if I am not mistaken) but I did not find anything similar on MacOS. All image loading seems to go to FileFormat and use the according SVGFileFormat that employs the JSVG loader. Do you have any reference where native SVG support on MacOS is adopted in SWT?

While its maybe not intentional, this is perfectly valid SVG and how it is supposed to work to add embedded raster graphics see for example here:

Sorry for being imprecise here. That's of course valid SVG, but it contradicts the purpose of getting sharp rendering results for any size. If you only have a raster graphics that cannot properly be vectorized, it of course makes sense to embed it like that. But here it's not the case as similar images exist as SVGs for which only some colors need to be adapted:

[laeubi]

Do you have any reference where native SVG support on MacOS is adopted in SWT?

I not even have access to a mac anywhere... so just a guess how such message would surface to an SWT application. It should be quite easy to test by creating a plain SWT snippet that loads a SVG and then make sure jsvg is not on the classpath.

That's of course valid SVG, but it contradicts the purpose of getting sharp rendering results for any size

That's for sure, I just mentioned this in one PR already in the past but it seems not everyone is looking at the actual SVG content very often :-)

[HeikoKlare]

so just a guess how such message would surface to an SWT application. It should be quite easy to test by creating a plain SWT snippet that loads a SVG and then make sure jsvg is not on the classpath.

As expected, this is the result when removing the SVG fragment (and JSVG) from the classpath and trying to create an image with an *.svg path:

Exception in thread "main" org.eclipse.swt.SWTException: Unsupported or unrecognized format [No SVG rasterizer found]
	at org.eclipse.swt.SWT.error(SWT.java:4950)
	at org.eclipse.swt.internal.image.SVGFileFormat.loadFromByteStream(SVGFileFormat.java:49)
	at org.eclipse.swt.internal.image.FileFormat.loadFromStream(FileFormat.java:121)
	at org.eclipse.swt.internal.image.FileFormat.load(FileFormat.java:157)
	at org.eclipse.swt.internal.NativeImageLoader.load(NativeImageLoader.java:26)
	at org.eclipse.swt.graphics.ImageLoader.loadByZoom(ImageLoader.java:161)
	at org.eclipse.swt.graphics.ImageLoader.loadByZoom(ImageLoader.java:205)
	at org.eclipse.swt.graphics.ImageDataLoader.loadByZoom(ImageDataLoader.java:63)
	at org.eclipse.swt.graphics.Image.lambda$3(Image.java:746)
	at org.eclipse.swt.graphics.Image.initWithSupplier(Image.java:1495)
	at org.eclipse.swt.graphics.Image.<init>(Image.java:745)
	at org.eclipse.swt.snippets.Snippet1.main(Snippet1.java:29)

As said, I have not found any code in the Image and NativeImageLoader implementation for MacOS that utilize OS functionality so far, but only FileFormat and subclasses for loading the according image formats. So I am not sure if this is related to any SWT-loaded images at all.
Maybe it something completely different, e.g.:

I wonder if the JVM is using it?

[Phillipus]

Maybe it something completely different

Browser component?

[HeikoKlare]

Browser component?

Likely option, yes. I also read that one particular consumer of CoreSVG is WebKit. I have opened an SVG inside an Eclipse SDK (which does it in the embedded browser), but did not get the error on application shutdown. Maybe it's up to which SVG is opened in a browser. Could be related to the Welcome view, Java element infos or the like, which use the browser and rely on SVGs.

[laeubi]

Maybe from a javadoc somehow (that also uses the browser component).

[Phillipus]

In my RCP app we only use the Browser component for a dedicated View. I got the error message when that was not active.

[Phillipus]

Found it.

It's an additional namespace declaration in some of the SVG files in Platform.

Run the following (on Mac) but set the environment variable CORESVG_VERBOSE=1 first either in the run config or export CORESVG_VERBOSE=1

import org.eclipse.jface.resource.ImageDescriptor;

public class SVGImageLoader {
    public static void main(String[] args) {
        ImageDescriptor id = ImageDescriptor.createFromFile(SVGImageLoader.class, "exportpref_wiz.svg");
        id.createImage();
    }
}

Add this SVG image alongside the above code: (Save As "exportpref_wiz.svg")

Open that SVG file in a text editor and note the namespace declarations:

<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

It's this extra line:

xmlns:svg="http://www.w3.org/2000/svg"

As the namespace is already declared as xmlns="http://www.w3.org/2000/svg that one should not be there.

Remove that line and run the snippet again. No error message.

(The error only occurs with ImageDescriptor)

[HeikoKlare]

That's an interesting finding. The xmlns:svg namespace seems to be declared in every SVG file we have in Platform (in addition to the same being assigned to the general xmlns):