Affinity Designer: SVG Export Optimization

[Pyanepsion]

Hello everyone,

v2.4.0.222

With the arrival of version 2.4 of Affinity Designer, it is crucial to pay more attention to the needs of web designers. Exporting AFDESIGN files in SVG format reveals a major issue: the excessive presence of superfluous elements in the source code. This can cause problems when SVGs are used on websites.

Issues

test-text-rectangle.afdesign

Current export vs. ideal export:

Here is a concrete example to illustrate the problem, based on a very simplified situation:

Current SVG source (Exported by Affinity Designer 2.4.0.2222): 3184 bytes

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" viewBox="0 0 889 154" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;">
    <g id="SVG-export" serif:id="SVG export" transform="matrix(1.05833,0,0,1.1,0,0)">
        <rect x="0" y="0" width="840" height="140" style="fill:none;"/>
        <clipPath id="_clip1">
            <rect x="0" y="0" width="840" height="140"/>
        </clipPath>
        <g clip-path="url(#_clip1)">
            <g id="Hide-maroon-rgb-115-72-72--tear" serif:id="Hide maroon rgb(115,72,72) tear" transform="matrix(0.944882,0,0,0.909091,76.9626,-7.27273)">
                <path d="M774.428,41.82C774.428,41.82 807.548,60.083 807.548,67.91C807.548,82.31 792.708,94 774.428,94C756.149,94 741.309,82.31 741.309,67.91C741.309,60.083 774.428,41.82 774.428,41.82Z" style="fill:rgb(115,72,72);"/>
            </g>
            <g id="Purple-rgb-115-72-242--circle" serif:id="Purple rgb(115,72,242) circle" transform="matrix(1.19876,0,0,1.31455,-195.447,-62.4413)">
                <ellipse cx="828.307" cy="100.75" rx="60.693" ry="53.25" style="fill:rgb(115,72,242);"/>
            </g>
            <g id="Pink-rgb-204-44-255--visible-heart" serif:id="Pink rgb(204,44,255) visible heart" transform="matrix(0.944309,0,0,0.908621,-17.4437,0.166044)">
                <path d="M853.979,109.074C861.352,98.868 876.097,98.868 883.47,103.971C890.844,109.074 890.844,119.279 883.47,129.484C878.309,137.138 865.038,144.792 853.979,149.895C842.919,144.792 829.648,137.138 824.487,129.484C817.114,119.279 817.114,109.074 824.487,103.971C831.86,98.868 846.606,98.868 853.979,109.074Z" style="fill:rgb(204,44,255);"/>
            </g>
            <g id="Yellow-rgb-255-255-63--Artistic-text" serif:id="Yellow rgb(255,255,63) Artistic text" transform="matrix(0.944882,0,0,0.909091,21.9758,16.3877)">
                <g transform="matrix(37.5,0,0,37.5,698.358,103.622)">
                </g>
                <text x="95.08px" y="103.622px" style="font-family:'SimplySans-Book', 'Simply Sans', sans-serif;font-size:37.5px;fill:rgb(255,255,63);">Unnecessary objects and elements</text>
            </g>
            <g id="Blue--rgb-0-255-255--Artistic-text" serif:id="Blue #rgb(0,255,255) Artistic text" transform="matrix(0.944882,0,0,0.909091,14.1732,1.81818)">
                <g transform="matrix(58.3333,0,0,58.3333,607.818,50.0094)">
                </g>
                <text x="107px" y="50.009px" style="font-family:'SimplySans-Book', 'Simply Sans', sans-serif;font-size:58.333px;fill:rgb(0,255,255);">A plethoric source</text>
            </g>
            <g id="Green-rgb-51-193-33--rectangle" serif:id="Green rgb(51,193,33) rectangle" transform="matrix(0.220472,0,0,0.233333,0,0)">
                <rect x="0" y="0" width="300" height="600" style="fill:rgb(51,193,33);"/>
            </g>
        </g>
    </g>
</svg>

Ideal SVG Source: 1555 bytes (1493 without spaces)

