Jump to content

Imported svg file looks not as supposed to


Recommended Posts

Hej everybody,

I am new to Affinity Designer and I struggle with my first project in it at the first step: importing a svg file.

I have a svg file and opened it in Affinity Designer. Somehow it does not look like it is supposed to be. The programme changed essential designs by itself, namely: The elements have hard edges instead of round ones, the text is splitted into text fields per line instead of a complete text frame. 

Here you can see how the graphic should look like: graphic_supposed_to_be.png

And this is what I get in Affinity Designer: graphic_i_get.png (I have marked one line so that you can see better what I mean)

Please help me with this issue :)

Thanks so much in advance!

graphic_suppoed_to_be.png

graphic_i_get.png

Link to comment
Share on other sites

Looks like that has been initially created in PowerPoint (PPT) ...

... just saw PNG versions of that one on the net so far.

However, I can image if this is indeed initially created via PPT (?) and then converted over from that to SVG, that some SVG commands and definitions might not be parsed in by AD since it's SVG engine probably doesn't support those. - SVG text is often split/divided into parts when parsed in by the Affinity SVG parser engine.

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

Thanks for your answers so far! I received the svg file from the author of the graphic. I am not sure in which programme the author has composed the file originally. The strange thing is, that when I use Inkscape on linux the file looks just as supposed to be :/ 

I attach the svg-file and hope for more advice, thanks in advance!

Calling people citizen science names figure VECTOR FILE_clean.svg

Link to comment
Share on other sites

6 minutes ago, Sue1 said:

I am not sure in which programme the author has composed the file originally.

The header of the file says it was created with Inkscape. I opened the document OK in Illu CS6, saved it and this version was looking good in AD. Really sad to say, that compared to the competitors the SVG support in AD is weak. Is SVG not well documented, so that it is difficult to implement a proper import / export?

Right now I have to use Inkscape / Illu if I need SVG files. Or using an online converter to PDF.

------
Windows 10 | i5-8500 CPU | Intel UHD 630 Graphics | 32 GB RAM | Latest Retail and Beta versions of complete Affinity range installed

Link to comment
Share on other sites

1 hour ago, Joachim_L said:

Really sad to say, that compared to the competitors the SVG support in AD is weak

Indeed

Affinity doesn't parse svg rounded rectangles. A random example from the file:
<rect
ry="14.182739" y="436.88196" x="-221.91631" height="46" width="42"
id="rect3285-35-8" style="color:#000000;display:inline;overflow:visible;visibility:visible;fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker:none;enable-background:accumulate" />
which is correct xml but Affinity doesn't understand the ry value and displays as a <rect>

If you produce a rounded rectangle from Affinity as an svg it will just be a path, which works but is hardly in the spirit of the standard

A quick and dirty method is to 
open the svg in Chrome
print to a pdf
open in Affinity
Note that there are additional objects in the original file not on the canvas and they will be lost

An alternative is to open the file in a proper svg editor and convert all the objects to paths. File size goes through the roof but you can't have everything

Calling people citizen science names figure VECTOR FILE_cleanAsPath.svg

Microsoft Windows 10 Home, Intel i7-9750H CPU @ 2.60GHz, 16 GB RAM, 500GB SSD, 1TB Whirlygig, NVIDIA GeForce RTX 2060
Affinity Photo - 24/05/20, Affinity Publisher - 06/12/20, KTM Superduke - 27/09/10

Link to comment
Share on other sites

43 minutes ago, BofG said:

Affinity is ignoring the "ry" property that sets the radius of the rectangle's corner(s).

 

42 minutes ago, David in Яuislip said:

Affinity doesn't parse svg rounded rectangles. A random example from the file: ...

Well, the fact is slightly different in this case. Affinity knows to parse rounded rects, but it will need both a "rx" and "ry" value in order to perform this. - So it always needs a complete rect definition here (with rx and ry values), if the "rx" is omitted and just an "ry" is defined, it won't perform a rounding here on a rect!

The following SVG example code would be parsed in AD correctly here ...

<?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 800 600" 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;">
	
    <rect x="300" y="300" rx="14.182739" ry="14.182739" height="46" width="42" id="rect3285-35-8" style="color:#000000;display:inline;overflow:visible;visibility:visible;fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker:none;enable-background:accumulate" />

    <rect x="50" y="20" rx="20" ry="20" width="150" height="150" style="fill:red;stroke:black;stroke-width:5;opacity:0.5" />
</svg>

 

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

