#420 Save View As SVG Incomplete

[John L. Poole]

I have a file with several layers: water, street, parcels, & buildings.

I click File->Save View As->Save View As SVG and save to test1.svg.
I then place [import] test1.svg into Adobe Illustrator.

Attached is a screenshot as it appears in OpenJump Version 1.9.1 release rev.4840 which I downloaded today, May 15th. Attached is the SVG file displayed in Adobe Illustrator. Notice that most of the street names are missing. Zooming in does not change anything when in Illustrator. I was viewing the SVGs in Firefox and MSIE, but thought perhaps those rendering engines had shortcomings, so I used Adobe Illustrator since it is an industry standard for graphics and the display is the same.

I tried searching for names of streets that do display in the SVG, e.g. "Madison" & "Main" and no results were found. I notice some :image/png;base64, compressed section at the end of the file constituting less than 5% based on the scroll bar position relative to the scroll window.

I can provide the SVG if you want.

[John L. Poole]

Here's the screen shot of the file displayed in OpenJump. I had tried to upload two files in my first posting, but I guess only 1 file at a time may be attached.

[John L. Poole]

Here's the SVG output: test1.svg

[michael michaud]

Hi John,

I could reproduce the problem, but it is quite difficult to solve.
The problem is that the computation of the svg graphics uses a different context than the one used for the screen display. There are two reasons for that :

• we use a different decimation parameter : to accelerate rendering, geometries are simplified when the map is displayed on screen, but we don't want to simplify them so much for svg, otherwise very bad-looking artefacts appear when one zoom on svg images.
• use of a special resolution parameter which main purpose is to ge the right scale when we import the svg image into a software like inkscape or when we print the svg image on a printer.

Even if I try to deactivate that, I don't get exactly the same labels :o(.
Currently, we set the decimation parameter to 0.001 pixel for svg instead of 0.5 for screen display : 0.5 is enough for screen display. 0.001 means that even if you zoom the svg x 1000, the geometry will still look like the original geometry (this is particularly important when you have two polygons sharing the an edge)
We also slightly scale the image down so that we get a resolution of 90 dpi (default resolution for svg). This scaling out is visible when you output a svg. Unfortunately, it decreases the chance to place labels :o(.
One (bad) solution to get more labels is to increase slightly the scale of your map before printing.
I am open to a better solution. If it helps, I can temporarily make a patch so that decimation and resolution parameters can be set from a system parameter so that you can test the effects.

[John L. Poole]

Thank you. You have piqued my interest and I'm looking into your code (Tortoise SVN shows 2.2GB + counting!) and trying to learn more about SVG rendering and your "decimation" parameter. I also thought I would see if I can compile your code.

[John L. Poole]

I'm just making notes here for posterity.

This looks to the reference point where you specify 0.001:
...\core\trunk\src\org\openjump\core\ui\plugin\file\SaveImageAsSVGPlugIn.java line 195:
new Java2DConverter(lvp.getViewport(), 0.001));

[michael michaud]

Maybe you downloaded the whole tree. What you really need is the trunk.
The class you are looking for is "org.openjump.core.ui.plugin.file.SaveImageAsSVGPlugIn" (lines 190-200)
Check our wiki
http://ojwiki.soldin.de/index.php?title=Main_Page
http://ojwiki.soldin.de/index.php?title=Downloading_OpenJUMP#Source_Code

[John L. Poole]

A breakthrough. I've been playing around with various setting, including the value at line 195. My findings are that the alteration of the "decimator" is not the direct problem. I had the setting on the style checkbox to "Hide overlapping labels." When I disengaged that feature, all the labels starting appearing in the exported SVG. I selected just the roads layer only to isolate what I thought was a problem with the label managment for a particular layer. This is encouraging... it it my belief that the "Hide overlapping labels" checkbox and its underlying algorithm is what is interfering with the export of the SVG and labels.

[ede]

sounds promising.. ede

On 23.05.2016 05:29, John L. Poole wrote:

A breakthrough. I've been playing around with various setting, including the value at line 195. My findings are that the alteration of the "decimator" is not the direct problem. I had the setting on the style to hide overlapping labels. When I disengaged that feature, all the labels starting appearing. I selected just the road only to isolate what I thought was a problem with the label managment for a particular layer. This is encouraging... it it my belief that the hide-label algorithm is what is interfering with the export of the SVG and labels.

---

