OpenBuilds / OpenBuilds-CAM

Online CNC CAM System
https://cam.openbuilds.com
GNU Affero General Public License v3.0
253 stars 617 forks source link

svg parser 90/96dpi #98

Closed petervanderwalt closed 4 months ago

petervanderwalt commented 4 months ago

Per forum user https://openbuilds.com/members/dwelch.210561/ Thread: https://openbuilds.com/threads/openbuilds-cam-svg-import-error.21542/

Copy pasted post:

New thread....straight to the point.

I had issues importing SVG files. The dimensions would be wrong. For example

Code:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
   width="612pt"
   height="792pt"
   viewBox="0 0 612 792"
   version="1.1"
   id="svg1"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg">
  <defs
     id="defs1" />
  <g
     id="surface1">
    <path
       style="fill:none;stroke-width:10;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;"
       d="M 0 0 L 720 0 L 720 720 L 0 720 Z M 0 0 "
       transform="matrix(0.1,0,0,-0.1,0,792)"
       id="path1" />
  </g>
</svg>

It detects the units from the height and width. Through discussion it defaults to 96dpi if it cant determine who created it. If you save out of inkscape with plain svg for example. If you save out as inkscape svg then openbuilds cam is happy, well okay I am happy as my 72 points becomes one inch. Instead of some other number.

Code:

   inkscape:version="1.3.2 (1:1.3.2+202311252150+091e20ef0f)"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"

Dont remember which but two of these three lines up front, at this time then take you down the path of success and the size of the path/box is 1 inch or 25.4 mm.

The bug I will call it is you instead get 25.4*0.9375 = 23.8125 mm instead.

If you change those to say mm instead of pt the tool recogizes the unts as mm now but still has this 0.9375 error it is converting millimeters to millimeters with a scaling of 0.9375.

Here is the issue. Not too far back sounds like inkscape changed from 90 to 96DPI and openbuilds cam did as well, but.....There appear to be a number of places that have the scaling.

90 / 25.4 = 3.543307087 96 / 25.4 = 3.779527559 and 90 / 96 = 0.9375

There is that percent error that affects these simple/plain svg files. (Inkscape or other generated).

You can grep for 3.543307 and find many hits. or grep for 'pt' or 'mm' and so on and run into a handful of places where code like this exists:

lw.svg-parser.js

Code:

                if (stringValue.indexOf('mm') !== -1) {
                    return floatValue * 3.5433070869;
                }

                if (stringValue.indexOf('cm') !== -1) {
                    return floatValue * 35.433070869;
                }

                if (stringValue.indexOf('in') !== -1) {
                    return floatValue * 90.0;
                }

                if (stringValue.indexOf('pt') !== -1) {
                    return floatValue * 1.25;
                }

                if (stringValue.indexOf('pc') !== -1) {
                    return floatValue * 15.0;
                }

If you go in and change the 1.25 to 1.3333333 for points.

Code:

                if (stringValue.indexOf('pt') !== -1) {
                    return floatValue * 1.25;
                }

Now when you import that file you get the correct 25.4 mm on a side as desired.

You can see the 90 in there for inches should be 96 and so on.

I did not find out when the other hits on this type of table are used, I just figured out the one that was affecting what I was trying to do.

petervanderwalt commented 4 months ago

Seems user's own ps2pdf > pdf2svg messes with native DPI and exports as 90dpi (industry standard is 96dpi) so no fix needed