Preview SVG files

[Chris2011]

The PR will preview SVG files inside the IDE with MultiViewSupport

I already add actions that make sense to the SVGDataObject as for XML files like:

• View (Opens in browser)
• Check XML and Validate XML
• Reload Document (Disabled atm unfortunately)

I have 2 problems faced here:

1. I can't find an implementation for Reload Document. Adding the action to mf-layers.xml file isn't enough without having the cookie set in the class as you can see for View, CheckXML and ValidateXML.
2. I have problems showing embedded images with relative paths:

<svg xmlns="http://www.w3.org/2000/svg" width="300" height="200">
    <image href="icons/vue.png" x="10" y="10" height="180px" width="280px"/>
</svg>

For problem 1. reload document for XML files were implemented, when there was an assumption that some references can change and the IDE can't recognize them. I really don't know whether I need this action or still this action is relevant for SVG. If you have a hint please lemme know.

For problem 2. I didn't want to add custom logic but I need to think about to handle this. Also I don't know whether batik can handle external resources as relativ paths. I have another image with an base64 encoded image and this is working just fine, but not to load from the path. VS Code and the browser can handle it quite well.

I got the image from https://commons.wikimedia.org/wiki/File:SVG_Logo.svg it is CC-BY-SA-4.0 I used it, converted it to PNG and will now use Apache, is this correct?

Otherwise CC-BY-SA-4.0 is missing in nbbuild/licenses folder. Does that means, that Apache 2.0 is not compatible with CC-BA-SA-4.0 or just not up to date?

[mbien]

one thing to watch out for is that we might switch from batik to JSVG #7463 (comment) at some point

not sure if anyone has this on the radar atm but it would be good to keep batik specific usages low.

[Chris2011]

one thing to watch out for is that we might switch from batik to JSVG #7463 (comment) at some point

not sure if anyone has this on the radar atm but it would be good to keep batik specific usages low.

Thx for the hint, I didn't noticed that. When this happens, of course I'm willing to switch to this. For now I would stick with batik if this is ok.

[neilcsmith-net]

one thing to watch out for is that we might switch from batik to JSVG #7463 (comment) at some point
not sure if anyone has this on the radar atm but it would be good to keep batik specific usages low.

Thx for the hint, I didn't noticed that. When this happens, of course I'm willing to switch to this. For now I would stick with batik if this is ok.

IMO, the two things don't need to be related. Possibly switching to JSVG (or build time generation) for icons in the core platform doesn't necessarily mean we don't keep Batik around as an autoload library elsewhere in the IDE for other purposes. In line with that, I would look at adding the additional Batik libraries required for this separately in the ide cluster rather than platform cluster. The size of Batik already caused enough of a concern in #1278 - let's not add to that.

As and when anyone does make the icon loading use something else, all of the Batik libraries (along with a couple of dependencies that were previously moved), could move to the ide cluster?

I like the general idea of providing this support in the IDE incidentally.

cc/ @eirikbakke

[Chris2011]

@neilcsmith-net thx for the info. So as I understand it correctly, I should add those required libs to the XML module where I added the SVGDataObject, instead of the batik ant module, right?

[neilcsmith-net]

I'd consider adding a libs.batik module in the ide cluster that relies on libs.batik.read in the platform cluster. If we ever switch to something else for icons, all the external libraries could end up in the former. But let's see what @mbien or @eirikbakke or anyone else think on that approach before you put time into it!

[eirikbakke]

Thanks for this PR!

Possibly switching to JSVG (or build time generation) for icons in the core platform doesn't necessarily mean we don't keep Batik around as an autoload library elsewhere in the IDE for other purposes.

I agree with this. I think it's OK to rely on Batik for IDE features that actually relate to SVG files, like this one. Batik probably supports a larger part of the SVG spec than the lighter-weight alternatives.

Whereas for NetBeans icons, it could make sense to switch to a lighter library, which just needs to work for the particular SVG files that are used for NetBeans icons.

