Impossible to use SVG export for accurate mm-precision

[JensOlsson]

Hi

I am trying to export a drawing as SVG so that I can cut it in a cutting machine. And sometimes I want it to be placed on a printed circuit board. But anywhere I try to use SVGs exported from Affinity Designer 2, they appear with incorrect size.

Lets say I set the DPI in Affinity Designer 2 of my document to 72 dpi. I also set type to Print and Document Units to mm

I draw a circle of 60mm diameter. I then mark it and export 

I then try to export it as an svg

I exported circle.svg
circle.svg
 

Now if I import this in another app, it becomes too small, not at all 60x60mm. Why? I dont know, but looking into the exported svg source code I think I understand what happened.
 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" viewBox="0 0 172 172" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:1.5;">
    <circle cx="85.539" cy="85.539" r="85.039" style="fill:none;stroke:rgb(255,0,0);stroke-width:1px;"/>
</svg>

As you can see above, it uses 172 instead of 60mm and the viewport is set to 100%. 
Why is it not possible to export and svg with true mm or inches?

[NotMyFault]

What happens if you export "full document" instead of "selection only" ?

[Old Bruce]

18 hours ago, JensOlsson said:

Lets say I set the DPI in Affinity Designer 2 of my document to 72 dpi....

Let us say you set it to 96 dpi. Give it a try, the opening in "another app" may well be expecting a dpi of 96. Especially if the origins of "another app" is the Windows world.

[JensOlsson]

5 hours ago, Old Bruce said:

Let us say you set it to 96 dpi. Give it a try, the opening in "another app" may well be expecting a dpi of 96. Especially if the origins of "another app" is the Windows world.

Oh, it worked! Thanks @Old Bruce

But I am still curious. Would it not be very advantagous to have an option in the svg export to have dimensions defined in the unit set for the document?
So if my document is using mm or inches, mm or inches could be used in the SVG. Wouldn't that make the dpi setting unimportant?

Kind regards
Jens

[kenmcd]

8 hours ago, Old Bruce said:

Let us say you set it to 96 dpi. Give it a try, the opening in "another app" may well be expecting a dpi of 96. Especially if the origins of "another app" is the Windows world

Apple is the one responsible of the use of non-standard 96 dpi. CSS standards define it as 72 dpi. Other applications have unfortunately adopted it to be "compatible" with their BS. Causes problems with web fonts CSS sizing, and with SVG in OpenType fonts.

[Sean P]

Hi JensOlsson,

This is something we do have logged with development. I will get your comments passed over to development.

[N A]

On 12/18/2022 at 1:31 AM, kenmcd said:

Apple is the one responsible of the use of non-standard 96 dpi. CSS standards define it as 72 dpi. Other applications have unfortunately adopted it to be "compatible" with their BS. Causes problems with web fonts CSS sizing, and with SVG in OpenType fonts.

