Exporting SVG from Designer makes a font/svg file instead of image/svg+xml

[rcorbari]

Hello,

 

I have a strange issue: exporting SVG as usual to be used on websites, Designer makes a font/svg file instead of a image/svg+xml file.

 

This makes the file unusable in my WP websites. I already compared the SVG files text using TextWrangler but they seem equal. I attach one of them for analysis.

 

What do you think the problem could be?

 

Thanks for your support.

LovelyApart 2018.svg

[Gerard O]

It opens as am image(in Windows Edge) for me

 

[Friksel]

After looking at your svg-file that just looks like a normal SVG to me (and loads in the browser just fine here), except for the fact you don't export the vectors, but all flattened to a bitmap. When you need a flattened image (so no clean vector-graphic), why not export to a jpg instead? That would normally result into a much smaller file size as well. But my advise would be to change the SVG export preset to 'SVG (for Web)' and make sure you're exporting vectors only. 

[rcorbari]

Thanks to all. Probably I uploaded here the wrong file: I exported the sections in reveal formats, including svg for web and svg flattened. 

Let me export again from scratch to svg for web and double check if the file is correctly recognized by WordPress. 

[rcorbari]

I tried to check again the export settings but the problem persists, even exporting "SVG for web". I attach some screenshots: you will see the correct file as exported in march (the example of airbnb.svg file), how today the new svg files appear when uploaded (grey icon), and the file format recognized by WP (font svg) even if I just exported the file using "SVG for web" settings.

 

I also attach Designer settings for SVG for web.

 

Please help, thanks.

 

 

[stokerg]

Hi rcorbari,

 

Can you try setting the Rasterise option to Nothing and then exporting the SVG again.  If that is still failing after that, please attach the .afdesign file and also the SVG for the other logo created back in March and we can look into this further

[rcorbari]

No way, still font/svg detected by WP. I attach the new Designer file and the old file.

Logo LA18 Final.afdesign

logo old.svg

[stokerg]

Thanks for the files.

 

I've exported your .afdesign out using the SVG For Web option and uploaded the file to my install of WordPress and it's being identified correctly (screenshot attached).  I've also uploaded the SVG file from your 1st post and again, it's being identified correctly by my WordPress (screenshot attached).

 

I've attached my exported SVG file to this post as well, so you can test it. 

 

It's starting to look like it could be an issue with your WordPress setup

LovelyApart 2018 Export for Web Preset.svg

[rcorbari]

Thanks @stokerg

 

it's strange since I never had problems with SVGs until these last days. I'm using Avada and SVG Support as plugin. I also tried Safe SVG without success.

 

I don't know where to look now, because the previous SVGs uploaded are still perfectly visible, to me seems still an issue with the export.

[stokerg]

10 minutes ago, rcorbari said:

Avada and SVG Support

 

Have either of these had an update in the past few days?  I'll install SVG Support plugin and see if anything different shows up (i altered my Functions.php to add svg support).

 

Update: Removed the code from Functions.php i had added to enable SVG support and installed the SVG Support Plugin.  Both SVG files, after being reuploaded are still being reported as image/svg+xml

[rcorbari]

5 minutes ago, stokerg said:

 

Have either of these had an update in the past few days?  I'll install SVG Support plugin and see if anything different shows up (i altered my Functions.php to add svg support)

 

No, they don't. If you could send me the code to add to functions.php, I can try to deactivate the plugin and see if something changes. I don't understand why the older files are perfectly visible, and the new ones don't.

 

I just tried to deactivate the latest plugins I installed but the problem persists.

[stokerg]

I got the code from this site:

https://www.sitepoint.com/wordpress-svg/

 

The snippet of code does set the type as image/svg+xml, so hopefully will work for you.  

 

If it was Designer at fault, i'd of expected to get the same issue when i uploaded the SVG from the 1st post, but it's loaded and displays fine and is identified as image/svg+xml for me

 

 

[rcorbari]

Now it's ok. I deleted the SVG plugins (SVG support and Safe SVG which was deactivated) and reinstalled Safe SVG only, now seems ok.

 

Thank you very much for your support!

[stokerg]

That great news rcorbari  Glad everything is working as it should now

[Friksel]

Good to read your problem is solved now!

@stokerg I was just looking into the svg too and I keep asking myself: why is there a xmlns:serif inside the SVG-tag?? Does this actually has a purpose or is this just to promote the company website?

[R C-R]

16 hours ago, Friksel said:

@stokerg I was just looking into the svg too and I keep asking myself: why is there a xmlns:serif inside the SVG-tag?? Does this actually has a purpose or is this just to promote the company website?

I am not @stokerg nor an expert on the subject, but the "ns" in the xmlns attribute stands for name space. As explained for example here, name space declarations are necessary to avoid name space collisions -- basically, when two different name spaces use the same tag for different things. The string in the xmlns attribute is not really a link, just a common way to identify a name space uniquely.

 

So for example, with the xmlns:serif="http://www.serif.com/" declaration, tags like serif:id=<some object id name> prevents confusion between a w3.org id tag & a serif one.

[Friksel]

4 hours ago, R C-R said:

So for example, with the xmlns:serif="http://www.serif.com/" declaration, tags like serif:id=<some object id name> prevents confusion between a w3.org id tag & a serif one.

 

Thanks for your reaction @R C-R. I'm a developer myself, so I know about namespaces. This is my point: serif-attributes don't have any meaning in a webbrowser and so they are redundant data making the SVG larger and because of that loadtimes longer. With all kind of compression-technics we are trying to minimize svgs to the bare minimum, but these serif-attributes aren't filtered out by minimizers, so they stay inside the file even though they don't have any meaning online. They just stick around and making the files larger then needed.
 

Using those serif-attributes inside svg's for importing in other serif software could make sense though to add additional data wich is Serif-specific for Affinity software and all. But when we export svgs for use on the web we don't want them inside our files. Next to this, if we would like to export our layouts to be used inside another Serif product, why not import the original Designer- (or Photo-)files instead? There's no use in importing svg's than I'd say.

It would be very much appreciated if there would at least be some option in the exporter-dialog to leave serif-specific attributes/namespaces out of the svg! 
And if it is about promoting Affinity products, I'll do that anyway  Thanks!

[R C-R]

50 minutes ago, Friksel said:

This is my point: serif-attributes don't have any meaning in a webbrowser and so they are redundant data making the SVG larger and because of that loadtimes longer.

You could say the same thing about xmlns:xlink or any of the several other name space attributes commonly found in SVG files, whether from web based or other sources. As the Namespaces Crash Course article mentioned, it has long been a goal of the W3C to make mixing different types of XML based content in the same XML file as problem free as possible. Even if we consider only web-based content (probably not a good idea), there is no way of knowing what user agent might be used to access it or for what purpose. I suspect that is why the Conclusions section of the article recommends including at least all commonly used namespace declarations in new SVG files,or for that matter why 'minimizers' don't filter out xmlns attributes.

 

Besides, from a practical standpoint, even for very complex SVG documents with lots of serif tags this would not amount to much data or increase page load times appreciably, even for quite slow connections. 

[Friksel]

@R C-R Guess we're having a different opinion on this.