[mbien]

IMO: if batik is supposed to stay we shouldn't switch to JSVG. The main motivation there would be to reduce dependencies (and potentially also become more resource efficient due to the changed impl). If batik is already there anyway, adding another lib just for icons is making it worse not better.

In other words: replacing batik with jsvg would be something worth exploring IMO, maintaining a lib wrapper for jsvg additionally to batik should only be done if it is also demonstrated that there is a noteworthy memory and/or performance benefit in practice.

In reality you probably want to see how svgs look in a browser not in swing, having preview for it is more of a convenience thing. If it wouldn't support some SVG features it might be still ok? NB will never be inkscape ;)

[eirikbakke]

@mbien Good point, two libraries is kind of awkward...

In reality you probably want to see how svgs look in a browser not in swing, having preview for it is more of a convenience thing. If it wouldn't support some SVG features it might be still ok? NB will never be inkscape ;)

Probably true. (I don't know exactly what the limitations with jSVG are compared to Batik.)

[troizet]

In reality you probably want to see how svgs look in a browser not in swing, having preview for it is more of a convenience thing. If it wouldn't support some SVG features it might be still ok? NB will never be inkscape ;)

It would be really nice if there was an option to preview svg in the navigator, similar to other images:

[Chris2011]

@troizet good catch, will check this too.

[neilcsmith-net]

If batik is already there anyway, adding another lib just for icons is making it worse not better.

I think these are mostly unrelated concerns, and probably don't need to be discussed on this PR ...

maintaining a lib wrapper for jsvg additionally to batik should only be done if it is also demonstrated that there is a noteworthy memory and/or performance benefit in practice.

This is the only reason for switching for icons at all IMO. JSVG claims a ~98% less memory usage than Batik. We're not sure if this is true in practice or whether we have an issue as yet. If as more SVG icons are added we start to see startup time or memory concerns, then JSVG might be a way forward. As might be compile-time generation of bitmaps and/or Java classes. FlatLaf has icons that are Java coded mirrors of SVG, and use of Radiance's converter could also be a consideration.

Libraries to enable SVG previewing only need to be loaded if the user edits such a file. Therefore there are different considerations. Accuracy might trump overheads. If we did switch to JSVG for icons, and if we felt JSVG was good enough for previewing, that would be the time to consider whether we need one library or two. The key thing here, for me, is whether we want the feature?

At the moment, if we need to add additional Batik libraries purely for previewing SVG files, then I'd like to see them added separately (ie. in the IDE cluster) to the base library support for icons so we at least don't increase the weight of things in the base platform cluster.

[mbien]

@neilcsmith-net

I think these are mostly unrelated concerns, and probably don't need to be discussed on this PR ...

the reason why I brought this up at all is because thinking a bit ahead can sometimes save some work.

This is the only reason for switching for icons at all IMO. (...)

Having the option to trade ~17 jars against one sounds like a good trade all by itself (esp in context of how dependencies are managed in the NB build) - even if jSVG would make no measurable difference.

@eirikbakke

@mbien Good point, two libraries is kind of awkward...

yep. Adding a dependency with overlapping functionality of an existing dependency should have a higher barrier.

Probably true. (I don't know exactly what the limitations with jSVG are compared to Batik.)

same, I didn't take a look how JSVG compares to batik since I don't know batik very well, the readme of JSVG does list its supported and not supported features though. The failure mode would be also interesting since we could render a open-in-system button or something like that if it sees animation etc.

Overall I don't really mind adding more batik jars if it is well motivated. But if we are going to remove them two weeks from now again it would be kinda awkward.

[neilcsmith-net]

Having the option to trade ~17 jars against one sounds like a good trade all by itself (esp in context of how dependencies are managed in the NB build)

Sure, I made that point when it was introduced in the first place (and pretty much the same as above) - #1278 (comment) and #1278 (comment)

If number of jars is the primary concern here, let's just ship batik-all.jar! Anyway, a better development for icons might be batik at compile time, not run time.

EDIT: actually, the size differential of shipping batik-all over the subset is a lot lower than I thought (~400kb) - this might actually be a good idea. And I wonder what the overhead of using 17 files vs 1 is?

[eirikbakke]

I implemented the changes needed to switch ImageUtilities from Batik to JSVG in #7941 . I'll need to test it for a while to see that all icons appear correctly etc., including in my own NetBeans Platform app. (Out of time for today...)

[matthiasblaesing]

I think having SVG preview is great. It is stupid to carry an SVG rendering library (be it Batik or JSVG) and not integrate it to render SVG. Having rendering identical to browser will be hard, as it seems, SVG goes the same way as HTML (i.e. chaotic support and development), so a library not aiming for perfection, but pragmatic rendering might even be the best option.

The rendering issue of images can be explained as this

<svg xmlns="http://www.w3.org/2000/svg" width="300" height="200">
    <image href="icons/vue.png" x="10" y="10" height="180px" width="280px"/>
</svg>

is neither SVG 1.1 nor 1.2. Both require the reference to be xlink:href and that works beautifully. In fact inkscape writes that by default.

For the preview I think being able to scale would be good, as implemented in the ide/image module (Screenshot shows example image with toolbar):

In that module there is also an ImageNavigatorPanel and ImagePreviewPanel that could be an inspiration for SVG support.

I'm not sure, that I see the SVG support inside the XML module, it could also be in image or independent.

[Chris2011]

Yes, I thought about adding scaling stuff and some other stuff into it and I also want to implement this, but not for this MVP. But at the end, we can leave this open until I:

• Implemented preview for the navigator panel
• Implementing the other stuff for scaling
• Move this stuff to SVG or an own package

Thx for the hints all.

[matthiasblaesing]

This https://www.apache.org/legal/resolved.html#cc-sa indicates to me, that we should keep away from "CC-SA" licensed media. This might be an alternative (CC-0 licensed): https://www.svgrepo.com/svg/255830/svg. Alternatively, maybe @eirikbakke could be persuaded to draw an icon?

[eirikbakke]

@matthiasblaesing Sure, here's an icon you're free to use:

It's in the style of other NetBeans file type icons, which are generally of the form "tiny art inside a piece of paper with a folded corner". The "art" was drawn freehand as a hint to the SVG logo.

[matthiasblaesing]

@eirikbakke thank you!
@Chris2011 thats one problem solved ;-)

[Chris2011]

I dunno whether everyone knows that little indication so isn't it possible to put the whole SVG icon inside this "file" but that's not that important, I'm fine with everything which doesn't look like the XML icon :). @eirikbakke thx for the suggestion.

Also and out of curiosity, For me it looks like a bit of a mens genital. But maybe it is just my mind.

[eirikbakke]

Here's an alternative that alludes to a a line or bezier curve being edited.

[eirikbakke]

but it don't show me the icon. I have this problem, when the name is the same but I will investigate deeper. Maybe a problem with the new implementation from me?

Not sure; this seems like a layer registration problem rather than an SVG icon loading related problem. The icon shown in your screenshot is the general one for XML files, as you already noticed.

Just a question, I also use the zoomIn/zoomOut icon from org/netbeans/modules/image/zoomOut.gif. Is this correct or should I copy them over to the new svg module?

I'm not actually sure what the rules are for when a module can access the resource files from another module. I'd suspect you can reference existing icons in modules that your own module has a dependency on, so long as those icons are in a public package of the referenced module.

[Chris2011]

Not sure; this seems like a layer registration problem rather than an SVG icon loading related problem. The icon shown in your screenshot is the general one for XML files, as you already noticed.

No this was just the visual representation in my production IDE to show you that they have the same name.

This here is the result in the IDE with the new Module

[eirikbakke]

No this was just the visual representation in my production IDE to show you that they have the same name.

Oh, interesting! Maybe try with just the PNG file present first, and then see if the presence of the SVG file causes the icon to disappear somehow (if the latter, we can debug further).

