Text divided when exporting to SVG in Designer

[Cédric M]

Hi,

is it normal that my text is divided into several small parts when I export my work to an SVG file in Affinity Designer? I'd like to keep it easily editable even after the export and right it, this is making it complicated. I've also noticed the creation of groups around my text when opening an SVG file

Is there an option that I would have missed to cancel that behaviour? 

 

Thanks,

[v_kyr]

Hi,

did you used the RETURN (newline) key when entering the text, so that graphictext was like a block, aka a text line <return> then another text line etc. ?

[sfriedberg]

@v_kyrI am pretty sure I've seen the behavior he's talking about, and it has nothing at all to do with line breaks.  Because it didn't matter to me, I didn't look into it, but I got the impression that every place kerning or any other sort of metric adjustment was applied, that little chunk of text (often just one character) was broken out into a whole SVG element.  But it was more complicated than that, because not everything got exactly the same treatment.

As Cédric said, it's pretty much useless for any editing purpose.  Write-only or display-only SVG, if you will.

[v_kyr]

For plain graphicstext I can reproduce that when using line breaks in inserted text, here especially when you write then ...

t

h

i

n

g

s

... like ...

t

h

i

s

[Cédric M]

10 hours ago, v_kyr said:

Hi,

did you used the RETURN (newline) key when entering the text, so that graphictext was like a block, aka a text line <return> then another text line etc. ?

Hi. I did, but from what I see this option is just minimizing the code and I don't think that's the reason of my issue here. I tried to uncheck this option and it added a lot of <tspan>

For example, the SVG code from an Inkscape SVG file was

 

<text
    xml:space="preserve"
    style="font-size:4.23333311px;line-height:1.25;font-family:'Segoe UI';-inkscape-font-specification:'Segoe UI';text-align:center;opacity:1;vector-effect:none;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
    x="329.70169"
    y="328.74991"
    id="labelConsoChateau1"
    inkscape:label="labelConsoChateau1">
    <tspan
         id="tspan4644"
         sodipodi:role="line"
         x="329.70169"
         y="328.74991"
         style="font-size:4.23333311px;line-height:1.25;font-family:'Segoe UI';-inkscape-font-specification:'Segoe UI';text-align:center;vector-effect:none;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1">Château 1</tspan></text>

was converted to 

<g id="labelConsoChateau1">
    <g>
        <text x="931.07px" y="1120.6px" style="font-family:'SegoeUI', 'Segoe UI', sans-serif;font-size:16px;">Châte</text>
    </g>
    <g>
        <text x="971.96px" y="1120.6px" style="font-family:'SegoeUI', 'Segoe UI', sans-serif;font-size:16px;">au 1</text>
    </g>
</g>

after some modification in Affinity

I also found that the ids from the text are often put to a parent group created by Affinity during the export

[v_kyr]

4 hours ago, Cédric M said:

For example, the SVG code from an Inkscape SVG file ...

Ah Ok you imported Inkscape generated SVG into Affinity then and so didn't created the text in Affinity itself. - That way (Inkscape to Affinity) it depends on if and how the Affinity SVG parser interprets and sets up certain SVG tokens like the <tspan>.

• SVG <tspan>

[Cédric M]

Yes I did understand that but, since SVGs are made from xml (which is supposed to be kind of "universal" unlike the .afdesign format), I would expect it to behave the same way no matter how it is generated. As you can see, my text didn't have anything special inside of it so the expected behaviour would be to keep the text in a single <text> tag, not generating unnecessary groups

I understand that program compatibility can be a bit difficult (especially since Inkscape adds its own attributes to the tags) but it's only when exporting that the groups are created so maybe there's a way to avoid that behaviour?

[v_kyr]

17 hours ago, Cédric M said:

... I would expect it to behave the same way no matter how it is generated. ...

NO as said this highly depends on the capabilities of the used SVG parser and for output (code generation) also on the SVG code generator part. Affinity doesn't seem to have a build-in full blown SVG syntax parser (like most Webbrowsers have), there are a bunch of SVG syntax things it doesn't handle at all, or instead in some strange/wrong manner.

For example, a plain MDN SVG sample like 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 viewBox="0 0 240 40" xmlns="http://www.w3.org/2000/svg">
  <style>
    text  { font: italic 12px serif; }
    tspan { font: bold 10px sans-serif; fill: red; }
  </style>

  <text x="10" y="30" class="small">
    You are
    <tspan>not</tspan>
    a banana!
  </text>
</svg>

... will be imported (shown up) nearly the right way, but is treated internally differently when exported (code generated) ...

<?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 240 40" 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(1,0,0,1,10,30)">
	<text x="0px" y="0px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:16px;">Y
		<tspan x="9.203px 18.102px " y="0px 0px ">ou</tspan> are</text>
	<text x="59.016px" y="0px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:16px;fill:#f00;">not</text>
	<text x="85.703px" y="0px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:16px;">a banana!</text>
</g>
</svg>

... look after the intial <tspan>not</tspan> placement for "not" and what Affinity generates instead (<tspan>ou</tspan>) etc. How it looks in contrast to the initial code here, it's more like a generation mess up instead.

[Cédric M]

Thanks for your answer. As my colleagues cannot choose to work with Affinity, I'm gonna have to work with Inkscape too then. I hope this will be improved in the future