Why does the SVG always come out bigger than it says it does?

[joseGaitan]

Whenever I export an SVG file it comes out a different size. Such as I when I first create the file it says I set the size to 1px by 1px. I create a circle and then when I export it to my web application the size is much bigger than it says it was. I have found that if I change the width and height properties on the SVG file itself it will shrink the SVG to my liking, but I would like it to do it when I export and not have to do it every time. If you need any more information from me please let me know.

[v_kyr]

Under the SVG export options (via the "More" button on it's export panel) uncheck the "Set viewbox" option and retry exporting as SVG.

Quote

Set viewBox—when selected, the exported file includes coordinates and dimensions which define the view box of the image. If this option is off, no view box data is included in the exported file. The export area is used to define the view box.

 

[Palatino]

[Jim Monson]

I have the same problem, i.e., there is always an empty background space around the SVG I am exporting. Unchecking the Setview Box and re-exporting (three times to be sure) did not change this. What am I missing? Below are the snaps of the four sides of my SVG after unchecking the Setview Box. This means that replacing an earlier SVG (with no surrounding space) places the new SVG in the wrong position, forcing me to repositions the x/y/w/h via Transform. What am I missing?

Snaps = left site / top side / right side / bottom side

[Dan C]

Hi Jim Monson

Sorry to hear you're having trouble. Could you please provide a copy of your Affinity document to the following link for me? What app are you using to reopen the exported SVG please?

https://www.dropbox.com/request/ZVZayxDSj3oAlHhfSwIt

[Jim Monson]

Thank you, Dan. FYI, this is part of a larger map which has a raster image as its base, on which I place all of my vector work (names, sites, routes, etc.). I work on an iMac Pro. Currently, I am upgrading certain road systems, and the one I am enclosing is the Moab-Edom system of local routes (in red).  Everything is now in AD but it was brought over to AD from my earlier Illustrator work which might be pertinent, although all my work is now done in AD. Here is how I work. Jim

1. My larger AD doc has multiple layers, sublayers and objects in it, but I have made a copy of this larger doc and deleted all but the Moab and Edom layers (Edom-Moab Local Roads-To AD.afdesign). This doc is attached below.

2. First I select the Moab-Edom layers in the above doc, copy it, use New From Clipboard to create its own doc and save it (Edom-Moab Local Roads-To AD.svg). This doc is also attached below. To be clear as to what I am doing, in my work flow I would have taken the x, y, w, h numbers of  these layers since later I use this svg and these numbers to import and position this svg in a new app I am creating. I had hoped that it would be positioned exactly in my app (which is the same exact size as the doc in #1 above).

3. If you bring up the Edom-Moab Local Roads-To AD.svg in AD, you will see a small empty area beyond the roads on each side of the svg (as I showed in my previous post). Obviously, this empty space forces me to adjust the positioning of the svg, a process I should not have to do if the actual routes were the limits of the svg.

Hope this help you isolate why this empty space appears in the svg.

PS: In order to isolate a possible Illustrator import issue, I just drew some original lines with arrows in my AD doc (below) and went through the same process as above (copy/New From Clipboard/save - and just for these arrows). The empty space is considerably larger in this svg (xxx.svg). Select the four line/arrow themselves in xxx.svg (using SHFT), and the extra space appears on its own (Screen Shot below). Another mystery. You can explore this with the AD doc. Thanks for any help you can offer. You folks are great!

Edom-Moab Local Roads-To AD.svg

Edom-Moab Local Roads-To AD.afdesign

xxx.svg

[Dan C]

Thanks for that Jim, the file and explanation is certainly helpful.

There are 2 issues at play here, one of which is a bug and the other to be expected.

The Moab-Edom layers all have a Mitre set at 15, which is causing the larger space around the curves when creating a new document from clipboard - if you select all of these curves and change the mitre from 15 to 1.5, then repeat the process you should find there is no additional space around the bounding box of the layer.

The arrow headed curves is a bug, as the app simply shouldn't be creating this large amount of blank space around the new file from clipboard. If you remove the arrow head you'll find the curves are clipped exactly to the new document or exported SVG. I'll be logging this with our developers to be investigated and hopefully fixed asap.

I hope this helps!

[Jim Monson]

Again, thanks, Dan. Here are a couple items.

1. MITRES - Yes. I had tried this but had only tried it at the layer level, which apparently does not effect the objects within. Your message encouraged me to return to this, and I found that I must select the objects within the layer(s) to change the mitre setting. When I changed the mitre of the objects, I could reduce it to 1, but not to zero as I had hoped. There is probably a reason for this.

2. CAP/JOIN/ALIGN - With my mitres set at 1, I then experimented with these settings and found that the settings circled in red in my first attachment (below) worked best, but even these settings left a tiny empty space, especially on the bottom and right of the svg. Thus I still had to slightly adjust the x, y, w, h of the placed svg that these settings rendered (always using by Copy/New From Clipboard method). You can see the different Transform  positions (below). I believe that this small difference came from the mitre setting that can only be reduced to 1 and not zero. It seems small but when placed on my detailed raster map, these small differences show up. Thus I tediously adjusted them so that the svg was correctly positioned. The difference between the source (original) object and the placed svg (target) is in the second attachment below.

3. MITRE to zero? - Is there a reason why the mitre setting could not be set to zero? The developers must have had a good reason to keep it at "1" but perhaps not. In the meantime, as you saw both my source and target docs are 5120 x 5120. As a work around I have drawn very thin 5120 x 5120 box in my source doc and included it when I Copy/New From Clipboard. This keeps the svg perfectly aligned in my target doc. I still wonder why the mitre can only be reduced to 1.

Again, many thanks!

Jim 

[Dan C]

On 10/2/2019 at 2:12 AM, Jim Monson said:

With my mitres set at 1, I then experimented with these settings and found that the settings circled in red in my first attachment (below) worked best, but even these settings left a tiny empty space, especially on the bottom and right of the svg.

As can be seen when the layer containing the strokes is selected, your strokes actually render slightly outside of the bounding box -

This is why when creating a new file from clipboard there is a slight 'space' around the bounding box of the layer.

On 10/2/2019 at 2:12 AM, Jim Monson said:

Is there a reason why the mitre setting could not be set to zero? 

Mitres simply can't be reduced below 1, AFAIK this is related to the radius of a circle and it isn't mathematically possible to reduce this below 1. Matt, one of our developers has expanded on this here - 

 

You can also find further info about this here - http://tutorials.jenkov.com/svg/stroke.html#stroke-miterlimit

Quote

The stroke-miterlimit actually sets the limit for the ratio between the miter length and stroke width. Thus, a stroke-miterlimit of 1.0 means that the miter length can be maximally 1 x stroke width. The miter is cut off beyond that. 1.0 is the smallest possible value for stroke-miterlimit.

I hope this clears things up!

[Jim Monson]

As usual, you folks at Affinity, come through quickly and clearly. Many thanks for all you do for us out here.