Scientific E Notation Values in "SVG (for export)" Creates Unusable Files

[Matthew Schultz]

I use Affinity Designer to create files that I export – using "SVG (for export)" – for other apps, such as Cricut Design Space. 

The problem is that the Affinity Designer SVG export contains scientific e notation values like:

<g id="topback" transform="matrix(-1,-1.22465e-16,1.22465e-16,-1,854.039,695.404)">

that other apps, specifically Design Space, chokes on. Trying to import that object into DS results in unusable, malformed objects.

Sometimes I can "fix" it by editing the SVG file from the above, to:

 <g id="topback" transform="matrix(0,1,1,0,854.039,695.404)">

resetting the transform matrix, but it doesn't work for all objects, I haven't dug into how to map the space transforms properly, and I'm trying to avoid learning/doing that because this step is a huge pain.

Based on a bunch of SVG parsers, the files are technically valid, and Affinity can re-import the SVGs, but I need them to work with the other apps. But this issue doesn't happen all the time and I can't figure out exactly what causes it to occur in the first place. Nor can I figure out how to fix it. I've tried deleting the offending object and re-creating them, but the new objects are affected exactly as the one it's replacing

Any ideas would be very helpful. 

THANK YOU!

 

 

[Matthew Schultz]

I've narrowed it down to when I rotate objects in the document. The object starts out with this SVG code:

<g id="back" transform="matrix(1,0,0,1,28.2284,1525.81)">
      <g id="back-cut" transform="matrix(1,0,0,1,0,-1201.46)">
          <path id="back-cut-back" d="M235.281,479.74L626.461,479.74L626.461,423.05L583.941,380.53L277.801,380.53L235.281,423.05L235.281,479.74" style="fill:none;fill-rule:nonzero;stroke:rgb(212,26,90);stroke-width:2px;"/>
      </g>
      <g id="back-fold" transform="matrix(1,0,0,1,0,-1201.46)">
          <path id="back-fold-back-flap-1" d="M626.461,423.05L235.281,423.05" style="fill:none;fill-rule:nonzero;stroke:rgb(0,173,238);stroke-width:0.75px;"/>
      </g>
  </g>

 If I rotate it 180º (doesn't matter if it's clockwise or counter-clockwise), the SVG code results in:

    <g id="back" transform="matrix(-1,-1.22465e-16,1.22465e-16,-1,889.971,-16.8319)">
        <g id="back-cut" transform="matrix(1,0,0,1,0,-1201.46)">
            <path id="back-cut-back" d="M235.281,479.74L626.461,479.74L626.461,423.05L583.941,380.53L277.801,380.53L235.281,423.05L235.281,479.74" style="fill:none;fill-rule:nonzero;stroke:rgb(212,26,90);stroke-width:2px;"/>
        </g>
        <g id="back-fold" transform="matrix(1,0,0,1,0,-1201.46)">
            <path id="back-fold-back-flap-1" d="M626.461,423.05L235.281,423.05" style="fill:none;fill-rule:nonzero;stroke:rgb(0,173,238);stroke-width:0.75px;"/>
        </g>
    </g>

If I vertically flip the object, I get this:

  <g id="back" transform="matrix(1,0,0,-1,28.2284,-16.8319)">
      <g id="back-cut" transform="matrix(1,0,0,1,0,-1201.46)">
          <path id="back-cut-back" d="M235.281,479.74L626.461,479.74L626.461,423.05L583.941,380.53L277.801,380.53L235.281,423.05L235.281,479.74" style="fill:none;fill-rule:nonzero;stroke:rgb(212,26,90);stroke-width:2px;"/>
      </g>
      <g id="back-fold" transform="matrix(1,0,0,1,0,-1201.46)">
          <path id="back-fold-back-flap-1" d="M626.461,423.05L235.281,423.05" style="fill:none;fill-rule:nonzero;stroke:rgb(0,173,238);stroke-width:0.75px;"/>
      </g>
  </g>

Seems like Affinity is having math issues.

[Gear maker]

I do something like you do.  Except I wrote some C++ code to read the SVG file.  Any transform causes my code problems.  I'm too lazy to figure out how transforms work and add the code to handle the transforms.  Instead I have created a preset that just flattens all transforms.  Give this a try.

[Matthew Schultz]

WOW; THAT WORKED! THANK YOU @Gear maker !

I had been trying the "flattened" built-in preset which did NOT work, so didn't think to even look in "more" (which, imho should be named "Options…") to see if there were other options available.

You just saved me a ton of work!

🙌

[Gear maker]

You are welcome.  That's the great thing about this forum there's almost always somebody else that has had the same task and will share how they got around it.  The standard SVG (flatten) preset rasterizes everything and doesn't look like it flattens anything.  Unless their Flatten means to rasterize?  Good luck.  Happy New Year.

[Matthew Schultz]

Happy New Year to you too, @Gear maker !

[Jowday]

The bad thing is that without consulting this forum customers will be stuck again and again. Bad 1995 usability right there.

It is really a Linux like experience. Maybe Serif should make that Linux port. It would fit right in. 😄

[Matthew Schultz]

It's so true.

I abandoned the Adobe suite when they went to monthly pricing – What amateur/home/hobby user can afford it? Such a missed opportunity in the name of greed and profit – and I've been generally happy with the Affinity suite. Don't get me wrong, Adobe is in business to make a profit, but they abandoned a large part of their users to court the corporate dollar. #smh

But Affinity's apps are simply not as polished as the very mature Adobe apps. Little annoyances here and there (like mine, above) make the overall experience frustrating and time-zapping.

#sigh

[Gear maker]

22 hours ago, Matthew Schultz said:

The problem is that the Affinity Designer SVG export contains scientific e notation values like:

Matthew, fyi you had commented about the scientific notation.  I believe that is necessary because almost all numbers stored in the Affinity suite contain 15 places after the decimal point to maintain the accuracy needed to be able to zoom in over 2 million % and still be accurate.  Many programs might have been written so that they can zoom in maybe to 1000% or so.  Which means they may not have written to be able to handle such numbers.  They probably couldn't handle -0.000000000000000122465 any better than they could handle -1.22465e-16.  So the only way Affinity could dumb the SVG down would be to round off that number which would destroy the accuracy of the SVG file if it were input back into a program needing the accuracy.

And each of the 6 numbers in the matrix statement can be used for multiple things that interact.  That's why I gave up trying to write code to interpret it in my project as soon as I found I could get AD to do the work for me during the export.

[Matthew Schultz]

@Gear maker, oh, I get it, and I've come to rely on the app's accuracy as I use it for multiple things, including making 1/64" accurate templates for my woodworking.

In this instance it really was more about why, if I was rotating the object 180º, did it not result in a whole number? I'd totally understand if I was rotating it 179.092032º… okay. But I was rotating it 180º. And when I flipped it, the math seemed to make sense to my simplistic mind. So I guess I was expecting a whole number and not an exponent when I rotated it by a whole number.

Maybe I'm overthinking it. Wouldn't be the first time. 🙂

[Sean P]

Hi Matthew,

I'm glad Gear maker has given you a great workaround! I just wanted to let you know that this is something we're aware off and with development to be fixed so I will get your comments passed over to development.

Thanks again for letting us know.

[Matthew Schultz]

@Sean P,

Thank you and Happy New Year!

Matthew