I guess that depends somewhat on whether they’re using a third-party library or rolled their own. In any case, there’s this one specific use case that comes up again and again, so it might be worth supporting it as a special case even if they don’t want to spend the time to implement arbitrary transforms.
I mean, if the software can’t fix it, maybe it could check for that sooner?
I might be misreading, but…
If it’s a problem with inconsistencies between SVG implementations, one approach to reign that in might be to… bypass the need for one by adding a “flip x” button in GFUI?
I mean, I had to exit the web editor and go back into Illustrator to break my file. Making it incompatible like that wasn’t an option in the editor, and I wouldn’t have done it if the editor hadn’t pushed me to do so by not having that function.
So.
Fine.
Let’s deal with what is.
I exit GFUI and go back to Illustrator. Can we address the problem at this phase?
To the point, is it possible to flip my image there without breaking the SVG, or taking a step further back into Photoshop? I’m looking for a “flatten images” command, probably on export.
Do we need an Illustrator plugin?
Are any of us skilled at building Illustrator plugins?
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()".
