Export SVG is 25% bigger, I can't back-up files - SOLVED

**Solved - For anyone else experiencing this, to save you all the reading Chris1 found a solution and fix for this that you can read in full below. **

Cause - parts of the image are outside of the bed image area causing around a 25% increase in size (varies).

**Open the SVG in Notepad - right at the top you will see - width, height, viewbox. **

Change them to - width=“20in” height=“13.25in” viewBox=“0 0 1920 1272”

> NOTE! You may have to change the " (Quotes symbol) in the above text. I noticed when copying it from this thread it changed to a weird up and down " style and corrupted the file!

Save and reopen the file and everything should be correct scale.

My original topic was closed after 30 days, so I can’t reply to it but I found new information on my error and hope someone can help. The export is only 25% bigger IF any part of the image is outside of the bed’s printable area. For example, if I have just printable area stuff in the file, no problem. If I have a second print waiting off to the top left that I move in once I am done - that is where the entire image distorts to 25% on export. Most of my files have 10-12 different “bed area sized plates” in the outside area so I can swap them in for each step. I desperately need to export my files, but I cannot export any that are larger than the printable area, and I do not know what to do. To copy each image into its own file would take hours and hours. I have 30 files with 10-15 images inside each. Is there really no way to save and export these without it distorting the size?

I only just finally figured this out today after years of searching for an answer. I was opening all my files as I do every 30 days to ensure they do not expire (do not have premium and can’t export these, lost them to a hard drive crash) but this time I decided to export them anyways even with the distortion just because if they ever expired I would have no way to recreate them. When exporting all of the said

" Design has manual settings

To make it easy to re-load, save your manual settings in your Materials Library before you export this design."

in the lower right and I had to hit continue before it would download, only 3 files did not say that and downloaded immediately. After testing why for a few hours I finally figured it out, that if anything is outside the bed area the image exported scales up 25-ish%

Maybe there is some issue I do not realize that this message means that I can fix, adjust, or turn off?

Original post:

I have been trying to backup my files since some I have used for years have been lost due to a failed hard drive. No matter what I try, the exported file from glowforge is scaled up about 25% which is useless - no I cannot just rescale it to the correct size as these are sensitive files and that would take days to do all the files.

To show the issue I made a 1 inch by 1 inch square and uploaded it to one of my files.

I am using the export SVG button in glowforge app right after the “premium” features.

I have tried downloading and immediately re-uploading without touching the file, so it’s not a program rescaling it. I use Inkscape for reference, but the image is already scaled 25% larger even with simple export/import and no touching.

I had the premium free trial and it still did this.

I have tried searching the forums, but only find people with upload scaling issues. My images upload just fine, it’s only the export to back up the images that have an issue.

Below you can see the file in Inkscape - the 1-inch square is now 1.25 inches.
The other is an image of the laser bed after export and immediate reupload without touching it, again the square is now 1.25 inches.

I have no other way to back up my files since my hard drive failed last month. I have had a glowforge since Kickstarter and tried multiple times over the years to export and save my files and it always did this. I didn’t really try to find a solution as it did not matter much, was just annoying, but now some of these will be lost forever if I forget to re-open in 30 days since I do not want premium. Please help!


3 Likes

I’m having a really hard time following what you are saying, but it’s known that there is a definite mis-match between DPI settings in Inkscape and the GFUI. 72 vs 96 DPI is 25%

3 Likes

Scaling is generally a minor issue that I often only do at the last moment before printing. If you find you have an issue you can even scale the job down and scale it back up again in Inkscape, With the entire design selected there is a widget on the lower left side that will give you the exact size and location the piece will print at. You can change those numbers and the result will be those numbers. What you see on the screen is the calculated location that can be a bit off based on Set Focus and the Callibration

2 Likes

Would you be able to supply an example test file that exhibits these symptoms? Ideally the original, and the exported version. That would make it easier for folks on the forum to try to reproduce the problem, and maybe examine the files for clues.

3 Likes

Hold the phone. I was able to reproduce this on my own following your description of having artwork outside the printable area. Here are the steps:

1. Create a new design by uploading this 1x1.svg file.

1x1

2. Observe that there are two squares, each exactly 1in x 1in:

3. (Optional) Export the design and upload the exported design to verify that nothing changes.

4. Drag one of the squares outside of the cuttable area:

5. Three dots menu, Export design.

6. Create a new design and upload the file that you just exported. In the test I just did, this was the file Glowforge produced:

1x1

