“Save As” and “Export” are intentionally different, because they’re intended for different uses.
“Save As” is intended for sending the document to someone else to work on. Thus it saves the document into a format with all of the metadata required for someone to load and keep working on the document. If you “save as” an SVG file, it’s got tons of information in it beyond what’s required simply to render the image, such as hidden objects. For example, I’m generating many objects with the same cut but different engraves, which I put each on a separate layer, so I can easily hide all layers except the cut layer and one engrave layer. When I ‘save as’ the output file contains all of the layers, so that if I open the SVG in Illustrator they’re still there. IMO, the use case for “Save As SVG” is a bit obscure - most of the time you want to work in Illustrator’s native format.
“Export” is intended just for rendering. So it can output to a bunch of bitmap formats, and when it writes an SVG it strips it down to just what’s needed to display the image, with all of the hidden objects and additional metadata stripped out. When I ‘export’ the same document I used as an example above, I get just the cut layer and the visible engrave layer, and the file is much smaller and simpler. If I open an exported file into Illustrator, it has nothing but the visible objects - all of the hidden layers are gone. And that’s a good thing, because the file is (in this case) 1/10th the size, making uploading and processing in GFUI much faster.
So what Illustrator does isn’t being imprecise, it’s being quite precise for two very different use cases for SVG. Either you want all of the hidden objects and metadata of an AI file, but written in SVG (perhaps to send to someone using Inkscape?). Or you want to send something compact to efficiently render, such as for printing or use on a web page. For GFUI, that’s what you want.
The SVG from both “save as” and “export” are valid. The difference is that the SVG written by “export” is stripped down to just what’s required to render/print the image, while the SVG written by “save as” has a lot of additional info in it so as to represent everything in Illustrator (hidden objects, tons of metadata, etc.) for continued editing. So both will work, but the smaller, simpler file generated by “export” will be faster to upload, faster to process, etc., so in general it’ll work better. For a specific example, I have an Illustrator file that’s 12 MB via “save as” and only 2.5 mb via “export”. The 12 MB file fails in “processing”, and the 2.5 MB file works fine.
For a file with no hidden layers, the “save as” is still bloated compared to the “export” file, but it’s not so dramatic. It takes longer to upload and process, but not dramatically longer, and not failing.
I just found a nice explanation of the SVG units complexity - https://mpetroff.net/2013/08/analysis-of-svg-units/ .
TL;DR: “In SVG, there are two types of coordinates, those defined in user space and those defined in real world units. If no unit is specified, it is assumed to be in user space units. By defining the document size in real world units and applying an equivalent viewBox attribute, one can define the user space unit to be a real world unit, e.g. millimeters.”
Since SVG crosses so many domains, units can get really messy. The supported length unit identifiers are: em, ex, px, pt, pc, cm, mm, in, and percentages. So if you’re designing for screen. print, or fabrication you work in different units (traditionally). And some of the units (pixels, em, ex) are completely context-dependent, so their meaning changes depending on what font you’re using, what dpi screen resolution is configured for, etc. Then you can mix them into a single design, which is all kinds of confusing. The spec https://www.w3.org/TR/SVG/coords.html is mind-bending. But I’m sure it’s precise, given that it’s from the w3c. But icky. I thought date/time was messy… whew!
Date/time is still messier. Time zones, daylight saving, leap days, leap seconds, calendar systems that disagree on the number of days in a year, etc. Not to mention calendar systems where the numbering of the year depends on who is emperor or calendars where the beginning of the month depends on whether someone in a particular location was able to see the crescent moon or not at a particular time.
Good point on upload time. I’m just getting started on using the gForge, so those constraints are still new to me.
Just thought I would link this discussion to another problem that I was testing for @jtbarrett.
Exporting an SVG from Illustrator gave me a file that the GFUI would not process. But using Save As did give me a usable file.
It’s interesting that Illustrator seems to be relying on that assumption as well when the user opens a file that was saved as. Presumably a 1 x 1" artboard would have…
in it, but what would it spit out if you set your artboard to 1.0069 x 1.0069” (slightly less than 1-1/144" square). Would it say “72.5px”? “72.4968px”?
Not entirely. I was pointing out the disconnect between the authoritative “Save As should not be used” with the fact that it’s been used successfully for many thousands of files in the last 9 months of real life use of the GF by many many people. The implication that all those projects did not work, could not work, should not work and all the people using that method (recommended by GF by the way) are doing it wrong because an individual who spelunked the SVGs thinks he has an explanation of why they all can’t be doing what they’re doing flies in the face of reality.
I’m perfectly fine with suggestions, recommendations or observations but pronouncements of absolutes in the absence of all the facts (and since none of us have access to the GF source code, we’re only guessing as to how it’s handling things) is the height of hubris.
Sometimes reality deals theory a sharp smack.
“Should not be used” is quite a bit different than “can not be used”. If @chris1 had said “can not be used” the fact that it actually can be used would be a great retort.
Lol, I was going to say something like “calm down Francis” but you covered it quite well with your TL’dr.
Really trying hard to stay up on this amazing topic and important issue. I appreciate your tenacity because it has been enlightening for so many issues. I’m thankful that you are putting this effort into the forum because much good can come of this.
Are we talking about recommended best practices? In the sense that, if we are all starting from scratch with the same learning curve to deal with, export is the better habit to use for making GFUI ready files for several reasons. Save as works but causes a file description that might be more open to problems.
I am think about qwerty keyboards versus colemak keyboards. Anyone with a smidgeon of statistical acumen would be insane to endorse qwerty over colemak or some other letter frequency/home position based layout. And yet, what do we have? The burden of legacy infrastructure and educational/informational pathways. It pained me each year when I taught technology to elementary students. I knew I was teaching them a less efficient method of touch typing, and yet I still did it. It works well enough. Enough that it balanced out the hassle of learning to reconfigure keyboard layouts in software and on the hardware itself and being prepared for the rest of your life to have to roll your own.
There is the ideal and there is the real. I do believe we can agree on best practices, but personal workflows will be personal workflows.
But maybe I have totally missed the point here. Sorry if my narrative has nothing to do with the issue at hand.
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.