This is wrong - the CSS standard assumes 96 dpi (https://www.w3.org/TR/css-values-3/). It is extremely annoying that Adobe Illustrator sets all its exported SVG bounding boxes assuming an archaic 72 dpi, so when that SVG is imported to almost any other browser or application it appears at the wrong size. This is the main reason that my company moved to Designer, as the SVG scaling can be set to 96 and saved as a preset (Adobe refuses to do anything about this fundamental issue, even after years of knowing about the issue). However, we sadly discovered that Designer refuses to save SVGs with linked raster images (Illustrator can), and insists on embedding the raster data in the SVG, bloating it out. The only real answer is to use Inkscape, that gets everything right as it was designed to uphold the SVG standard, which follows CSS' 96 dpi.

[Idsky]

I'm disappointed in Designer 2 after buying it.  No physical size on SVG export is just 1 problem (if document units are mm, SVG export units should be mm).

I'll be using InkScape for SVG and DXF export.

Also frustrated that I cannot set dimensions of objects at more than 0.1mm accuracy.  Working at 600dpi, 0.1mm is 2.4 dots and accuracy is also lost in scaling things.
 

[Hangman]

1 hour ago, Idsky said:

Also frustrated that I cannot set dimensions of objects at more than 0.1mm accuracy.

If you change the number of decimal places in the User Interface Preferences, you can set this to six decimal places, i.e., 0.000001mm accuracy.

[Idsky]

18 hours ago, Hangman said:

If you change the number of decimal places in the User Interface Preferences, you can set this to six decimal places, i.e., 0.000001mm accuracy.

Ooh, nice, thanks, I missed that!  2dp mm will do nicely.  I had hunted for a way to set stroke to display as mm but didn't find that.  I know you can type "1mm" into the stroke but it always converts back to pt.  It will always be tough changing to a new app.  The pain of using Designer *and* InkScape still beats Illustrator cost!

[Hangman]

Yes, unticking Show lines in points will show the stroke in whichever unit you are using which is really helpful...

[NotMyFault]

If you are dealing with sub-millimeter precision requirements: 
please consider that Bézier curves are not exact. The ellipse shape used to create the circle uses only 4 nodes, and if you rotate a circle you will detect that it is about +/- 1/5000 off given radius at 17-45 degree.

To get a perfect circle, you need to use additional curve nodes:

 

[Grumbler]

Heyho,

I have a similar problem. I bought Affinity Designer to switch to a more professional tool from Inkscape. My normal workflow is to fit the document to the artwork elements to get precise measurements and borders. In Inkscape this works always perfectly with a very high precision. It seems Affinity Designer sets svg size or viewbox (whichever you choose during export) always to a rounded integer value.

Assume you create an artboard with a width of 222,1 mm and fit a rectangle precisely into the artboard which also has a width of 222,1 mm. Now export the document or artboard (doesn't matter) and you will see that the svg size (export without viewbox) or viebox (export with viewbox) has a width and height which is a rounded integer value but the rectangle has a precise non-rounded value.

If you now open the svg with another program e.g. Inkscape or Adobe Illustrator you will see that the document is larger than the rectangle (zoom into the right part of the rectangle).

If I do the same with Inkscape the svg size has the same non-rounded size as the rectangle and you won't see this issue.

Btw. PDF have the same issue!

In my opinion this is a bug in Affinity Designer!

Best regards,

Marcus

 

A rectangle:

 <rect x="-0" y="914.014" width="839.433" height="11.805" style="fill:rgb(96,67,148);"/>

Affinity Designer:

<svg width="100%" height="100%" viewBox="0 0 840 980"

Illustrator:

<svg id="Ebene_1" data-name="Ebene 1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 839.43 979.65">

Inkscape:

<svg width="839.433" height="979.654" version="1.1"

Edited February 16, 2023 by Grumbler

[Matthew Lyon]

I'm having similar problems – trying to export an SVG from Affinity Designer with precision millimeter measurements, and finding out both that the units are being converted based on some dpi thing, and the shapes have slightly-off dimensions. I've attached a simple example of the latter, the rectangle in the file should be the full width and height of the viewbox, but it is not. This behavior is forcing me to shift some work over to inkscape, which is terrible.

bizcard.afdesign bizcard.svg

Edited November 8, 2023 by Matthew Lyon

[Old Bruce]

22 hours ago, Matthew Lyon said:

trying to export an SVG from Affinity Designer with precision millimeter measurements,

The raison d'être behind the creation of the SVG file format was to be able to present Vectors on Web Pages. Hence the "dpi thing". As far as I can tell all monitors and screens are built with Dots per Inch (Pixels per Inch), resulting in unexpected / bad results when we design with metric for the units of measurement. Use Pixels or you may be able to work in some cases with Inches.

[Matthew Lyon]

And yet here we are in a world with things like laser cutters, programming tools that generate OpenGL code, and CAD programs that all take SVG files as input.

If you want unit confusion, try doing Printed Circuit Board design. Mixing and matching millimeters, metric & imperial SMT sizes, 1/10th inch THT sizes, and typesetting unit conventions is a *lot* of fun.

Regardless of what the intention of SVG was, like most successful technologies it's being used in ways it perhaps wasn't intended to be, and there are tools that require SVGs with widths/heights in mm. If I'm designing something for physical dimensions and the design has to accomodate things with mm dimensions, it's often easiest to just design in millimeters. The format allows for it and InkScape will accommodate the need.

Besides, with the advent of "retina"-grade monitors, even CSS isn't consistent about the dimensions of a pixel anymore.

Anyway, in the example exported file I attached, while the svg's attributes are

width="100%" height="100%" viewBox="0 0 208 333"

the rectangle, which takes up the full document size, the equivalent SVG element has

width="207.874" height="332.598"

so the resizing going on in the export is inconsistent in a way that makes it unsuitable for certain uses. I would expect this to output a width and height equivalent to the viewBox's dimensions. Again, this problem is not present in Inkscape.

I suppose I could output at a ridiculously high DPI (to avoid rounding errors) and write a script to reprocess the SVG file to have expected units, but I'm anymore I'm trying to avoid workflows that require one-off hacks.

Edited November 9, 2023 by Matthew Lyon
taking advantage of editor's code tags