I’m glad they made that fail the prepare a print stage, otherwise you will have weird things happen.
Failing it faster would be nice, though.
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.
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.
There used to be a specific error message (we don’t support transforms) or something in the PRU days, so this seems a regression…
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.
There are more things in heaven and Earth and SVG, Horatio…
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.
That’s super-weird. But thanks for the info!
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.)
So, adobe speaks a different dialect of metadata?
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.
Yes rasterising the image should apply the transform and create a new image that doesn’t need transforming.
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="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
My brain hurts.
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.
Yeah, could be.
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.
This idea holds promise.