Yes. With A3 paper also it just matches the upper left hand corner position. One of the annoying things about this workflow is that inkscape X and Y origin is the lower left hand corner of the page, so in the UI, the position of the object is reported as X: 25.4, Y: 394.1
Now, I should try an object that doesnât fit and see if it scales.
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).
@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âŚ
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.
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.
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⌠width=â72pxâ height=â72pxâ
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.
â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.