[Chris2011]

Just the png was working, my feeling was/is the same name but lemme check this first.

[matthiasblaesing]

Ok, tested and works for me. I did this:

• check out this PR
• add is.eager=true to project.properties in svg module
• download the svg from Preview SVG files #7938 (comment) (icon provided by @eirikbakke )
• placed it in tree as ide/svg/src/org/netbeans/modules/svg/resources/svgLogo.svg (this screen is from the unpatched IDE):
  
• build from source
• opened the svg module in IDE started with ant tryme and got this (this image is from the patched IDE):
  

To verify that the SVG is actually used, I ran with debug activated and placed a conditional break point in platform/openide.util.ui/src/org/openide/util/ImageUtilities.java, line 737, breaking on the condition n.contains("svgLogo"). That was matched and the loader code ine line 755 produced an icon.

[Chris2011]

@matthiasblaesing thx for testing and I will check this out.

[Chris2011]

Ok so I did an ant clean on my local netbeans repo and I see the svg. Maybe it was a caching problem. I think I'm ready in a couple of days. Thx for your help :)

[matthiasblaesing]

Made a second pass and looks really nice. I left a few inline comments and I noticed, that svg is missing from the cluster.config.

[Chris2011]

Thx for the review, I also observed 2 things:

1. as @matthiasblaesing already mentioned, the navigation panel works after changing svg
2. the editor tab popup actions for just the preview has just two actions called editors and split. All others are available for source and history like Close, Close all, Close Others, etc.

If those should work for preview too and I would like to know, a hint would be nice. I tested it while pasting the actions registrations to the MultiViewElement but this didn't worked out.

[matthiasblaesing]

For problem 1, this is the solution in ide/image:

netbeans/ide/image/src/org/netbeans/modules/image/navigation/ImageNavigatorPanel.java

Lines 137 to 160 in 9d5bc1e

	WORKER.post(() -> {
	try {
	FileObject fileObject = dataObject.getPrimaryFile();
	if (fileObject == null) {
	return;
	}
	try (InputStream inputStream = fileObject.getInputStream()) {
	if (inputStream == null) {
	return;
	}
	if (panelUI == null) {
	getComponent();
	}
	try {
	BufferedImage image = ImageIO.read(inputStream);
	SwingUtilities.invokeLater(() -> panelUI.setImage(image));
	} catch (IllegalArgumentException iaex) {
	Logger.getLogger(ImageNavigatorPanel.class.getName()).info(NbBundle.getMessage(ImageNavigatorPanel.class, "ERR_IOFile"));
	}
	}
	} catch (IOException ex) {
	Logger.getLogger(ImageNavigatorPanel.class.getName()).info(NbBundle.getMessage(ImageNavigatorPanel.class, "ERR_IOFile"));
	}
	});

The problem is, that setNewContent and getComponent race. Normally the former wins and initial view does not happen, because you go out of the null check:

netbeans/ide/svg/src/org/netbeans/modules/svg/navigation/SvgNavigatorPanel.java

Lines 145 to 147 in 2e72095

	if (panelUI == null) {
	return;
	}

I noticed this only after I removed my breakpoints out of the raced path and only into the "it is broken" regions.

For the actions: I noticed that too in other contexts. You might want to have a look at the implementation of the "History" multiview element, as that is in a similar role, than preview (not an editor, but should do many thing similar to the companion multiview element).

[Chris2011]

Thx again will check.

[Chris2011]

For the actions: I noticed that too in other contexts. You might want to have a look at the implementation of the "History" multiview element, as that is in a similar role, than preview (not an editor, but should do many thing similar to the companion multiview element).

I just had a look into the MarkdownViewerElement, because there it is working and it was just this code:

@Override
public Action[] getActions() {
   return callback.createDefaultActions();
}

and also the code to set callback. FYI.