[bugs:#420] https://sourceforge.net/p/jump-pilot/bugs/420/ Save View As SVG Incomplete

Status: open
Created: Mon May 16, 2016 01:04 AM UTC by John L. Poole
Last Updated: Mon May 16, 2016 01:26 PM UTC
Owner: nobody
Attachments:

• 2016-05-15 17_53_59-Adobe Illustrator CS4 - Untitled-1_ @ 66.67% (RGB_Preview).png https://sourceforge.net/p/jump-pilot/bugs/420/attachment/2016-05-15%2017_53_59-Adobe%20Illustrator%20CS4%20-%20Untitled-1_%20%40%2066.67%25%20%28RGB_Preview%29.png (599.8 kB; image/png)

I have a file with several layers: water, street, parcels, & buildings.

I click File->Save View As->Save View As SVG and save to test1.svg.
I then place [import] test1.svg into Adobe Illustrator.

Attached is a screenshot as it appears in OpenJump Version 1.9.1 release rev.4840 which I downloaded today, May 15th. Attached is the SVG file displayed in Adobe Illustrator. Notice that most of the street names are missing. Zooming in does not change anything when in Illustrator. I was viewing the SVGs in Firefox and MSIE, but thought perhaps those rendering engines had shortcomings, so I used Adobe Illustrator since it is an industry standard for graphics and the display is the same.

I tried searching for names of streets that do display in the SVG, e.g. "Madison" & "Main" and no results were found. I notice some :image/png;base64, compressed section at the end of the file constituting less than 5% based on the scroll bar position relative to the scroll window.

I can provide the SVG if you want.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jump-pilot/bugs/420/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[michael michaud]

Hi John,

I think you're right about the hideOverlappingLabels option.
I mean, I already supposed that the problem was related to this option, but only because while changing the resolution, the ratio between feature sizes and font size changes, hence the number of overlapping labels.
In my last test, I removed the resolution change and noted that during svg export, there are much more conflicts detected than during screen display. I have no idea why the label placement algorithm detects extra conflicts during svg export. It will need more investigation.

[ede]

On 23.06.2016 08:16, michael michaud wrote:

I tried to scale it for Inkscape, but I think that Drawing (LibreOffice) uses another resolution (maybe 72 insteadof 90) and I'm not sure exporting inkscape into pdf preserve the scale

should this maybe made configurable in the dialog?

..ede

[michael michaud]

Should be fixed in r4940. It is difficult to scale the svg in a way that fits all needs though. I tried to scale it for Inkscape, but I think that Drawing (LibreOffice) uses another resolution (maybe 72 insteadof 90) and I'm not sure exporting inkscape into pdf preserve the scale.
Please, check that it solve the labelling problem and report your experience about scale.

[John L. Poole]

I'll try r49040. I started to investigate this and got sucked into a rabbit hole concerning the topic of affine transforms or something quite complex in mathematics which has now faded in my memory. I remember concluding this was a rich area in need of further research, documentation and time.

Thank you for keeping the fire going on this issue.

[John L. Poole]

There's improvement. I modified as follows (below does not reflect all of my modificatins, but only changes as are pertinent to the test of dpi changes:

  ScreenScale.setResolution(72); // 5/22/2016 7:55 jlpoole modification
  ZoomToScalePlugIn zoomToScalePlugIn = new ZoomToScalePlugIn();
  zoomToScalePlugIn.setScale(scale);
  zoomToScalePlugIn.zoomToNewScale(context);
  //svgGenerator.scale(0.746, 0.746); // rapport pour LibreOffice (0.72/0.96) r.49040
  //svgGenerator.scale(0.90/0.96, 0.90/0.96); // rapport pour Inkscape        r.49040
  svgGenerator.scale(0.72/0.96, 0.72/0.96);

And the result was many of the street names disappeared. When I used your setting of .90, much more appeared. However, there was not a match to what appears in the screen. It looks like this is a hit-and-miss approach finding various resolution settings that work. I'd still like to spend the time (probably 4-20 hours) to really understand the relationship among the variables.

[michael michaud]

Hi John,
The problem seems to be solved for me. Can you confirm ?

[John L. Poole]

Hi Michael,

Can you provide the name/ID of build you are using so I may download the same build to test?

[michael michaud]

Hi sorry for the delay,
I think the problem is solved in recent builds (NB of september, october...). Not sure you get exactly the same thing in SVG and on the screen in all situations, but compared to the initial situation I would tend to consider the problem is solved.
Let me know if you still observe big differences between what you see on screen and in svg output.