<svg viewBox="0 0 889 154" xmlns="http://www.w3.org/2000/svg" xml:space="preserve" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2">
  <g transform="scale(1.05833 1.1)">
    <clipPath id="a">
      <path d="M0 0h840v140H0z"/>
    </clipPath>
    <g clip-path="url(#a)">
      <path d="M774.428 41.82s33.12 18.263 33.12 26.09c0 14.4-14.84 26.09-33.12 26.09-18.279 0-33.119-11.69-33.119-26.09 0-7.827 33.119-26.09 33.119-26.09Z" style="fill:#734848" transform="matrix(.94488 0 0 .9091 76.963 -7.273)"/>
      <ellipse cx="828.307" cy="100.75" rx="60.693" ry="53.25" style="fill:#7348f2" transform="matrix(1.19876 0 0 1.31455 -195.447 -62.441)"/>
      <path d="M853.979 109.074c7.373-10.206 22.118-10.206 29.491-5.103 7.374 5.103 7.374 15.308 0 25.513-5.161 7.654-18.432 15.308-29.491 20.411-11.06-5.103-24.331-12.757-29.492-20.411-7.373-10.205-7.373-20.41 0-25.513 7.373-5.103 22.119-5.103 29.492 5.103Z" style="fill:#cc2cff" transform="matrix(.9443 0 0 .90862 -17.444 .166)"/>
      <text x="95.08" y="103.622" style="font-family:'SimplySans-Book','Simply Sans',sans-serif;font-size:37.5px;fill:#ffff3f" transform="matrix(.94488 0 0 .9091 21.976 16.388)">Unnecessary objects and elements</text>
      <text x="107" y="50.009" style="font-family:'SimplySans-Book','Simply Sans',sans-serif;font-size:58.333px;fill:#0ff" transform="matrix(.94488 0 0 .9091 14.173 1.818)">A plethoric source</text>
      <path style="fill:#33c121" d="M0 0h300v600H0z" transform="scale(.22047 .23333)"/>
    </g>
  </g>
</svg>

A comparison of the two versions highlights the overabundance of unnecessary information in the current export.

Suggested improvements

Automatic code clean-up:

1. Implement an automatic clean-up function during export to eliminate superfluous elements.
2. Export in Two Formats. Offer the option of exporting the SVG in two versions:

• Standard SVG file.
• SVG source optimized for integration into a web source.

<g id="" viewBox="0 0 889 154" transform="scale(1.05833 1.1)">
  <clipPath id="a">
    <path d="M0 0h840v140H0z"/>
  </clipPath>
  <g clip-path="url(#a)">
    <path id="Hide-maroon-rgb-115-72-72--tear" d="M774.428 41.82s33.12 18.263 33.12 26.09c0 14.4-14.84 26.09-33.12 26.09-18.279 0-33.119-11.69-33.119-26.09 0-7.827 33.119-26.09 33.119-26.09Z" style="fill:#734848" transform="matrix(.94488 0 0 .9091 76.963 -7.273)"/>
    <ellipse id="Purple-rgb-115-72-242--circle" cx="828.307" cy="100.75" rx="60.693" ry="53.25" style="fill:#7348f2" transform="matrix(1.19876 0 0 1.31455 -195.447 -62.441)"/>
    <path id="Pink-rgb-204-44-255--visible-heart" d="M853.979 109.074c7.373-10.206 22.118-10.206 29.491-5.103 7.374 5.103 7.374 15.308 0 25.513-5.161 7.654-18.432 15.308-29.491 20.411-11.06-5.103-24.331-12.757-29.492-20.411-7.373-10.205-7.373-20.41 0-25.513 7.373-5.103 22.119-5.103 29.492 5.103Z" style="fill:#cc2cff" transform="matrix(.9443 0 0 .90862 -17.444 .166)"/>
    <text id="Yellow-rgb-255-255-63--Artistic-text" x="95.08" y="103.622" style="font-family:'SimplySans-Book','Simply Sans',sans-serif;font-size:37.5px;fill:#ffff3f" transform="matrix(.94488 0 0 .9091 21.976 16.388)">Unnecessary objects and elements</text>
    <text id="Blue--rgb-0-255-255--Artistic-text" x="107" y="50.009" style="font-family:'SimplySans-Book','Simply Sans',sans-serif;font-size:58.333px;fill:#0ff" transform="matrix(.94488 0 0 .9091 14.173 1.818)">A plethoric source</text>
    <path id="Green-rgb-51-193-33--rectangle" style="fill:#33c121" d="M0 0h300v600H0z" transform="scale(.22047 .23333)"/>
  </g>
</g>

Conclusion

Implementing these improvements in Affinity Designer would enable greater compatibility with current web practices and significant performance optimization for sites incorporating SVGs. This would represent a considerable advantage for web designers using Affinity Designer.

See also:

• Iconify: https://iconly.io/tools/svg-cleaner
• SVGom: https://svgomg.net/
• SVG Minify: https://www.svgminify.com/

[bbrother]