7. Observe that the squares have now changed position and size from where they were when you exported them in step 5:

In my limited testing, the scale factor does not seem to be consistent, but depends somehow on where the out-of-bounds artwork was placed.

Will follow up with an examination of the SVGs themselves. But in short, it looks like you found a bug! You’ll probably want to contact Glowforge support, specifically, to report it.

9 Likes

I can understand why that would not be well known. I can’t think of a reason I would ever want to “export” a design from the GF UI… I uploaded them from my computer where they were created in the first place.

1 Like

So let’s take a look at these files. Here’s the original:

<?xml version="1.0" encoding="UTF-8"?>
<svg id="Layer_1" xmlns="http://www.w3.org/2000/svg" width="20in" height="12in" version="1.1" viewBox="0 0 1440 864">
  <!-- Generator: Adobe Illustrator 29.1.0, SVG Export Plug-In . SVG Version: 2.1.0 Build 142)  -->
  <rect x="72" y="72" width="72" height="72" fill="none" stroke="#000"/>
  <rect x="216" y="216" width="72" height="72" fill="none" stroke="#000"/>
</svg>

Here’s what happens when it is “correctly” exported (all artwork in bounds):

<svg
	xmlns="http://www.w3.org/2000/svg"
	xmlns:gf="http://glowforge.com/namespaces/gf"
	xmlns:xlink="http://www.w3.org/1999/xlink" width="20in" height="13.25in" viewBox="0 0 1920 1272">
	<gf:laserdefs>
		<gf:laserdef class="l91783f13-fe78-4b51-bfac-44b34dc5a35f" order="0" type="cut" power="NaN" corner="NaN" materialid="UNKNOWN" settingid="cut::DEFAULT_SETTING"></gf:laserdef>
	</gf:laserdefs>
	<g id="oEw">
		<g id="oE">
			<g id="g6af7cbc6-70d3-44c6-b953-0795f7b03bfd">
				<path class="e l91783f13-fe78-4b51-bfac-44b34dc5a35f l91783f13-fe78-4b51-bfac-44b34dc5a35f" id="e0" d="M96 96L192 96L192 192L96 192z"></path>
			</g>
			<g id="gde276dd0-8a4e-4cf7-94e8-7a75429aa536">
				<path class="e l91783f13-fe78-4b51-bfac-44b34dc5a35f l91783f13-fe78-4b51-bfac-44b34dc5a35f" id="e1" d="M288 288L384 288L384 384L288 384z"></path>
			</g>
		</g>
	</g>
	<style type="text/css">.l91783f13-fe78-4b51-bfac-44b34dc5a35f { stroke: #000000; fill: none; }</style>
	<text y="1172" x="20">
		<tspan>Glowforge® print settings</tspan>
		<tspan x="20" dy="20">Design id: 7BG1AYAVNHJFBRK977M9EO1WECYT1</tspan>
		<tspan x="20" dy="20">Timestamp: Fri Dec 27 2024 15:04:40 GMT-0500 (Eastern Standard Time)</tspan>
		<tspan x="20" dy="20">Version: 1.0</tspan>
		<tspan x="20" dy="20" fill="#000000">Step 0: #000000 Cut</tspan>
	</text>
</svg>

And here’s what happens with the bad one (one of the squares moved out of bounds):

<svg
	xmlns="http://www.w3.org/2000/svg"
	xmlns:gf="http://glowforge.com/namespaces/gf"
	xmlns:xlink="http://www.w3.org/1999/xlink" width="22.035851472471194in" height="14.846670934699105in" viewBox="-195.4417413572344 -153.28040973111405 1920.0000000000002 1272">
	<gf:laserdefs>
		<gf:laserdef class="l689a701e-932e-4e71-9dff-41305e4d8d35" order="0" type="cut" power="NaN" corner="NaN" materialid="UNKNOWN" settingid="cut::DEFAULT_SETTING"></gf:laserdef>
	</gf:laserdefs>
	<g id="oEw">
		<g id="oE">
			<g id="g2435b521-e74b-4ddf-9fe0-5487c6f92b1b">
				<path class="e l689a701e-932e-4e71-9dff-41305e4d8d35 l689a701e-932e-4e71-9dff-41305e4d8d35" id="e0" d="M96 96L192 96L192 192L96 192z"></path>
			</g>
			<g id="g812c6bca-39d3-44f1-ade6-ca39c177b1b0">
				<path class="e l689a701e-932e-4e71-9dff-41305e4d8d35 l689a701e-932e-4e71-9dff-41305e4d8d35" id="e1" transform="matrix(1,0,0,1,-483.4417413572346,-441.28040973111433)" d="M288 288L384 288L384 384L288 384z"></path>
			</g>
		</g>
	</g>
	<style type="text/css">.l689a701e-932e-4e71-9dff-41305e4d8d35 { stroke: #000000; fill: none; }</style>
	<text y="1172" x="-175.4417413572344">
		<tspan>Glowforge® print settings</tspan>
		<tspan x="-175.4417413572344" dy="20">Design id: 7BG1AYAVRHNGJCBHJHWEBHPHCR9AB</tspan>
		<tspan x="-175.4417413572344" dy="20">Timestamp: Fri Dec 27 2024 14:57:52 GMT-0500 (Eastern Standard Time)</tspan>
		<tspan x="-175.4417413572344" dy="20">Version: 1.0</tspan>
		<tspan x="-175.4417413572344" dy="20" fill="#000000">Step 0: #000000 Cut</tspan>
	</text>
</svg>

Now, it’s a little bit messy, but the two paths are the same:

M96 96L192 96L192 192L96 192z
M96 96L192 96L192 192L96 192z

M288 288L384 288L384 384L288 384z
M288 288L384 288L384 384L288 384z

The second box is moved by a transform rather than changing the coordinates. What is actually different between these two is the viewport size and viewbox. From:

width="20in" height="13.25in" viewBox="0 0 1920 1272"

to:

width="22.035851472471194in" height="14.846670934699105in" viewBox="-195.4417413572344 -153.28040973111405 1920.0000000000002 1272"

I think what we’re seeing here is a misunderstanding of how SVG scaling works, and what these numbers represent. The viewBox attribute’s contents are “min-x min-y width height”. Importantly, the combination of the viewBox’s width and height in pixels combined with the root svg element’s width and height in inches give the resulting document a real-world DPI. The first example is easy: viewBox="0 0 1920 1272" means that relative coordinates will be in a 1920x1272 pixel box. How big is a pixel? 1920/20 and 1272/13.25 = 96 pixels per inch. Our square’s coordinates are 96 pixels apart (e.g. (96, 96), (192, 96), (192, 192), (96, 192)), therefore it’s 1in square.

The messed-up one gets interesting. It says viewBox="-195.4417413572344 -153.28040973111405 1920.0000000000002 1272". I think someone thought that makes the viewbox bigger. It does not: it’s still 1920x1272 pixels. It just has an offset starting position, which is actually the opposite of what was intended (and it’s why the re-imported design is no longer out of bounds). And on top of that, those 1920x1272 pixels are stretched out to a space 22(ish)x14.8(ish) inches, leading to only 87 DPI. But since the coordinates of the squares are unchanged, it leads to everything being about 10% larger.

The solution here is surprisingly straightforward: simply keep the original width="20in" height="13.25in" viewBox="0 0 1920 1272". In the following file, all I did was take the broken one and change those three attributes.

fixed.svg

And as you can see here, everything is exactly where I left it before exporting, including one square being out of bounds, and it’s all back to the correct size:

So I think this might be a fairly straighforward bug fix.

6 Likes

Wow.

Interesting but, again, I can’t think of a reason I’d ever need to export out of the GF UI.

1 Like

OMG you are a lifesaver it works!!!

I just opened the SVG in Notepad - right at the top was - width, height, viewbox. Changed them to width="20in" height="13.25in" viewBox="0 0 1920 1272" as you said and the image was normal scale. I put a 1x1 inch box in every SVG and just edited one, so far that one worked! The box is 1x1 and everything else remained to the original scale I originally uploaded it as!

Wow, thank you SOOOOOOO much! For so many years I have been trying to figure this out! Though why it does this I have no idea, hopefully, anyone else trying to export finds this thread unless they fix it! I can finally recover my files now!

3 Likes

As I stated in my long original post, I uploaded some of these files years ago when I first got the glowforge on kickstarter and many of the original files were lost when my hard drive crashed as it was before I started saving everything to the cloud. With the fairly recent 30 days requirement I have had to set reminders to make sure I open every file every 30 days or loose access to them unless I upgrade to premium (I don’t have any use for premium as my work is very specific and the features are useless to me)

2 Likes

Ah, got it.

I regularly back up my main computer to three different external hard drives, one (rotated) kept in a safe at another location.

This topic was automatically closed after 30 days. New replies are no longer allowed.