8 minutes ago, v_kyr said:

 

Well, the fact is slightly different in this case. Affinity knows to parse rounded rects, but it will need both a "rx" and "ry" value in order to perform this. - So it always needs a complete rect definition here (with rx and ry values), if the "rx" is omitted and just an "ry" is defined, it won't perform a rounding here on a rect!

The following SVG example code would be parsed in AD correctly here ...


<?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 800 600" 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;">
	
    <rect x="300" y="300" rx="14.182739" ry="14.182739" height="46" width="42" id="rect3285-35-8" style="color:#000000;display:inline;overflow:visible;visibility:visible;fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker:none;enable-background:accumulate" />

    <rect x="50" y="20" rx="20" ry="20" width="150" height="150" style="fill:red;stroke:black;stroke-width:5;opacity:0.5" />
</svg>

 

Well spotted. The W3 set out an algorithm for use of the rx/ry values:

https://www.w3.org/TR/SVG11/shapes.html#RectElement

but Affinity does it "it's own way".

Link to comment
Share on other sites

23 minutes ago, v_kyr said:

Affinity knows to parse rounded rects, but it will need both a "rx" and "ry" value in order to perform this.

Interesting, thanks for that but it just demonstrates Affinity not complying with the std as it shouldn't need both

Even worse, from your example above, it looks fine in Photo but when it's exported as svg you get this

<?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 800 600" 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;">
    <path id="rect3285-35-8" d="M342,314.183C342,306.355 335.645,300 327.817,300L314.183,300C306.355,300 300,306.355 300,314.183L300,331.817C300,339.645 306.355,346 314.183,346L327.817,346C335.645,346 342,339.645 342,331.817L342,314.183Z" style="fill:white;stroke:black;stroke-width:2px;"/>
    <use xlink:href="#_Image1" x="47.5" y="17.5" width="155px" height="155px"/>
    <defs>
        <image id="_Image1" width="155px" height="155px" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAJsAAACbCAYAAAB1YemMAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAF1klEQVR4nO3bwWsUVxzA8a9r6sFkRTzUGOuppQbUi1oQRaX3gh56sBS8FFranuof4MF7S4+tR08eLFX6FygoAaNCtaBFoWBZTU/SJFJiGnp42XR38ia7mzg/dfL9QNDMm928w5eZeTO7G1i7LcD7wBjQ7PjZ/BLeW6/Gc2C646cFPFj8/6ptWOXrtgL7gHFSZFofWsB94C7wbNAXDxrbMHAMOAg0Bv1jqo0FYBK4SjoK9qXf2IaAw8ARYNPAU1NdzQHXgRvAfK+d+4mtCZzC06XKtYCL9Lim6xXbTlJoIyvttBc4QTq3jgE7gFHgrT5nqtfHC+Ap8IRU0CRwBbjX+6XTpOBaZTusFNtu4GPSKXSZEeAMcBp4t/dE9IZ7BFwAvgVmy3ebBy6RVq7LbCx50U7gUzKhDQFfAj8BHwHb+p+v3mDbgA+Bz0grgjukVUJBg3SH4hGZU2ruyNYEPidz6hwFfgYOrXrKqosJ4CQwlR+eAc5TCK54+2KIkmu0/cBNDE3JIVIP+/PDI6SOus6MxdgOk1l17geuAe+sfY6qkV2kLkqCGyP1tKQztmHSfbQuo6TVyPBLmqDqZRi4DGzPDx+h47FlZ2zHKNywHSJdo3lE00p2kYLL3LbYBBxv/9KObSvpNlmXL/AaTf05RFpVZhwk9bUU2z4K128jwNnKpqY6Okv27n+D1NdSYOPFPc4Ab1c3L9XQduCb/NA4pNi2kFmBnq5wUqqvkm7GgGaD9MHHLnvxEZRW5z1gT35od4PMUe1EtfNRzZ3Mbx5rkB5PdVm2LJUGcCC/uZmNzQ+uaS1K+snHtqPiyajeSmIbaZD5FtRoxZNRvZX0M5z90oqfsNValPXjN6QUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUxtgUJhvbi+hZqFbmSrY3gOfFjU+rnYtqrqSf2QYwXdz6pOLJqN5K+pnOxtaqeDKqt5J+ZrKxTVY8GdXbrfzm6QaZEK9UPBnV2+X85lYD+L249R7wqNr5qKYeAr/lhx40gL/JHN0uVDol1VVJNy0WT6MA94uj3wF/VTYl1dEUqZuM+/D/Td27wELn6Axwrrp5qYbOAbPLNy+Q+lqK7RmZReiPwERlU1OdTADn80OTpL66Hlddo/CkYR44CfxZxexUG49JncwvH5oDrrZ/6YxtFrhe3HsKOEH28CgxSwptKj98nY7HocUH8TfIrExvA8fwCKduj4GjpD4yWqSelhRjmwcuktYHXW4DB/EaTskE8AFwJz88Teqo68ya+4hRdkdIh8qjwNeUHjZVc1PAV6QOShpoH7CWPQbdWPKe06TbbOMUglwAbgI/AP8Au4Btq5m13igPge+BT0jnxoX8bvPAJeCP3OCGHn9jbPH9R1baaQ/pIvHA4gt2AKPAph5vrtfPHOnzaE9IF123SM86Sx5BdWqfEUs/NNQrNoAmcIrUkZTTouTU2ansNNppDvgV+BfY2edrtD7Mke7P/kK6qlpRP0e2TpuB46SFqV+WWb/al+7XyHytoMygsbVtBfaRFhCeXtePFumh+l0WH0ENYrWxdWoCu0nRNUmLiSYw/BLeW6/GLOn6a2bx3xbwgB7XZL38B5uOz5/xsPD5AAAAAElFTkSuQmCC"/>
    </defs>
