Nope. It just happily lets it run off of the printable area. Either an object out there or an object that spans (tried them both, separately).
From this I’m guessing that the page size is mostly useful for the human to do initial placement within the printable area. If you’re designing something with multiple ops, you’ll want to get the placement right in the design software since if the browser session dies, you lose any monkeying around you do there and since there’s no numerical input, you can’t precisely repeat any tweaks you make.
So, at the moment, probably a 19"x10.97" page size is better (than 20x12) since that’ll help the user avoid putting something outside of the printable area (as long as they remember to give engraves more space).
Ah, I see. I didn’t realise this was only needed for otherwise unit less files.
@chris1, if you recall (I’m not searching because I am lazy and coffee hasn’t kicked in) I had horrible problems when i first got the PRU and later someone looked at my SVG and noted that the export produced a radically different (albeit valid) SVG code than the save as did. Not sure why adobe wrote 2 different SVG engines but they apparently did…
Because everyone doing so and getting consistent reproducible correct results are just imagining it right?
Looks like this creates a bug when you have an object at the origin. You have to move it away a small fraction or it gives the no artwork message. Or perhaps a simple > 0 which should be >= 0.
Not sure why adobe wrote 2 different SVG engines but they apparently did…
Common at big companies with lots of developers. At one point Excel on the Mac had four different math evaluation engines. We wrote a math accellerator that hooked in, and we had to find and hook into all four (e.g. evaluation of math in scripts was different from evaluation of math in a cell in a spreadsheet, which was different from Solver, etc.), presumably because each component was written by different teams. They had different semantics and order of operation, so they would literally give different results to the same equation, so QA was a nightmare.
So my guess is that “save as” and “export” were written by different teams with different goals. One important difference that I see is that export only writes out what’s visibile in the file and only enough metadata to render that, while save as includes hidden layers, and also quite a bit of additional metadata required to let Illustrator read the file back in and edit it. So “export” files are much smaller, and are easier to parse. Still, it might have been better to have both done by one engine, with some logic doing filtering.
I think we all must acknowledge that some individuals care about details. Lawyers care about specificity of words/language and engineers about specificity of numbers. Good enough works for me, but were I an engineer it wouldn’t be acceptable. @chris1 has done us a “solid” by exposing a tangible difference in the 2 methodologies, and I for one thank him for it. I’m sure @jamesdhatch was being lighthearted but I want to give my appreciation for a precise interpretation of the code.
“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.