Our advice remains to use Illustrator’s “Save As” feature exclusively for preparing images. You’re welcome to use other approaches. Should you find a bug, we’ll ask you to see if the bug exists when using the Save As approach. (As with any advice, it’s possible we’ll change this at some point in the future).
Until GF comes out and says “sorry, we were wrong, don’t use the Save As method as we previously told you to, use Export instead despite having also told you before that you shouldn’t use Export”, theirs is the authoritative comment on the subject. This is the objective reality that matters - there are no alternative facts in play. Just who to believe, the authors or the observer.
EDIT: Looks like Dan weighed in with some additional authoritative support
Chris a long way back I had a job that failed to render correctly, and ultimately it was discovered that it was because I had used export rather than save as. Once I switched it worked fine, and we were told to use save as by support… there was a lengthy discussion in early pru days about the differences and why save as was the right thing to use. And every ai project since on Prus has used save as…
This is the kind of stuff that we really need a wiki to document.
Dan has mentioned several times in the past not to use the export command as it introduces issues, try searching “Illustrator” and “Save As” or “Export”
Might want to check the location of that link.
He said it again tonight in response to Chris’s admonition not to use Save As. Said you can do whatever you want but if you have a problem Support may ask you to try again using Save As.
I understand. I am referring to the location of the link.
simmah-dah-nah I edited the post
here is the post:
In my opinion, thank you both for the additional data point. In my opinion, this appears to be the same issue as jbpa had. In my opinion, re-exporting this with the version of Illustrator I have installed produces a working file. In my opinion, I have learned a valuable lesson from this whole experience and in my opinion it would be better for me to not offer advice and assistance going forward. I enjoyed my brief time on the forum and I wish you all the best.
My post was in no way a response to nor a critique of your viewpoint on this matter!
I was simply helping out with locating a post someone else had requested.
I value your contributions and hope you continue to contribute to this forum!
Yep, if Glowforge is coding based on “save as” then in this context, it’s case closed until GF says otherwise.
If GF is coding to support “save as” instead of “export” SVG from Illustrator, then I suppose that’s the answer.
Odd, though, in that Adobe says that the “export” command is what should be used for sending images to print/render, which is our use case. If we’re all being told to send larger, harder to process files to Glowforge just because of a bug involving one character in one font, it would (IMO) make more sense to deal with that bug as a one-off. Since there’s a whole class of files that work (for me) exported that fail using save-as, due to the size and complexity of the ‘save as’ files vs ‘export’.
I doubt it is because of that one issue. More likely, that one instance is an example of more widespread differences in how SVG is written in Save As vs Export.
From the topic I referenced:
Yes, I read that. Save As and Export are completely different commands, which are intended to do different things. The part I’m having a little trouble with is that Export is the command intended to generate stripped down files for printing/viewing, with all of the metadata and hidden objects removed for efficiency, so it’s what (from Adobe) we should be using. I’ve printed 100+ things so far via export, and I have several files that work via Export but fail in processing with mysterious errors using Save As, so in my mind it’s at least still an open question as to which method is better. Right now, I think it’s a matter of how Adobe’s quirks and Glowforge’s quirks mesh for a given file.
If GF prefer to use Save As then it is another bonkers feature of their software phylosophy. Please export data in a format with no physical units and let us guess the size instead of using the correct export command because we have a bug in our import.
Why not get rid of inches completely from the GFUI. Then we have no actual real measurements at all, zooms, pews and pixels. Fantastic for artists and children, crap for engineers.
To me, if only one method works, use that. If both methods work, use the one that reproduces the geometry you’ve created most faithfully. In the case of the two methods @henryhbk used in that Papyrus thread, the outputs were significantly different.
Here are those two outputs compared on top of each other in Rhino…
Attached are the files I used/created in Rhino…
Save As or Export.zip (69.4 KB)
For the curious, my recollection about this:
Export creates a file that is indistinguishable from files from other sources. Unfortunately, each of those sources behaves slightly differently. Save As creates a distinct “made by illustrator” fingerprint on the file. We can deal with files of known origin reliably since we can work around their errors, but when we don’t know their origin, we can’t predict the results - which in practice often leads to errors, as many implementations of SVG export are unusual, out of spec, or downright buggy.
Export also requires you to change the defaults in order to work correctly; Save As works with the default settings (aside from embedding images - which we can detect and prompt you to fix).
Finally, empirically, we found many problems with Export that were solved by using Save As, and none of the reverse.
The research done by folks on the thread, particularly @chris1 and @laird, is very helpful and has some useful information on export that we haven’t seen before… We’re planning to re-examine to make sure we don’t need to change our recommendation.