</svg>

Madness

Microsoft Windows 10 Home, Intel i7-9750H CPU @ 2.60GHz, 16 GB RAM, 500GB SSD, 1TB Whirlygig, NVIDIA GeForce RTX 2060
Affinity Photo - 24/05/20, Affinity Publisher - 06/12/20, KTM Superduke - 27/09/10

Link to comment
Share on other sites

Forgotten to tell something about the text parts here in the SVG which are created via SVG <tspan> elements.

Unfortunately, it is not (yet) possible to define multi-line text in SVG. Several independent text elements have the disadvantage that they cannot be marked and selected together. However, you can use the <tspan> element to define your own areas that you can position and layout accordingly. The <tspan> element essentially corresponds to the span element in HTML and can be used anywhere within the text element. Compared to the use of several text elements, tspan offers the following advantages:

  • <tspan> elements do not have to (but can) be repositioned
  • the individual <tspan> elements belong together and can be marked together
Quote

The SVG tspan element essentially corresponds to the span element in HTML. With the tspan element you can define your own areas within the text element, which you can position and layout according to your wishes. In this way it is possible, among other things, to display several lines within a text element without having to use several of these elements. This can be important so that texts with several lines can be completely selected, e.g. to copy texts or for external applications to read texts in context. Of course, the text content of tspan elements can also be formatted independently of the parent text element, so that e.g. writing with different colored characters is possible. All attributes that may also be used for the text element are valid for the tspan element.

BTW, there are parts of the Inkscape SVG drawing which are offset outside of the doc (the SVG viewBox) boundaries, either deliberately/intentionally or accidentally ...

offset-positioned.jpg.8cf7bbc7bdf276bce1675f48f0ebd795.jpg

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

25 minutes ago, BofG said:

Well spotted. The W3 set out an algorithm for use of the rx/ry values:

https://www.w3.org/TR/SVG11/shapes.html#RectElement

but Affinity does it "it's own way".

That's right, the Affinity SVG parser doesn't take that into account, it's by far here not compliance to the SVG specs.

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

25 minutes ago, David in Яuislip said:

Even worse, from your example above, it looks fine in Photo but when it's exported as svg you get this ...

That's due to the one rect's "opacity:0.5" setting here (the rect layer has 50% opacity when shown) ...

Quote

<rect x="50" y="20" rx="20" ry="20" width="150" height="150" style="fill:red;stroke:black;stroke-width:5;opacity:0.5" />

... which Affinity generates during export via rasterization (...thus as a base64 encoded embedded bitmap image) for a SVG export! - If you define full layer opacity (aka 100%) it will export that rect as vector paths instead.

 

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

8 minutes ago, v_kyr said:

<rect x="50" y="20" rx="20" ry="20" width="150" height="150" style="fill:red;stroke:black;stroke-width:5;opacity:0.5" />

Thanks. I understand what it's doing, I just don't understand why.

The same line via Inkscape comes out thus:

<rect id="rect3" style="fill:red;stroke:black;stroke-width:5;opacity:0.5" height="150" width="150" ry="20" rx="20" y="20" x="50" />

