fix for the ununiform margins while exporting

[intonarumori]

Things to consider:

• this fix changes the svg dimensions so probably breaks backward compatilibity
• this is the easiest fix for the problem

If you think about it if you have a rectangle that's not a square, if you extend it with the same margin in each direction the resulting rectangle will not be the same aspect ratio, so actually you cannot really solve this problem without changing svg size.

[skrat]

I wouldn't do this, SVG width/height attributes are now storing the bounding box of the graphic, and it's being used. Having the margin expressed in the viewbox attribute is the best we can do. It was originally introduced for the sole purpose of having some padding in the thumbnails generated out of these SVGs.

Please provide information on what you're trying to solve with this.

[intonarumori]

If you take a look at the current svg output you will see something like this: http://labs.rumori.hu/floorplanner/windowmargin.png

Lot of wasted space on the sides.

So actually margin will be just "random" depending on the aspect ratio of the content.

With the fix you will see this: http://labs.rumori.hu/floorplanner/window.png

I think this better represents what the parameter suggests.

[skrat]

This is doable by using different viewbox and leaving the bounds data in width/height.

[intonarumori]

For non square content it's not possible. Please see my first comment.

[skrat]

As said before, the width/height is being used to store real size of the graphic. So if you need margins, then you have to calculate the right viewbox.

[intonarumori]

Let's say you have a 100x50 content, and you want 10 pixel margin, please let me know how would you do uniform margin with a 100x50 svg size. You can't, so the problem is not solved with your suggestion.

You will end up with something like this: http://labs.rumori.hu/floorplanner/windowmargin.png

I'm open to other suggestions though, we can keep backward compatibility while introducing some other methods or parameters to get the preferred output.

Or I can go and post-process the SVG in my context, that's also possible.

In general though, I think the current margin implementation is a bit confusing. As you said it, it is for "having some padding". Where the actual value is dependent on the dimensions of the content. In most cases this just results in unnecessarily wide paddings. I don't think this is what we intended. It's not flexible, it's not exact, it's hard to work with.

[intonarumori]

As said before, the width/height is being used to store real size of the graphic.

I think this is just your assumption, neither necessary nor present in the SVG specification.