Affinity Suite: Multiple SVG export anomalies

[Pyanepsion]

Hello everyone,

While exporting a very simplified text from Affinity in regular Arial, 8 pt, black), I came across several oddities in the generated SVG file. To illustrate the case, I added “absent” characters represented by a red placeholder, as well as a red rectangle.

And there you have :
- A ghost font named ArialMT (from Adobe), which doesn't exist in my source file or even on my system.
- A totally useless empty group.
- Nested transformations for no good reason. None of the transformations are useful.
- Many useless attributes.

Here's the source file (Unnecessary things in color).

<?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 1334 350" 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 transform="matrix(4.16667,0,0,4.16667,0,0)">
        <g transform="matrix(4.60446,0,0,0.45635,0,0)">
            <rect x="0" y="0" width="18.243" height="184.069" style="fill:#e43a30;"/>
        </g>
        <g id="Fonte" transform="matrix(1,0,0,1,84,2.84217e-14)">
            <text x="14px" y="31.954px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">In purus est, mattis eget, imp</text>
            <text x="150.948px" y="31.954px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text>
            <text x="161.615px" y="31.954px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">rdiet nec,</text>
            <text x="14px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">f</text>
            <text x="16.964px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text>
            <text x="27.63px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">rm</text>
            <text x="40.068px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text>
            <text x="50.734px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">ntum cong</text>
            <text x="100.542px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text>
            <text x="111.208px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">e, tortor. Aenean ut</text>
            <g transform="matrix(10.6667,0,0,10.6667,187.094,59.687)">
            </g>
            <text x="14px" y="59.687px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">nibh. Nullam hendrerit viverra mi […]</text>
        </g>
    </g>
</svg>

Here's why.

<?xml version=“1.0” encoding=“UTF-8” standalone=“no”?> <!-- Can be removed: redundant with file header. -->
<!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd”> <!-- Obsolete: useless in modern SVG files. -->

<svg
    width=“100%” height=“100%” <!-- Potentially useless: dimensions will often depend on integration via CSS. -->
    viewBox="0 0 1334 350”
    version=“1.1” <!-- Superfluous: version is implicit in modern specifications. -->
    xmlns="http://www.w3.org/2000/svg”
    xmlns:xlink=“http://www.w3.org/1999/xlink” <!-- Potentially useless: `xlink` is no longer needed in SVG 2.0. -->
    xml:space=“preserve” <!-- Unnecessary in most cases: `xml:space=“preserve”` has little effect except with intentional spaces. -->
    xmlns:serif=“http://www.serif.com/” <!-- Totally useless: no use of this namespace in the file. -->
    style=“fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;”> <!-- Potentially useless if these styles don't concern content. -->

To be more precise:

Here's a list of aspects to consider:
1. DTD usage

    Criticism:

• Use of the DTD <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd”> is obsolete and of little use in a modern context. Most browsers ignore this declaration.

    Improvement:

• Remove the DTD or simply use the XML version without DTD.

2. Inline style

    Criticism:

• The style attribute in svg and internal elements (rect, text) mixes style definitions in SVG content, making maintenance difficult.

    Improvement:

• Externalize styles in a CSS sheet or group them in a <style> tag in the SVG file to centralize styles.

3. Non-standard fonts

    Criticism:

• The style font-family:'ArialMT', 'Arial'; includes a non-standard font (ArialMT), which may not be recognized on all systems. This may cause incorrect rendering.

    Improvement:

• Use standard fonts or define reliable fallbacks (font-family: 'Arial', sans-serif;).
• If the software could also optimize the source, it would produce much smaller images that would load more quickly.

4. Inconsistent attribute values

    Criticism:

• x-positions for <text> elements use px values when other units might be more suitable (e.g. % or relative coordinates).
• Dimensions and transformations (matrix(...)) are complicated and difficult to interpret, making manual editing a pain.

    Improvement:

• Simplify transformations and use consistent units or positions to facilitate readability and maintenance.

5. Lack of descriptive tags (accessibility)

    Criticism:

• The file does not contain accessible descriptions such as <title> or <desc> tags. These tags are useful for assistive technologies (screen readers).

    Improvement:

• Add <title> and <desc> tags to describe visually represented content.

6. Unnecessary or redundant data

    Criticism:

• The namespace xmlns:serif=“http://www.serif.com/” is declared but never used.
• The <g transform=“matrix(10.6667,0,0,10.6667,214.422,59.687)”> element is empty, which seems unnecessary.

    Improvement:

• Remove unused elements or declarations to lighten the file.

7. Complex transformations

    Criticism:

• Matrix(...) transformations are complex and make subsequent modification difficult. They can also cause compatibility problems with certain viewers or tools.

    Improvement:

• Replace matrices with explicit transformations (e.g. translate, scale, rotate) where possible.

8. Fixed dimensions and lack of dynamic viewBox

    Criticism:

• The dimensions width=“100%” and height=“100%” do not guarantee correct rendering in all contexts, as they depend on the parent container.
• The viewBox is correctly defined, but its association with dynamic dimensions could be optimized.

    Improvement:

• Add explicit dimensions or use a more flexible viewBox to ensure consistent rendering.

9. Confusing hierarchical structure

    Criticism:

• The numerous <g> and <text> sub-elements make the structure unwieldy. Each word or fragment is encapsulated in a separate element, making the file difficult to manipulate or modify.

    Improvement:

• Group text in a single <text> element if possible, with <tspan> elements to handle differences in style or position.

10. Style redundancy

    Criticism:

• Each <text> element repeats the same styles (font-family, font-size, fill), making the file unwieldy.

    Improvement:

• Use classes or global styles to reduce redundancy.

11. Unnecessary inclusion of XML attributes

    Criticism:

• The xml:space=“preserve” attribute is rarely needed and could be superfluous here.

    Improvement:

• Remove it if its presence does not modify the file's behavior.

12. Longer text spans

    Criticism:

• The text of an option should not resemble a treasure hunt, but clearly describe its function. The current title, 'Longer text spans', is inappropriate, even a misnomer that can only add to the confusion. In French, the translation also adds a contradiction to the contradiction. This option actually determines whether or not <text> tags include <tspan> child tags.

    Improvement:

• A more suitable formulation would be:
  <Text> tag without <tspan> child tags. Or: <Text> tag without <tspan>
  In French :
  Balise <Text> sans balises enfants <tspan>. Or: Balise <Text> sans <tspan>

To take things a step further, here's some optimized code.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1334 350">
  <!-- Styles CSS intégrés -->
  <style>
    .svg-red { fill: #e43a30; }
    .svg-black { fill: #11161e; }
    .svg-text { font-family: Arial, sans-serif; font-size: 10.667px; }
  </style>

  <!-- Rectangle rouge -->
  <rect x="0" y="0" width="76" height="184.069" class="svg-red" />

  <!-- Textes noirs -->
  <text class="svg-text svg-black">
    <tspan x="14" y="31.954">In purus est, mattis eget, imp</tspan>
    <tspan x="161.615" y="31.954">rdiet nec,</tspan>
    <tspan x="14" y="45.82">f</tspan>
    <tspan x="27.63" y="45.82">rm</tspan>
    <tspan x="50.734" y="45.82">ntum cong</tspan>
    <tspan x="111.208" y="45.82">e, tortor. Aenean ut</tspan>
    <tspan x="14" y="59.687">nibh. Nullam hendrerit viverra mi […]</tspan>
  </text>

  <!-- Textes rouges -->
  <text class="svg-text svg-red">
    <tspan x="150.948" y="31.954"></tspan>
    <tspan x="16.964" y="45.82"></tspan>
    <tspan x="40.068" y="45.82"></tspan>
    <tspan x="100.542" y="45.82"></tspan>
  </text>
</svg>

13. Table with unnecessary transformation sequences

Criticism:

• Instead of transforming the table directly into text, and adding a grid, the software produces an unbelievable number of transformations that in reality serve no purpose except to add inaccuracies.

    Improvement:

• Avoid transformations. See discussion below

14. Character style transformed into path

Criticism:

• The Small capital character style turns text into a path and adds a <tspan> tag, the underscore becomes a rectangle, the highlight becomes a path, the apostrophe sometimes leads to the insertion of a <tspan> tag.

    Improvement:

• Avoid transformations. See discussion below.

Summary of areas for improvement

By streamlining the structure, optimizing the styles and simplifying the transformations, we could make this SVG file :

•     More readable,
•     lighter,
•     More compatible with modern tools.

By adopting these optimizations, Affinity could generate SVG files that are not only more powerful and lightweight, but also conform to modern standards, making them easier to integrate and manipulate in demanding professional workflows.

Wouldn't it be a good thing to be ahead of the game?

test-svg.afpub bad-font.svg

[walt.farrell]

Is that .afpub file your original .afpub file (from which you generated the SVG originally), or is it the result of Opening the SVG in Publisher?

That "obj" indication should mean you have an object pinned in the original text, but we would need the original .afpub file to see where you started.

[Pyanepsion]

I'm not sure I understand your request. I've provided the original AFPUB file, the SVG image produced, the SVG source code generated with my comments, and a proposal for an optimized version of the source code.
I'd like to take advantage of your request to add a twelfth point.

[bbrother]

17 hours ago, Pyanepsion said:

Wouldn't it be a good thing to be ahead of the game?

Huh, what? Affinity is lagging behind in advanced SVG export options and should catch up.

FYI Adobe Illustrator has had an option to e.g. use inline CSS (in the <style> tag) in SVG since at least CS6, which was released in May 2012.

[Pyanepsion]

13. Tables

Tables also produce numerous unnecessary transformation artifacts, often one per row. These serve no functional purpose and significantly increase the file size.

<g transform="matrix(10.6667,0,0,10.6667,125.09,31.8289)">
</g>

At the top level, we also observe transformations that effectively cancel each other out.

<g transform="matrix(1.00318,6.93889e-18,-2.77556e-17,1.11865,-1.017,-20.8912)">
  <g transform="matrix(0.996832,0,0,0.893932,0.306381,1.98085)">
    <text x="112.043px" y="31.829px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;">A1</text>
  </g>
</g>

The result of these redundant artifacts is an SVG file that is, on average, three to five times larger. This also increases display latency, introduces significant inaccuracies due to compounded rounding, and complicates maintenance for any post-generation edits.

test-svg-table.svg test-svg-table.afpub

[walt.farrell]

On 12/17/2024 at 5:08 AM, Pyanepsion said:

I'm not sure I understand your request. I've provided the original AFPUB file, the SVG image produced, the SVG source code generated with my comments, and a proposal for an optimized version of the source code.
I'd like to take advantage of your request to add a twelfth point.

In that case, how did you create the .afpub file, and how did you get that "obj" into the text? It must have come from somewhere. Was it a conversion of some other file, copy/paste, or ???

[Pyanepsion]

@walt.farrell,

Thanks for your insight. I think I understand what you’re referring to! You’re probably talking about the  symbol. This character corresponds to the Unicode U+FFFC, called Object Replacement Character. It’s used to represent objects embedded or anchored in a text stream when they can’t be displayed directly.

It’s a standard character often, and certainly always found in all well-designed fonts.

It precedes �, the Unicode character U+FFFD, called Replacement Character. The latter is used to indicate that a character is absent from the font used, or that it cannot be displayed due to inappropriate encoding. If it doesn’t exist in a font, it means that the font is really badly designed. In practice, it’s best to avoid using such a font, as it may cause similar problems elsewhere.

To answer your question more precisely, this U+FFFC character appeared in the AFPUB file during a simple manual insertion of the character, carried out for didactic purposes, to check whether it passed the export test.

PS: I haven’t yet tested the use of anchored objects with SVG files. Do you think such use would be relevant in this specific format?

[Pyanepsion]

14. Character style

The font style Small capital should produce a reduced-size capital text, but instead there's a path whose place is reserved by a <tspan>.

Underline often produces a rectangle, and sometimes a path.

The apostrophe sometimes produces a <tspan>, but I don't know why.

<!-- Vulputate, and others -->
<path d="M234.686,19.098l-2.411,5.922l-1.032,0l-2.349,-5.922l1.047,0l1.61,4.303c0.027,0.072 0.052,0.138 0.072,0.197c0.021,0.059 0.04,0.118 0.058,0.175c0.017,0.057 0.033,0.114 0.047,0.172c0.014,0.057 0.029,0.12 0.047,0.19l0.01,-0c0.028,-0.122 0.059,-0.241 0.094,-0.359c0.034,-0.119 0.078,-0.244 0.13,-0.375l1.687,-4.303l0.99,0Z" style="fill:#11161e;fill-rule:nonzero;"/>
<path d="M240.467,22.526c0,0.184 -0.008,0.375 -0.023,0.575c-0.016,0.2 -0.052,0.396 -0.11,0.589c-0.057,0.192 -0.139,0.375 -0.247,0.546c-0.108,0.172 -0.253,0.323 -0.437,0.454c-0.184,0.13 -0.412,0.233 -0.683,0.309c-0.271,0.077 -0.599,0.115 -0.984,0.115c-0.427,0 -0.785,-0.043 -1.073,-0.13c-0.288,-0.087 -0.525,-0.202 -0.711,-0.344c-0.186,-0.142 -0.327,-0.305 -0.424,-0.487c-0.098,-0.182 -0.168,-0.37 -0.211,-0.562c-0.044,-0.193 -0.068,-0.381 -0.073,-0.565c-0.006,-0.185 -0.008,-0.351 -0.008,-0.5l-0,-3.428l0.963,0l0,3.417c0,0.149 0.005,0.297 0.013,0.443c0.009,0.146 0.03,0.284 0.063,0.414c0.033,0.13 0.082,0.252 0.146,0.364c0.064,0.113 0.151,0.211 0.26,0.292c0.11,0.082 0.244,0.145 0.404,0.19c0.16,0.045 0.354,0.068 0.583,0.068c0.358,-0 0.642,-0.043 0.852,-0.128c0.21,-0.085 0.369,-0.205 0.476,-0.362c0.108,-0.156 0.176,-0.343 0.206,-0.56c0.03,-0.217 0.044,-0.457 0.044,-0.721l0,-3.417l0.974,0l0,3.428Z" style="fill:#11161e;fill-rule:nonzero;"/>
<path d="M245.926,25.02l-3.922,0l-0,-5.922l0.968,0l0,5.089l2.954,-0l-0,0.833Z" style="fill:#11161e;fill-rule:nonzero;"/>
<path d="M246.983,19.098l2.354,0c0.413,0 0.769,0.04 1.068,0.118c0.298,0.078 0.543,0.193 0.734,0.346c0.191,0.153 0.332,0.341 0.422,0.565c0.09,0.224 0.135,0.482 0.135,0.774c0,0.26 -0.043,0.505 -0.13,0.734c-0.087,0.229 -0.223,0.43 -0.409,0.604c-0.185,0.174 -0.422,0.311 -0.711,0.412c-0.288,0.1 -0.633,0.151 -1.036,0.151l-1.458,-0l-0,2.218l-0.969,0l-0,-5.922Zm0.969,2.87l1.312,0c0.479,0 0.839,-0.08 1.078,-0.242c0.24,-0.161 0.36,-0.428 0.36,-0.799c-0,-0.198 -0.034,-0.362 -0.102,-0.49c-0.068,-0.128 -0.164,-0.23 -0.289,-0.305c-0.125,-0.074 -0.278,-0.126 -0.458,-0.156c-0.181,-0.029 -0.384,-0.044 -0.61,-0.044l-1.291,-0l-0,2.036Z" style="fill:#11161e;fill-rule:nonzero;"/>
<path d="M257.832,22.526c-0,0.184 -0.008,0.375 -0.024,0.575c-0.015,0.2 -0.052,0.396 -0.109,0.589c-0.057,0.192 -0.14,0.375 -0.247,0.546c-0.108,0.172 -0.254,0.323 -0.438,0.454c-0.184,0.13 -0.411,0.233 -0.682,0.309c-0.271,0.077 -0.599,0.115 -0.985,0.115c-0.427,0 -0.784,-0.043 -1.072,-0.13c-0.289,-0.087 -0.526,-0.202 -0.711,-0.344c-0.186,-0.142 -0.328,-0.305 -0.425,-0.487c-0.097,-0.182 -0.167,-0.37 -0.211,-0.562c-0.043,-0.193 -0.068,-0.381 -0.073,-0.565c-0.005,-0.185 -0.008,-0.351 -0.008,-0.5l0,-3.428l0.964,0l-0,3.417c-0,0.149 0.004,0.297 0.013,0.443c0.009,0.146 0.03,0.284 0.063,0.414c0.032,0.13 0.081,0.252 0.145,0.364c0.065,0.113 0.151,0.211 0.261,0.292c0.109,0.082 0.244,0.145 0.403,0.19c0.16,0.045 0.355,0.068 0.584,0.068c0.357,-0 0.641,-0.043 0.851,-0.128c0.21,-0.085 0.369,-0.205 0.477,-0.362c0.108,-0.156 0.176,-0.343 0.206,-0.56c0.029,-0.217 0.044,-0.457 0.044,-0.721l-0,-3.417l0.974,0l-0,3.428Z" style="fill:#11161e;fill-rule:nonzero;"/>
<path d="M263.78,19.932l-2.026,-0l-0,5.088l-0.959,0l0,-5.088l-2.005,-0l0,-0.834l4.99,0l-0,0.834Z" style="fill:#11161e;fill-rule:nonzero;"/>

test-svg-style.afpub test-svg-style.svg

[walt.farrell]

On 12/18/2024 at 5:27 PM, Pyanepsion said:

PS: I haven’t yet tested the use of anchored objects with SVG files. Do you think such use would be relevant in this specific format?

Thanks for the details of how the character got there. I was guessing the problem might be that you were using some pinned object that couldn't be (or at least wasn't being) handled properly in the SVG export. But it sounds like that won't be related to your issue. Sorry.

I have no idea whether (or in what ways) that function might apply in exporting SVG files.