SVG import problem

[twise]

Hi,

I've recently noticed that SVG files exported from Matplotlib in Python are no long imported into Affinity Designer correctly, following a change in how Matplotlib exports SVGs. Essentially characters within text end up on top of one another rather than being spaced apart. There are no problems importing into Inkscape, Chrome, etc. suggesting the problem lies with AD.

I've pinned down the problem to how AD parses X and Y positions in SVG <use> tags - these seem to be applied before path transforms rather than after. The Matplotlib export process multiplies the <path> specification values for each text character by 64 (this makes the values integers, so the file size is smaller), then uses transform="scale(0.015625)" (1/64) to ensure they are the correct size. The placing of characters in the text field is then controlled by X and Y offsets in <use> tags. These X and Y values are not *64 like the path values, as ordinarily they are applied after the 1/64 scaling. However in AD the offsets are applied prior to transforming, resulting in them being 1/64 what they should be.

I've attached a basic example exported SVG that doesn't import correctly into AD.

svg_example.svg

[PixelPest]

Can you add a screenshot of how it should look like?

[twise]

Sure, here's my minimal example which is a lowercase L followed by a dash (should come out as l-).

This is correct, as it appears imported into Inkscape:

And this is incorrect, as it appears imported into AD:

This is the most minimal example I could come up with, but the same happens with more characters - they all end up on top of one another instead of next to each other.

[David in Яuislip]

It seems to be Affinity can't cope with the  x="27.783203"

<use x="27.783203" xlink:href="#DejaVuSans-45"/>

If it's changed to this
<use transform="translate(27.783203)" xlink:href="#DejaVuSans-45"/>

then it's ok

svg_example2.svg

[twise]

That's great, thank you! Yes, it seems like it's the use of x and y in the <use> part that Affinity doesn't handle well, but apparently it's fine if it's provided as a translation instead. It definitely seems that this is a minor issue with AD's SVG imports given other software handles it without any problems, but at least it might be possible to work around it.

[PixelPest]

I can confirm. There´s something wrong how AD interprets this stacked hierarchy of groups+clones as 5 other SVG editors + browsers don´t have issues displaying it correctly.

Unlinking the clones helps here:

svg_exampleNoClone.svg

When you compare just the XML for its content: 

Quote

<?xml version="1.0" encoding="UTF-8"?>
<svg width="152mm" height="102mm" clip-rule="evenodd" fill-rule="evenodd" version="1.1" viewBox="0 0 576 384" xml:space="preserve" xmlns="http://www.w3.org/2000/svg"><g stroke-linejoin="round">
    
<path d="m0 384h576v-384h-576z" fill="none" stroke-width="1.33"/><path d="m123 256h5.99v50.7h-5.99z" stroke-width=".0104"/><path d="m138 286h17.5v5.33h-17.5z" stroke-width=".0104"/></g></svg>

the original SVG is quite messy. 430 Byte vs 2217 Byte. 😉

TestSVGopt.svg

[Wosven]

It should be added to the bug section, so they can correct it.

[twise]

Thanks all for your help! I'll report it as a bug.