I definitely agree with you @Pyanepsion. Export and import of svg should be significantly improved. Not just for web designers.

Adding an unwanted element like <rect> with the name of the artboard is a real tragedy for icon designers.

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:serif="http://www.serif.com/" width="100%" height="100%" viewBox="0 0 32 32" version="1.1" xml:space="preserve" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;">
    <rect id="Artboard1" x="0" y="0" width="32" height="32" style="fill:none;"/> <!--- Unwanted rect on artboards export --->
    <g id="Artboard11" serif:id="Artboard1">
        <g transform="matrix(1.66298,0,0,1.66298,-8.88398,-11.0055)">
            <circle cx="14.963" cy="16.239" r="4.811" style="fill:rgb(244,94,94);"/>
        </g>
    </g>
</svg>

I don't even want to think what someone who exported dozens icons thinked when he noticed an unwanted element like this <rect>🤯

[v_kyr]

There's room for improvements in both directions here, aka SVG output generation and SVG input parsing,

[Bit Disappointed]

I already have AI modelling such messy SVG into something usable - based on my instructions. I've also learnt a lot about SVG differences by simply asking AI about the pros and cons of its methods and comparing SVG. It's eminently helpful.

This is definitely a place where AI can be used as an option - besides the traditional tools.

[v_kyr]

3 hours ago, Bit Arts said:

I already have AI modelling such messy SVG into something usable - based on my instructions.

LOL, well until I prompt some AI correctly how to write some correct programming or SVG format code, I've done that manually by hand 10 times as fast myself. But I also know one or two things about SVG, because I used to do a lot with it in the pasts. All one usually needs is just to look into the SVG Spec and MDN SVG references. - So using an AI for SVG things is probably only useful for people which don't have any clues about it.

[Bit Disappointed]

7 minutes ago, v_kyr said:

LOL, well until I prompt some AI correctly how to write some correct programming or SVG format code, I've done that manually by hand 10 times as fast myself. But I also know one or two things about SVG, because I used to do a lot with it in the pasts. All one usually needs is just to look into the SVG Spec and MDN SVG references. - So using an AI for SVG things is probably only useful for people which don't have any clues about it.

You may dispense with the arrogance and online know-it-all attitude, which is predictable, tedious, and disconnected from my reality.

I have had professional developers quality-check and evaluate the changes before they were incorporated into the product, and the output was indeed satisfactory. I simply couldn't deliver the messy output from Affinity. My instructions are not developer instructions, but rather the purpose of the current SVG, so I get SVGs from Affinity that I can hand over to developers, who won't need to spend costly consulting time cleaning it up. Moreover, it's only on rare occasions that SVGs come from the client, but we do provide some illustrations.

The same professional supplier, with handpicked developers and talent scouts at universities, is actively integrating AI in development, optimization, and testing, and I'm talking about a supplier with billion-dollar revenue, so their considerations are far from Mickey Mouse level.

They're streamlining, I'm streamlining. It's clear to me that you can't fathom such a daily routine, workplace, and working conditions. Consequently, you can't even imagine what the standard, daily life, and job market will look like in 5 and 10 years.

[v_kyr]

10 hours ago, Bit Arts said:

You may dispense with the arrogance and online know-it-all attitude, which is predictable, tedious, and disconnected from my reality. ...

How did you've done all that before using any AI?  And how long does it take you to define an AI chat prompt, which does finally what you're exactly after and which generates then the wanted correct and optimal SVG code?

Further common AI systems do take/catch up the code for mostly all of these things from other existing example code routine sites on the net, also the examples out of the SVG specs and other hundreds from other resources they've visited. They take that stuff (as training material) from other already available code sites and do then  feed that into their DB pools. - Meaning here, they usually don't have any own real knowledge about these things, as all that is taken from other resources. So it needs more specific AI tools for that explicite coding domain.

Though lately there are some efforts done to develop & create AI coding assitent tools, which should help developers to do some of the boring dev tasks in a better, overall more time efficient way then. But those are actually more at their beginnings and dev tool vendors/providers just started to incorporate some AI based assistence into their products. - So things like for example ...

• 10 Best AI Coding Assistant Tools in 2024
• 10 Best AI Code Generators
• https://www.ibm.com/blog/ai-code-generation/
• ... and so on ...

Personally I've tried out one or two of such things which did come newly along with the development IDEs I tend to use, but since most things are there (in this/my dev domain) in very early stages, results were actually to date not that convincing. - However, things might change for the future, especially nowadays were AI is that much hyped everywhere.