Exported images from illustrator get sized incorrectly


#1

I’ve noticed that a lot of files that I’ve created with illustrator get sized incorrectly in the glowforge, leading to bad prints and thrown away materials. The latest example of this is below.

In Illustrator, I have a box that is around 10" wide and 5" high. When I import the file into the glowforge, the dimensions are drastically different.

I’ve put the image next to the proofgrade sticker for size. If we measure the vertical piece with only a few teeth, in Illustrator it’s 1.15x3.9. When actually cut by my glowforge, it’s .75x2 7/8.

The exported svg is attached. This has been messing up a lot of my prints and I really need to figure out how to resolve it.


Further discussion of images being resized
Vent svg
#2

Make sure when you save your file, you don’t have any extra boxes checked. Some of them capture Adobe settings that will change the sizing. (Think that one is Include XMP.)

Correct Save As SVG settings are shown below:


#3

From the other one today


#4

And, be sure you do a Save As… not Export.


#5

Contrariwise, I always use Export (in fact I use Export for Screens because it’s quicker) and I have never had a problem with my SVGs.

Format_Settings


#6

For those of you using an older version of Illustrator (CS3 in my case), I wrote a cleanup tool to help make the dimensions right.

That being said, importing random SVG into Illustrator is such a pain (it keeps losing dimensions and putting things in random places) I’m actually trying to learn Inkscape…


#7

Modern versions seem to work pretty well. It’s just that they default to Responsive being on, which throws everybody the first time. If you look at the generated file, this is the bugbear:

<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 729.79 372.57">

Uncheck “Responsive”, and you get:

<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" width="10.14in" height="5.17in" viewBox="0 0 729.79 372.57">

Now I suppose one could argue that the Glowforge software might or even ought to default to a coordinate system in inches, which would make these two functionally identical. But that’s just going to cause trouble down the road. Better, maybe, to prompt the user or to fail to import the file at all.

Edit: Actually, now that I think about it, with a viewBox in effect, that wouldn’t work. I think you need the width and height attributes.


#8

In Affinity, there is no choice but to ‘export’. Saving ‘as’ saves the file only in the Affinity format.


#9

Glad to know that. In the past people have reported problems with exported Illustrator files, but maybe it has to do with version (mine is very old: CS5).


#10

@curt thanks for that link!

@chris1 that looks right to me, the svg file needs width and height properties to be correctly sized. I wish there was either some notification from the UI that this was happening, or that the UI allowed us to specify an absolute size when rendering. It looks to me like the viewbox settings are in pt from illustrator, but the UI is probably assuming they are px or mm.


#11

The specification says to default to px, but that doesn’t help for various reasons: If I’m interpreting the rules correctly, viewBox="0 0 729.79 372.57" is establishing that all the contained elements are scaled such that 729.79x372.57 abstract “user units” fills the entire “viewport”.

The problem here is, how big is that viewport? If the SVG contained a width and height with unit identifiers, you just use them. Otherwise, in a browser, there are some rules for determining the initial viewport (like using CSS or scaling to fit the container), but it kind of makes no sense for a standalone SVG.

The more I go through this, the more convinced I am that it’s literally impossible to do the right thing, and the graphics application needs to export fixed width and height.

So my suggestion for Glowforge is to prompt the user when such a file is imported. Right now it’s a pretty bad situation because it silently picks a size and is almost certainly wrong. But refusing to load the file entirely would annoy people and make their lives difficult. So instead I would pop up a dialog explaining that the file is missing size information and ask how big it’s supposed to be. You could just do that the first time and then remember it, although it would be nice if there were a place to change it in case you made a mistake.


#12

Like Chris, I am also using Export, with the lastest version of Illustrator CC. I had posted a few weeks back about Illustrator not sizing my files correctly, and it was also because I had the ‘Responsive’ option checked.


#13

I can imagine some artwork might make sense to not have a defined size. For example, with a logo it might be natural to drag and size it to fit on an object. On the other hand constructional things like boxes need units. If the GFUI displayed the size of the currently selected objects it would be easier to spot it being wrong.


#14

The issue is related to DPI. A little googling turned up some discussion. The upshot of which is that the view box defines “user units” as opposed to physical units. Some elements in an SVG can only be expressed in user units. User units can be arbitrary and basically say, “map the entire display area to this number of user units. However, if you also specify width and height, you now have an explicit declaration of the mapping from physical units to user units.

@chris1’s example uses 72 dpi, which is also identical to points. Original Mac screens were also 72 dpi. Discussions I found indicate 72 dpi (or more accurately user units per inch) is the default (perhaps only?) setting in Illustrator.

@davethegr8’s example, if we assume it was using 72 as the base, was rendered by the GFUI at 110 DPI. A 20” HD monitor would have 110 DPI. I am wondering if the combination of the browser and current display resolution might play a role here?

Moral of the story, force it to include width and height—turn off Reponsive.


#15

Oh :woman_facepalming: totally forgot to mention this…when you’re designing in Illustrator make your default Artboard size equal to 12" x 20" for all of your Glowforge designs. It retains placement and size information for the files.


#16

@johnse that makes some sense, though viewbox I think just uses px definitions. https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox And a dpi mismatch would cause the sizing issues as noted, though I can’t figure out what app.glowforge’s default is.

@jules I’m actually using 11.5x20 as my artboard size, so that I know that anything on the artboard will be in the working area of the laser. Have you tried that? Is there a vast difference between 12 and 11.5?


#17

Yes, the workaround only works if the artboard is exactly 12" x 20". That might be one reason why you’re seeing changes in size. Fixing that will stop it. :grinning:


#18

I hate to be the “well actually” guy, but I feel like I’ve now invested a significant amount of my rapidly dwindling lifespan into studying the SVG specification, so I might as well leverage that to hypercorrect minor inaccuracies. That’s what the Internet is for, after all!

To wit: viewBox attribute is specified in user space, which may or may not be pixels depending on the current user coordinate system in effect. For practical purposes, the viewBox attribute we’re talking about here, on the top-level svg element, might as well be in smoots. Without either a width and height attribute, or a containing document to establish an initial viewport, there’s no requirement for the app to render the SVG at any particular size.

The right answer is to ensure that the files you create have width and height in them. For Illustrator, that’s a simple matter of unchecking responsive. In Affinity Designer, you have to click More and turn off “Set viewBox”. I don’t know what the Inkscape option is, but it has one.


#19

No. The reason he’s seeing changes in size is that he was exporting SVGs with “Responsive” checked.

12" x 20" is a workaround for absolute positioning. It may have the side effect of fixing the size, but that’s just confusing two issues.


#20

You’ll be happy to know that I went back in and reworded that, just for your benefit Chris. :smile: