well, artboards don’t really apply in copy/paste operations, so i don’t think that will matter here. i can export just fine (and if I did, i’d use PDF to avoid any of those scaling issues).
but i’d really like the copy/paste to work properly because that workflow completely avoids exporting any additional files. which reduces a step and reduces file clutter.
Ah, I understand. My mistake, sorry I didn’t fully understand. But I’ve been doing some more tests with the workflow using the information you’ve all discussed in this thread, and was unable to reproduce the issue using AI 25.4.1 on MacOS Big Sur (this was no matter the document setup). All designs I created and pasted directly from Illustrator into the design library opened at the correct size. I’m going to ask one of my colleagues using Illustrator on Windows to test as well and take a closer look.
Stay tuned, I’ll let you know what I find.
for reference, i’m getting it in 25.3.1 in windows and in 25.4.1 in windows.
Thanks so much. Yup, a colleague was definitely able to reproduce with Illustrator 25.4.1 right away using Windows (thanks @chelsea!). I’ve exported both of the designs we created with this method to take a closer look. I’m going to want to take what I found to some other engineers before I suggest further workarounds. I’m going to be speaking to them late tomorrow morning, and I’ll follow up after I get a chance to review these details.
One more update before I take this to the team: I can let you know now that this may still be in Adobe’s hands, because the SVG information I get from Illustrator 25.4.1 on Windows as opposed to the SVG information from 25.4.1 on Mac is different (that’s going straight from Illustrator to plain text), and might be causing a different interpretation of the same information. I believe @jestelle was on to something earlier when suggesting this, but unfortunately this may mean that there is an issue at the most basic level of SVG creation in Illustrator on different operating systems and how those settings carry over between programs. Frustrating, definitely, to have changes like this impact a workflow you’ve established, but I’ll make sure there’s nothing else we can do on our end to suggest a non-clunky workaround.
if you help me understand exactly what the issue is, i can post on adobe’s site to complain about how their change broke my workflow.
It took longer than I expected to get back to you, but here’s what I’ve found.
We were able to narrow the differences down to the plain text SVG code coming out of Illustrator. The differences between a 1" by 1" square, created independently on a Windows laptop and MacOS laptop seem to be causing the trouble.
Here is the SVG code from a square created in MacOS on the current version of Illustrator. This SVG code can be pasted into the Design Library and opens as a 1" by 1" square as expected. <svg id=“Layer_1” data-name=“Layer 1” xmlns=“http://www.w3.org/2000/svg%22 width=“1.01in” height=“1.01in” viewBox=“0 0 73 73”><defs><style>.cls-1{fill:#fff;stroke:#231f20;stroke-miterlimit:10;}</style></defs><rect class=“cls-1” x=“0.5” y=“0.5” width=“72” height=“72”/></svg>
Here is the SVG code from a square created in Windows on the current version of Illustrator. This code, when pasted into the Design Library, opens to a square that is approximately .75” by .75"<svg id=“Layer_1” data-name=“Layer 1” xmlns=“http://www.w3.org/2000/svg” viewBox=“0 0 73.13 73.13”><defs><style>.cls-1{fill:#fff;stroke:#231f20;stroke-miterlimit:10;}</style></defs><rect class=“cls-1” x=“0.5” y=“0.5” width=“72.13” height=“72.13”/></svg>
The MacOS version is defining a width and height that can be applied to the layer; this is missing from the Windows version. This means there is no reference point to use when the Glowforge app scales the design. There are ways we try to scale appropriately in our software when this information is missing, but that’s dependent on the other information present. For instance, if the same SVG were exported and then uploaded, it would include information that the file came from Illustrator. This would fill in the blanks our software needs to understand the default dpi being used by the program, and how we can calculate that to match our app’s display.
I’ll raise the concern with Adobe, as well, but for now without width and height being defined in the raw Windows SVG code, there’s a high probability that the Glowforge app isn’t the only program unable to match the dimensions to the dpi from Illustrator in Windows when using this method. If you’d like to add another voice to that concern in their forums, that might be helpful.
Thanks so much for all the work here to get more information. Right now, there isn’t a method that can help this exact workflow succeed without rolling back your Illustrator version on Windows, but I hope this helps you understand a little more what’s going on.