Jump to content
You must now use your email address to sign in [click for more info] ×

SVG file size AI vs Affinity Designer


Recommended Posts

Hi there, I'm thinking of switching from AI to Affinity Designer and am currently testing AD. I need AI primarily to customise logos for websites. Now I have the problem that the SVGs saved from Affinity always have at least twice the file size as the ones from AI (same logo, same size, procedure etc). I can't see any difference in quality. Is there perhaps a trick?
Thanks for any help!
Tobias

form Affinity.svg from Adobe.svg

Link to comment
Share on other sites

Hi @topro

As you can see, Adobe does away with all formatting and clarity.

image.thumb.png.cee9098939d3bb8fc80fb80967965aa8.png

AMD Ryzen 7 5700X | INTEL Arc A770 LE 16 GB  | 32 GB DDR4 3200MHz | Windows 11 Pro 23H2 (22631.3085)
AMD A10-9600P | dGPU R7 M340 (2 GB)  | 8 GB DDR4 2133 MHz | Windows 10 Home 22H2 (1945.3803) 

Affinity Suite V 2.3.1 & Beta 2.(latest)
Better translations with: https://www.deepl.com/translator  
Need a system wide color picker? Try Microsoft's (New) Power Toys
Need a robust PDF Solution? Have a look at Stirling PDF

There's nothing you get used to faster than working slowly!

Link to comment
Share on other sites

Just use a SVG compressor/minifier to compact the Affinity SVG file output further ...

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

15 minutes ago, Komatös said:

Hi @topro

As you can see, Adobe does away with all formatting and clarity.

image.thumb.png.cee9098939d3bb8fc80fb80967965aa8.png

 

20 minutes ago, v_kyr said:

Just use a SVG compressor/minifier to compact the Affinity SVG file output further ...

Thanks for that, but what I get from Adobe is already much smaller without further processing. And if I put the Adobe SVG into the compressor, it gets even smaller.

Link to comment
Share on other sites

@topro

Look at both files in a text editor that, if possible, shows a direct display of the differences.

AMD Ryzen 7 5700X | INTEL Arc A770 LE 16 GB  | 32 GB DDR4 3200MHz | Windows 11 Pro 23H2 (22631.3085)
AMD A10-9600P | dGPU R7 M340 (2 GB)  | 8 GB DDR4 2133 MHz | Windows 10 Home 22H2 (1945.3803) 

Affinity Suite V 2.3.1 & Beta 2.(latest)
Better translations with: https://www.deepl.com/translator  
Need a system wide color picker? Try Microsoft's (New) Power Toys
Need a robust PDF Solution? Have a look at Stirling PDF

There's nothing you get used to faster than working slowly!

Link to comment
Share on other sites

I did not know this optimiser yet. Here you can still make settings and see the result simultaneously, into which you can also zoom. I was able to save up to 75% file size without visible degradation. Excellent tip! I should be able to manage with that.

Many thanks to both of you. 

Link to comment
Share on other sites

52 minutes ago, topro said:

... but what I get from Adobe is already much smaller without further processing. And if I put the Adobe SVG into the compressor, it gets even smaller.

Well, even Adobe's SVG generator outputs more compact SVG code, it's not that much manual readable inside a text editor and thus then as easy to edit & customize as the SVG output from the Affinity SVG code generator. Meaning here, that in order to make the Adobe SVG code output more manual readable/editable at all I would need to throw it's code through an "SVG Code Pretty Printer". In contrast the by Affinity generated SVG code is pretty good readable and editable in any text editor (I usually tend to use "Sublime Text" with some add-ons for such purposes).

However, if you throw the by Affinity generated SVG code through some SVG Obfuscator/-Compressor/-Minifier you will get much more compact und smaller/lower sized SVG file sizes (which in turn are just plain XML based texts). - The same applies of course also to Adobe's SVG output code, which can be even further compacted/minified by certain above listed SVG tools then!

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

A very brief look at both files...

The AI file uses styles: <style>.a{fill:#636362;}.b{fill:#e5332a;}</style>. So paths are given a class '<path class="a" ...'

The AD file uses per path colours: style="fill:rgb(99,100,102). It's obviously less text to use classes like 'a' and 'b' than to specify the colours for every path in the file. There are 40 entries like this: 'style="fill:rgb(239,63,54);fill-rule:nonzero;"'. That's 46 characters for each path, compared to 14 characters for 'path class="a"'.

So it's fair to say that the SVG output from AD could be optimised.

Link to comment
Share on other sites

7 minutes ago, LondonSquirrel said:

So it's fair to say that the SVG output from AD could be optimised.

The overall point that counts IMO more here is, at least for SVG code hackers like me, to get better manual readable, formated & editable SVG output code, which one then can manually more easily alter & adapt to specific own needs etc. vs. getting unreadable, partly obfuscated SVG code! - SVG code optimization, in terms of smaller file sizes (for faster website loadings) if needed, can be performed with/by a bunch of third-party SVG tools (...as I've referenced partly above in this thread).

So overall I don't see any needs to optimize/compact and obfuscate the by Affinity generated SVG output code that much further by Affinity's own SVG generators yet!

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

6 hours ago, LondonSquirrel said:

I would not count using styles as obfuscation. It's just shorthand.

Another term often used for "shortening code" (aka making text more compact by throwing out all newlines and other readability formating characters etc.) beside minifying/compacting/shortining is obfuscation, since an Obfuscator does operation wise -beside making the code overall more unreadable- pretty much the same here for text based code.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

In OP’s case, the actual reason why the Affinity created SVG version takes more disk space than the one created by Adobe is that the former has 1,010 curve nodes each of which is described with accuracy of 3 decimals, while the Adobe one has 969 nodes, which are described in accuracy of 2 decimals max (the accuracy is user-definable at export time e.g. in Illustrator). Additionally, the Adobe version describes the drawing instructions whenever possible as a series of vertical or horizontal shifts using variably absolute and relative coordinates, which saves space (since only X or Y needs to be described).

E.g. one short path (character shape forming the capital letter “H” in the logo) is described (spaces added to separate the commands) as one absolute moveto and then 12 absolute lineto commands before closing the curve.

<path d="M89.152,21.792 L89.152,42.201 L87.141,42.201 L87.141,32.657 L75.039,32.657 L75.039,42.201 L73.055,42.201 L73.055,21.792 L75.039,21.792 L75.039,30.875 L87.141,30.875 L87.141,21.792 L89.152,21.792Z" style="fill:rgb(99,100,102);fill-rule:nonzero;"/>

The Adobe created file describes the same path as follows (drawing the shape clockwise starting from the top right node):

<path class="a" d="M89.15,21.79 V42.2 h-2 V32.66 H75 V42.2 h-2 V21.79 h2 v9.08 h12.1 V21.79Z"/>

So the Adobe version uses 62 characters spaces excluded to give drawing coordinates for the letter “H”, while Affinity uses 183. The latter is more accurate (it seems that always given with 3 decimals), but it also uses a pair of coordinates where only X or Y is needed, and repeatedly describes the same fill color and rule for multiple paths. In the Adobe created file the fill colors are described as class properties so they do not need to be described repeatedly for paths using the same properties. Fill rule is given only if needed.

The SVG code in these files is not specifically created to be human readable so both encoding styles save space by not adding unnecessary space between commands and coordinates, and do not wrap the long coordinate lists. I would say that anyone experienced with SVG can read both kinds of path descriptions without problems. For the Adobe version XML formatter and a proper editor is needed, but excellent editors are available for free, as are XML formatting extensions/plugins and syntax colorizers and anyone in frequent need of having a look in SVG code should really get one.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.