There is no sense to rasterise anything because the opacity is less than 1

Madness

Microsoft Windows 10 Home, Intel i7-9750H CPU @ 2.60GHz, 16 GB RAM, 500GB SSD, 1TB Whirlygig, NVIDIA GeForce RTX 2060
Affinity Photo - 24/05/20, Affinity Publisher - 06/12/20, KTM Superduke - 27/09/10

Link to comment
Share on other sites

52 minutes ago, David in Яuislip said:

Thanks. I understand what it's doing, I just don't understand why.

The same line via Inkscape comes out thus:

<rect id="rect3" style="fill:red;stroke:black;stroke-width:5;opacity:0.5" height="150" width="150" ry="20" rx="20" y="20" x="50" />

There is no sense to rasterise anything because the opacity is less than 1

Madness

Affinity is just not very good at this. If you take the stroke off the rectangle, Affinity will generate a pure SVG using "fill-opacity". With the stroke in place it for some reason forgets how to do that and falls back to rasterising the object.

Link to comment
Share on other sites

55 minutes ago, David in Яuislip said:

Thanks. I understand what it's doing, I just don't understand why.

Probably since the Affinity apps use their own proprietary format, their SVG output code generator (exporter) has to map their internal routines somehow to SVG counterparts (same as their EPS generator etc.). They probably used the lowest and easiest common denominator to implement the export to vector formats here, meaning treating most blend modes and filters etc. as image parts then here.

55 minutes ago, David in Яuislip said:

The same line via Inkscape ...

Well, Inkscape is a very SVG spec conform build app (beside Webbrowsers SVG engines) and the XML based SVG is it's native file format! - So no surprise here that Inkscape easily can do so!

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

6 minutes ago, BofG said:

Affinity is just not very good at this.

🙂

If you set Rasterise to nothing in the More dialog you get

<path d="M200,40C200,28.962 191.038,20 180,20L70,20C58.962,20 50,28.962 50,40L50,150C50,161.038 58.962,170 70,170L180,170C191.038,170 200,161.038 200,150L200,40Z" style="fill:rgb(255,0,0);fill-opacity:0.5;stroke:black;stroke-opacity:0.5;stroke-width:5px;stroke-miterlimit:2;"/>

which is about as good as Affinity can do. I'd better stop now or I'll start to complain that the colours aren't in hex

13 minutes ago, v_kyr said:

Probably since the Affinity apps use their own proprietary format,

AAarrggghhh, that's illegal

Microsoft Windows 10 Home, Intel i7-9750H CPU @ 2.60GHz, 16 GB RAM, 500GB SSD, 1TB Whirlygig, NVIDIA GeForce RTX 2060
Affinity Photo - 24/05/20, Affinity Publisher - 06/12/20, KTM Superduke - 27/09/10

Link to comment
Share on other sites

19 hours ago, Sue1 said:

Please help me with this issue :)

Here is a fixed SVG code version of your initial SVG file, so Affinity Designer handles the rectangle rounding when importing the fixed SVG file. - Though since your original filename was too long for my taste I used "cpeople" here as a filename instead ...

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

Hej everyone, thank you soooo much for your help! I did not get all the coding details but at least I gained some insights which impressed me :)

Thanks @David in Яuislip for your quick solution! I appreciate this.

Thanks @v_kyr for your hint about the hidden ghosts! I have discovered them as well and I had fun in wondering why these ghosts were sent into the nowhere ;-) Your end-file is extremely helpful for me, thank you so much!

As I got from your discussion here, there is no solution for getting complete text frames with more than 1 line. So if I want to modify the text I need to create a new textframe or at least take in that I have to change it line by line, correct?

Link to comment
Share on other sites

1 hour ago, Sue1 said:

As I got from your discussion here, there is no solution for getting complete text frames with more than 1 line. So if I want to modify the text I need to create a new textframe or at least take in that I have to change it line by line, correct?

Yes, that's right here for the SVG format, which doesn't treat multi-line text let's say as flexible as Affinity can. And since you imported from a SVG file the text is shown like that in a SVG manner. - So in this case (for that sort of shown up text line groups handling) it's not Affinity's fault, but the way SVG does handle it.

In Affinity you can use it's artistic or group text tool to replace all those single line text portions just into one multi line box. That's fine for Affinity and it's own proprietary file format, but as far as you export again to the SVG format, it will be again stored in that specific SVG way, since that's how the SVG file format supports this.

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

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...
 Share

×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.