There You Go Again - No SVG Loading - Only PDF

It’s not just AD. Corel files that used to work (saved as plain SVG) don’t work now either.

Haven’t checked F360.

It looks like the GFUI now rejects any SVG file that contains the style rule “fill-rule:evenodd”. Which includes every single SVG that Affinity Designer emits, as that’s set as the default fill rule in the style attribute on the top-level <svg> element.

File that fails:

<?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 1920 1152" 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;">
    <g transform="matrix(0.320693,0,0,0.4436,56.7828,28.8)">
        <rect x="122.289" y="151.488" width="299.352" height="216.411" style="fill:none;stroke:#000;stroke-width:1.74px;"/>
    </g>
</svg>

File that works (same as above, but with the “fill-rule” style removed.

<?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 1920 1152" 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="clip-rule:evenodd;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:1.5;">
    <g transform="matrix(0.320693,0,0,0.4436,56.7828,28.8)">
        <rect x="122.289" y="151.488" width="299.352" height="216.411" style="fill:none;stroke:#000;stroke-width:1.74px;"/>
    </g>
</svg>

Edit: See my more minimal test cases below for somewhat cleaner examples.

4 Likes

@Jules is examining a bunch of files.
Apparently Corel and other programs (even though have inches selected when saving) put the file in pixel format, which the UI is struggling with for some reason.
Add to the weird, even if file is brought into Inkscape and reproduced, the pixel thing continues.
If MADE in Inkscape, it registers correctly as mm or inches in file.

That’s not the problem. See the files I just uploaded. Both are in pixel dimensions (because Affinity Designer always saves SVG using pixel dimensions, no matter what) but the one containing “fill-rule: evenodd” fails whereas the one that doesn’t specify a fill-rule works. There’s no other difference between the two files.

3 Likes

Yep, wasn’t the pixels. About to go change that ticket.

Ok, I’ve made some minimal test cases.

This works:

<?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 100 100" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <rect x="25" y="25" width="50" height="50" style="fill:none;stroke:#000;stroke-width:1px;"/>
</svg>

minimal%20success

This fails:

<?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 100 100" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" style="fill-rule:evenodd">
  <rect x="25" y="25" width="50" height="50" style="fill:none;stroke:#000;stroke-width:1px;"/>
</svg>

minimal%20failure

2 Likes

Looks like this is it. I manually edited the Circle.svg posted above with a text editor and removed the “fill-rule:evenodd” reference, the file loaded without issue. Apparently opening the same file with Inkscape and editing/re-saving does not alter that part.

1 Like

Ok. We are getting nowhere.
Support needs to chime in here, since stuff was changed on their end not ours.
How about it @dan or @Rita or @jae or (your favorite staff name here)

4 Likes

Nor should it. Changing the fill rule can cause drastic changes in how the file should be rendered. Except on Glowforge, which has always ignored fill rules in the past, thus giving Corel and AD users lots of headaches when the GF fills in areas that should be empty.

The good thing is that maybe this means they are working on a solution to recognizing the fill-rule. The bad thing is it looks like it went onto the production server a tad early :hushed:

3 Likes

That’s what I’m thinking. Someone has some half-finished code for handling fill rules but they don’t want anyone actually running it yet so they put in some code to reject files that use it.

But that’s a horrible way to do development; hopefully it’s someone new who isn’t following protocol.

3 Likes

Thank you so much for letting us know about this. I’m so sorry you were having trouble uploading your designs.

Could you try again and let me know how it goes?

Rollback of code or whatever seemed to have worked.
SVG are loading again.
Thanks for the fix.

With all due respect, this is a non-answer. Is there anyway you can expand on whether the GF Cloud software changed and if it did, confirm that you’ve changed it again and expect it to fix the problem?

Once confirmed that it’s working again generally results in a “I’m going to close this now, let us know if it happens again” message. That doesn’t help any of the folks who just wasted cumulative days of time understand what happened or why or why it’s working again. That last part is key because it can prevent the lingering fear that it was some unknown gremlin that may pop its head up again leaving us doing the same thing all over again.

As my wife says, “I love you but not when you do things like this” :smile:

11 Likes

He has a point @jaz, also still no reference to an issue on

How is that possible? Do you only get Christmas bonus’ if no issues are reported?
Something broke. Something got fixed. This is an ‘issue’.

6 Likes

I do believe that is an automated monitoring tool that is simply looking to see if the services are responding to requests (which they were, the whole time - just not with the right responses).

5 Likes

I agree. I don’t bother going there - it seems to be just a heartbeat process ping result type of “status”. Not useful to determine if the app is working correctly and since that’s more likely to be the problem than a failure of AWS, the status page is of marginal use at best.

1 Like

Don’t tell that to the masses that requested it!

2 Likes

I think the masses were hoping for something that had real status updates provided by Glowforge’s DevOps/NetOps teams.

3 Likes

I kept getting that message all day yesterday. The only files I could upload must have been created in something other than what I use, since they were files I’d gotten through the forum. Thanks for the PDF trick - I didn’t even think of that yesterday. I thought the only format the GF would recognize was the SVG. I’m running the file now from the pdf - when it finishes, I’m going to try uploading again, since it seems that the issue might be resolved.