I agree, and I think (hope) they will get there. The software is still in beta, so things are still changing. I’m just glad they added that check. I was freaking out that my Glowforge was broken when the issue happened to me. One thing that would be really nice is if they at least say if it failed because of a file issue or server issue.
That would be nice, but it won’t help much when making designs. At least, not until they add the ability to save changes to a design in the GFUI.
I’m not sure about illustrator, but in Inkscape you can “Make a bitmap copy” under the edit menu. I haven’t tried this yet, but I think it should work.
That’s the part I’m not getting with this issue… Isn’t it already transformed by the time it gets to the GFUI? Or is the language to transform it built into the SVG instead? (The latter would be weird to me.)
I was replying to “how hard is it to apply a transform to a bitmap”, and what I meant was simply that the difficulty of implementing support for SVG transforms on bitmaps is a bit of an unknown since we don’t know the how the code is structured. If they’re using some open-source library, it might even be possible for one of us to contribute a fix.
This has been requested many many times. It usually gets derailed by an argument about the nature of the Glowforge software.
EDIT: This is the official recommendation from Glowforge. I think I’m allowed to state an opinion if it’s clearly labeled as such, so in my non-factual opinion, method number 1 in the official advice is batsh*t crazy. #2 only addresses Inkscape, so I’ll mention that there’s an equivalent in Illustrator.
My understanding is the SVG says here an image that has this transform. It is up to the reader of the SVG to apply the specified transform to the image.
It is a bit odd for a flip but if it allows arbitrary rotations then it is really the only way. For example if you want your image rotated 45 degrees it becomes a diamond shape. Bitmaps are always rectangular so there is no way to store the rotated image as a bitmap unless you expand it 40% in each axis and add transparency. You have to read a rectangular bitmap and rotate it. GF don’t seem to be able to do that for some reason.
Based purely on emotion and no practical knowledge, I have to say I agree with your subjective opinion.
(Good lord. I read that whole page a dozen times this week, and thought I’d tried everything on it. Missed the whole section on flipped images somehow.)
I’ll try re-rasterizing next time. Didn’t know that was an option.
(Illustrator has a bunch of “that won’t do anything, but I’m not gonna stop you” operations, and this looked to be one of those. Like, it’s not greyed out, 'cause it’ll work with some objects. Just not the one I have selected. But, similar ones.)
Transform is part of the SVG standard that GF havn’t implemented. https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/transform. It isn’t metadata or anything Adobe specific. Same as the fillrule attribute that they ignore. They only have a partial SVG reader implementation.
So does rastering the image in Illustrator fix the issue, in that the transform would be executed in Illustrator, so the exported bitmap would be untransformed?
It sure would be nice if the error message communicated what the error was, so that you’d have a clue about how to fix it. I spent a day trying to get an image to print that has been mysteriously failing, and I think this error was the cause. Not being able to print a mirrored image (i.e. to engrave onto the back of translucent acrylic) is pretty odd.
The plot is quite thick, as it turns out. I’ve been experimenting to try to find what is and isn’t supported, and some things are quite baffling. I started with a simple SVG:
Then I tried adding various transform attributes to it.
transform="scale(0.5)" works
transform="translate(50 50)" works
transform="rotate(-45)" works (!)
transform="rotate(-180)" fails (?!)
transform="skewX(45)" works (seriously!)
transform="translate(50 50) rotate(-45) skewX(45) scale(0.5)" also works
transform="matrix(-1, 0, 0, 1, 72, 0)" fails
transform="matrix(0.5 0 0 0.5 0 0)" (equivalent of scale(0.5)) works (!!)
When I say works or fails, by the way, I mean at the printing stage. All of these load successfully into the GFUI, and after you click print it does the scanning thing for a while, goes to “Preparing your design”, and only then does it spit out an error, if it’s going to.
Just for fun, I applied the “fails” transforms to a simple vector rectangle, and they all worked, including the matrix flip.
So what is unsupported seems to be specific to images, and specific to some deeper aspect of the transform, not simply "we don’t reject matrix()".
Very impressive research. Makes me wonder what SVG library they’re using. If it’s open source, and we can figure out some bugs and contribute the fixes to the project, our Glowforge’s get better!
I’m thinking it’s custom. Based on it failing at the preparing stage, the is presumably the cloud motion planning SVG-to-waveforms code, unfortunately, which would be secret sauce.
The long version of my post, which I actually did write a mountain of text on, also confirmed that the transformation issues weren’t triggered by vector shapes.
(The file that was failing had an engrave pass and a cut pass. Both had been grouped together in Illustrator, and transformed together, so those instructions were present. Disabling the engrave pass made it acceptable. Disabling the cut pass did nothing.)
Anyway, this research does help a lot.
I should be able to throw a quick “flip SVG in x” app together in Processing, which applies one of the transformations we know will get the job done.
That’d be less overhead than loading up Illustrator, and less obtrusive than going all the way back to Photoshop and having to re-assemble layers in Illustrator.
Thanks for the discussion, all! I’m sorry for any inconvenience. As @chris1 pointed out, there’s an issue with our software in handling images that include flipped bitmaps and it looks like that what’s happening here. We will be making improvements in this area.
