There You Go Again - No SVG Loading - Only PDF


#21

here is a test file just made.
But like I said, even the ones already printed won’t re-load.
Only the ones already up in the UI.
test-2.zip (707 Bytes)


#22

2 weeks ago I had the same issue with AI files, though if I tried to load a second time, it always took them. What was once nearly perfect alignment was now way off. After every burn, the UI would refresh, so I could never good a good after shot. Lasted 2 days, then magically fixed itself (Ok, I know it was probably an update). STILL haven’t heard back from support on my ticket.


#23

i opened this file in Illustrator and exported an SVG from there and it opens in GFUI fine.

TestCopy


#24

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

Haven’t checked F360.


#25

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.


#26

@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.


#27

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.


#28

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


#29

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


Errors Loading files originating from CorelDraw and Affinity Designer [Resolved]
Unexpected Error issues
#30

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.


#31

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)


#32

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.


#33

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:


#34

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.


#35

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?


#36

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


#37

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:


#38

He has a point @jaz, also still no reference to an issue on
https://statuspage.glowforge.com/

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


#39

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).


#40

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.