Hacker News Reader

Comment by jarek-foksa | Hacker News Reader

Implementation-wise, the only place where real world units such as "mm", "cm" or "px" make sense are the "width" and "height" properties of the outermost <svg> element.

This is because everything inside SVG document lives in an imaginary infinite world where dimensions and distances are expressed in abstract "user units".

You use "viewBox" attribute on the outermost <svg> element to specify a rectangular fragment of that world for the purpose of rendering. You use "width" and "height" properties to specify the real-world size of that fragment.

Authoring tools might show you dimensions of SVG objects such as rectangles or paths in real-world units computed from "viewBox", "width" and "height" of the outermost SVG element, but under the hood the size of those objects should be stored in user units.

View on HN

The issue is with translating "user units" to real world units. Up until now SVG is tricky as a CNC file format because of this little detail. For Inkscape you had to translate user units/px based on the assumption of 90dpi.

Not a big deal if you only use Inkscape. The real mess starts when going between different authoring apps. Then pretty soon a 100mm line in Inkscape turns into something longer or shorter. This is when you revert back to DXF, the bastard of all file formats.

I don't see how the viewBox's real world units can solve this. I think the geometries need to actually use real world units (which the SVG standard supports).

I don't understand how DPI is relevant here, if an authoring tool takes into account DPI when translating user units to viewport units then it's a bug in the authoring tool rather than limitation of the SVG format.

Not sure if this is what you meant, but some tiny rounding errors might occur during conversion if there are many transforms involved between the user space and the viewport space, but this can be avoided if user space values are stored with high enough precision.

In order to convert user units to viewport (physical) units and vice versa you only need the current transformation matrix, viewBox rect and viewport size. I have created a demo which shows how I can determine the line length in physical units: http://jsfiddle.net/9n5hf2jw/1/

The way how real world units are interpreted inside the SVG document is so messed up that even the SVG spec itself discourages their use:

Defining the size of a document in mm and then using mm units for shapes within it is going to give counterintuitive results, since they'll be converted to user units to resolve against the view box. (https://svgwg.org/svg2-draft/coords.html#Units)

Thanks for the jsfiddle. I think I understand what you mean. Cross-referencing this with how the new Inkscape saves files actually makes sense. By using width/height and viewBox you can define how user/px units are converted to physical units.

When I setup up Inkscape to use mm it does set with/height in mm and then the viewBox to the same dimensions (without units). This way it is implying the user/px units (e.g. all unitless dimensions in the file) are basically mm.

Previous versions of Inkscape would always safe in user/px units with an implied conversion of 90dpi, meaning a scaling factor of (25.4/90) to go from values in the file to mm. CorelDraw always uses 96dpi, Illustrator always 72dpi. I am not saying this makes sense. It's just how different authoring apps do it. If you want to use the file in a CNC machine you have to make sense of what the app meant when it uses unitless dimensions. When a file was edited with two different apps it very often is not possible to make a smart guess by some basic heuristics.

BTW: the CNC app I am working on is LasaurApp, part of an open source laser cutter called Lasersaur - http://lasersaur.com

Reply on news.ycombinator.com