Java SVG support

[Emux]

We have the issue 575 about adding support in Java for SVG resources.

I think it would be very usefull for all wishing to build / test their maps / themes with SVG resources easier in Java (along with mobile devices).

I have already explored an implementation via Apache Batik (Apache License 2.0).
It seems to handle the SVG well.

But I didn't pushed in the repository anything yet, because Batik is a bit large for the simple SVG rendering we want.

I have looked also JFreeSVG, it's small but GPL.

Another thought is if we can use AndroidSVG in Java too.

If anyone has considered another library with the proper license, let us know to examine it.

--
Emux
Cruiser - Atlas

[Emux]

After further search I integrated SVG Salamander (LGPL and BSD).

From my tests I have not seen any issues so far and if all go well I'll push it in dev later.

I'd prefer having only one SVG dependency, for Android + Java.
But we'll see how it goes.

[Ludwig]

SVG Salamander looks quite reasonable, if it delivers what it promises. 

+1

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/54E0EFF6.9020408%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Emux]

I pushed on dev an implementation for Java SVG support via SVG Salamander.

It's small and seems to handle the SVG spec well.

Further in the todo list, I don't know if we need to implement a memory cache for the rendered svg in Java too (as we have in Android).

[Emux]

Another option to consider (now that we can scale the theme images) is if we'll introduce also in Java a variable scale factor based on screen dpi.

We have lately more and more 3K or 4K resolutions with small inches and that could be useful.
Now we use always a fixed scale=1 in Java.

[Emux]

I published new Atlas Beta  (along with the rest bundle).

- It supports SVG graphics in render themes

- It includes the improved map symbols appearance (discussed here)

[Tobias]

Am Mittwoch, 18. Februar 2015 10:54:32 UTC+1 schrieb Emux:

I published new Atlas Beta  (along with the rest bundle).

- It supports SVG graphics in render themes
- It includes the improved map symbols appearance (discussed here)

Thanks for that, first tests look promising, SVG works as expected and symbols look much better.
Both features are great improvements for Atlas.

Best regards,
Tobias

[Emux]

Thanks for the feedback Tobias.

It's far easier to build / test maps and render themes on desktop than on a mobile device.

So it was needed in Mapsforge to have a complete SVG solution on both platforms.

[Maki]

I'm a bit late to the party, but still... thanks for this upgrade, it's really a quality jump. It really makes a difference being able to test on desktop.

At a first sight icons are perfect and my forest pattern with gradients, transparency and clones works well.

Maki

Il giorno giovedì 19 febbraio 2015 07:49:23 UTC+1, Emux ha scritto:

Thanks for the feedback Tobias.

It's far easier to build / test maps and render themes on desktop than on a mobile device.

So it was needed in Mapsforge to have a complete SVG solution on both platforms.

[Emux]

Thanks for the feedback Maki.

I was a bit late in implementation of both features.. keep pushing myself to free time to implement things in Mapsforge.. a neverending story :)

[Emux]

Maki I answer here your other post,

On 22/02/2015 02:34 μμ, Maki wrote:

Anyway I played a couple of days with SVG textures, some random facts and thoughts:

a) Salamander SVG is much more robust when it comes to SVG specs support. After successfully testing in Atlas beta I moved the theme to the phone and I had to redo some, even simple ones, patterns because they didn't render. I attach one sample. Couldn't Salamander be used in Android, too?

I tried first the opposite way, to use AndroidSVG in Java (but it uses Android specific code).

The same result is with SVG Salamander, it relies on Java classes that don't exist in Android.

I'm in favor too having only one SVG library and the most compatible one too, but it seems to not be that easy.

b) I have caching issues in Atlas beta. If I modify the SVG file, just reloading (F5) isn't enough, I have to quit and reopen the app. Changes in the XML are handled fine, however.

In Java (Atlas) we don't use SVG cache (probably not needed), so the live rendering is performed each time.
For that I find a bit strange what you mention, but I'll check it.

c) reloading the map from the "tools" menu usually works fine in Cruiser, but it happened once that I had to rename the SVG file, because no matter what I did (reloading, switching maps and/or theme) it didn't see the changes I made.

In Android (Cruiser) I clear all the caches (also SVG) with each map model change (open map / theme, reload etc).

Thanks for the feedback, we need to check those reports.

[Maki]

Il giorno domenica 22 febbraio 2015 16:12:17 UTC+1, Emux ha scritto:

I'm in favor too having only one SVG library and the most compatible one too, but it seems to not be that easy.

 I imagined that, but still wanted to ask. To me the point is mostly that SVG Salamander seems more robust.

b) I have caching issues in Atlas beta. If I modify the SVG file, just reloading (F5) isn't enough, I have to quit and reopen the app. Changes in the XML are handled fine, however.

In Java (Atlas) we don't use SVG cache (probably not needed), so the live rendering is performed each time.
For that I find a bit strange what you mention, but I'll check it.

c) reloading the map from the "tools" menu usually works fine in Cruiser, but it happened once that I had to rename the SVG file, because no matter what I did (reloading, switching maps and/or theme) it didn't see the changes I made.

In Android (Cruiser) I clear all the caches (also SVG) with each map model change (open map / theme, reload etc).

 

I wonder if there aren't file-system caches getting in the way sometimes. One common issue I have with the Galaxy Nexus is that when connecting to the PC via USB the file list I see is not up to date. For example Oruxmaps saves a gpx each time I record a track, but I don't see it on the PC (Solid Explorer shows it, tough). It's a common thing, there are a number of utilities to manually force a rescan of the SD. Eventually I've set up SD Rescan to automatically run when I connect the USB cable. But I really can't understand why such a thing can happen.

Maki

[Emux]

On 22/02/2015 10:11 μμ, Maki wrote:

b) I have caching issues in Atlas beta. If I modify the SVG file, just reloading (F5) isn't enough, I have to quit and reopen the app. Changes in the XML are handled fine, however.

Ok I can confirm that behavior Maki, thanks for catching it.

I'll look what can be done.
Probably we want something centrally in Mapsforge like on Android.

[Emux]

I published Atlas Beta 1.2.4
where I clear properly the SVG cache at map model changes (and reload).

FYI
SVG Salamander keeps the rendered SVG documents loaded in memory.
So it seems we have a Java SVG cache after all, that's good.
Of course it's automatically released on app restarts, but we need to clear it in all other cases.