SVG Specifications Used in File Validation for Programmatic SVG Generation

Less of a problem, more of a question…

For context:
I am programatically generating SVG files and it would seem that “line” elements are problematic for the uploader and simply gives me the error:
There was an error while uploading this file
It may work if you try again later. If the issue persists, email the file to support@glowforge.com for help.

Now this SVG opens in browsers and Affinity Designer with no issues.
I can also export from Affinity Designer as SVG for Web and that file will upload just fine.
The major differences in the two files are some headers and the lines are converted to paths.

So the problem becomes that while I can just run it through Affinity Designer each time, it’s simply not efficient. That brings me to my question(s)…

Question(s):

  1. Is there any documentation that specifies which SVG elements are supported and which are not?

  2. Is there anyway to get verbose output from the file validation algorithm?

  3. Is there anyway to get a standalone file validation application or script for those who want to quickly validate a file against the Glowforge application?

Thanks in Advance,
Tommy

2 Likes

I don’t know, but maybe someone like @Jules or @marmak3261 can tag some of the tech heads that might be interested in this question :wink:

1 Like

This is one that only Glowforge can answer. We don’t have that information. :slightly_smiling_face:

1 Like

Are you having trouble with the line elements themselves, or perhaps the new line characters that are being used? And what makes you suspect these line elements?
I agree that access to a spec and output would be handy, but it doesn’t sound necessary here. Can you take a known-good svg and compare it to your generated one? There should be either a visual or bytecode difference between the two.
Without more details, I’d suspect malformed svg code in your generated file, which could be validated as above.

Is there more to it that prevents this?

2 Likes

I think you may be onto something. I was going to try and upload the two files here (into this post) but my programmatic one, despite being displayed without issue in a few browsers and affinity designer, is kicked back by the forum. The error I get in the forum is something along the lines of not being able to determine size. That warning is along the lines of the feedback which I think would be super useful to people trying to upload files to the app.

However, I do understand that the more verbose warnings can make things worse for some users.

I initially suspected the lines as the affinity designer output is a pretty similar file with path elements instead of line elements. However, there is also the addition of a small preamble that the app might be looking for.

I will try and include the preamble and see if I can narrow down exactly which part is upsetting the app.

-Tommy

I’m not sure how hard this needs to be. Here’s a plain SVG with a single rectangle. After the header, it has a simple rectangle with x,y, height and width. If you replicate the bulk and put your own elements into the body, they should load just fine. I’ve manually edited SVG files many times, there’s not much “magic” in them.

square

1 Like

Okidoki…

I found it. Apparently the app is looking for a Document Type Definition (DTD) to most likely to validate the SVG file against.

The SVG uploads and the app interprets the line elements just fine when I include the DTD :

<!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd”>

And you’re absolutely right @eflyguy … not much magic in there which is why this stumped me.
My guess is they are one of the few applications actually validating SVG syntax and hence need the DTD, which makes the process much easier.

All in all, thanks everyone who helped kick start my brain.

-Tommy

3 Likes

Hope it helped, and you’ll share at least pics of your finished designs!

2 Likes