SVG Import has a bug in all three apps on Windows

[Michael Collins]

1. Are you using the latest release version? YES 1.10.5.1342
2. Can you reproduce it? YES
   Does it happen for a new document? If not can you upload a document that shows the problem? Doc included
3. If you cannot provide a sample document then please give an accurate description of the problem for example it should include most of the following:

• What is your operating system and version (Windows 10, OSX Mojave, iOS 12 etc)?
  Windows 10.0.1.19043
• Is hardware acceleration (in Preferences > Performance) ON or OFF ? (and have you tried the other setting?)
  tried OFF and ON
• What happened for you (and what you expected to happen)
  The importation of text in an SVG does not properly support the alignment-baseline attribute and my text is placed at the wrong Y coordinate
• Provide a recipe for creating the problem (step-by-step what you did).
  The SVG that I have placed at the bottom of this message does not import correctly into Photo, Publisher or Designer. The Y coordinate is in the wrong place
• Screenshots (very handy) or a screen capture/video.
  Attached

SVG Source code:

<svg width="612" height="792" viewBox="0 0 612 792" xmlns="http://www.w3.org/2000/svg">
  <rect x="0" y="0" width="612" height="792" fill="#FFFFFF" stroke="#000000" stroke-width="1"/>
  <rect x="36" y="36" width="36" height="36" fill="#DDDDFF" stroke="#000066" stroke-width="1"/>
  <path d="M 36 36 L 100 160 Q 130 200 150 120 C 190 -40 200 200 300 150 L 400 90 z" fill="none" stroke="black" stroke-width="2"/>
  <path d="M 100 100 L 200 100 L 150 200 z" fill="white" stroke="#00FFFF" stroke-width="1"/>
  <text x="36" y="36" alignment-baseline="hanging" font-family="Times New Roman" font-size="48" font-weight="bold" fill="red">This is a test!</text>
  <text x="36" y="36" alignment-baseline="hanging" font-family="Times New Roman" font-size="24" font-weight="bold" fill="green">This is a test!</text>
  <text x="36" y="36" alignment-baseline="hanging" font-family="Times New Roman" font-size="12" font-weight="bold" fill="blue">This is a test!</text>
</svg>

I have tested all of the alignment-baseline values and found several where your apps do not follow the rules. I am including several images that show the SVG in Chrome, Edge and Firefox as well as in Designer. (To test the different values change the value of alignment-baseline="hanging" to the each entry in the list of failing options at the end of this message)

I will add that Firefox also seems to import these incorrectly.

I have also tested these SVGs in Photo and Publisher and I assume you have the same import code for all three since they do the same things.

Here is the link that describes how alignment-baseline is supposed to work
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/alignment-baseline

List of values that are failing:

• mathematical
• hanging
• central
• text-before-edge
• middle
• baseline

There may be others that depend on parent relationships, but this SVG does not dive that deep.

Mike Collins

CENTRAL

 

HANGING

 

MATHEMATICAL

 

MIDDLE

 

TEXT-BEFORE-EDGE

Edited June 22, 2022 by Michael Collins
Adding labels to images.

[Michael Collins]

I added dominant-baseline="hanging" into the <svg> tag and now Firefox works correctly but your import still does not. See attached file.

 

Edited June 22, 2022 by Michael Collins
simplify language

[Michael Collins]

Here is another reference for you to use to help correct your import bug:
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/dominant-baseline

 

They supply this SVG code:
 

<svg width="400" height="300" viewBox="0 0 300 300"
    xmlns="http://www.w3.org/2000/svg">

  <!-- Materialization of anchors -->
  <path d="M60,20 L60,270
           M30,20 L400,20
           M30,70 L400,70
           M30,120 L400,120
           M30,170 L400,170
           M30,220 L400,220
           M30,270 L400,270" stroke="grey" />

    <!-- Anchors in action -->
    <text dominant-baseline="auto" x="70" y="20">auto</text>
    <text dominant-baseline="middle" x="70" y="70">middle</text>
    <text dominant-baseline="hanging" x="70" y="170">hanging</text>
    <text dominant-baseline="mathematical" x="70" y="220">mathematical</text>
    <text dominant-baseline="text-top" x="70" y="270">text-top</text>

  <!-- Materialization of anchors -->
  <circle cx="60" cy="20" r="3" fill="red" />
  <circle cx="60" cy="70" r="3" fill="red" />
  <circle cx="60" cy="120" r="3" fill="red" />
  <circle cx="60" cy="170" r="3" fill="red" />
  <circle cx="60" cy="220" r="3" fill="red" />
  <circle cx="60" cy="270" r="3" fill="red" />

  <style><![CDATA[
  text {
    font: bold 30px Verdana, Helvetica, Arial, sans-serif;
  }
  ]]></style>
</svg>

It it should produce the same as the browsers in the attached image.

This also shows another problem where your import does not handle using styles in the SVG.

 

Edited June 22, 2022 by Michael Collins

[Lee_T]

Hi Michael, welcome to the forums, 

would you mind please including a set of your svg files for each problem?

Lee

[Michael Collins]

I did include the SVG files as text in my previous posts. You can just copy the code out and save it as a file.

And I am including the second example since it shows more of the errors. This is the same as what I have in my previous post.

It includes a style for the font and the dominant-baseline set to `auto`, `middle`, `hanging`, `mathematical` and `text-top`.

The result should look like the image below.

example.svg

[Lee_T]

Thanks, this has been reported.

 

Lee

[Michael Collins]

Thanks Lee. 

[BR22]

Hello

I also have an SVG loading bug, not sure if it is the same issue, or maybe could be useful to diagnose the problem. I am using the latest Designer and Photo version on Windows 11 Pro 21H2. The SVG takes minutes to load and when it does, some elements in the image are not in the correct location. Browsers load this instantly and correctly.

Coat_of_arms_of_the_U.S._10th_Cavalry_Regiment_with_external_ornament.svg

[Komatös]

I can confirm this. Opening takes around 3 minutes in Designer and is faulty. Inkscape opens the file practically within half a second, error-free.

[Old Bruce]

The SVG seems to have been made with something called Sodipodi, Inkscape's predecessor. That software was last updated 18 years ago.

[v_kyr]

On 6/24/2022 at 8:37 PM, BR22 said:

I also have an SVG loading bug, not sure if it is the same issue, or maybe could be useful to diagnose the problem.

No it's not the same issue, but other ones. - The supplied file is in Inkscape SVG format (with a bunch of Inkscape related SVG meta data & preprocessor settings etc.), but even if that file would be exported instead as an plain SVG 1.1 from Inkscape, Affinity will take that long time to open that at all and in a faulty manner.

So what probably is the problem here with that SVG file is, even the Affinity SVG parser can partly handle the SVG <use> (but not with all possible parameter options) and <radialGradient> commands, it won't handle all the supplied SVG <use> & <clipPath>'s the right way and also doesn't know how to deal at all with a SVG <pattern> !

As some simpler examples, see & try out the following in a webbrower like FF and in ADe, open the examples in both for comparison ...

1) Should work

<svg viewBox="0 0 300 200" xmlns="http://www.w3.org/2000/svg">
<defs>
    <clipPath id="clipPath3">
        <path d="M10,10 q60,60 100,0 q50,50 50,50 l40,0 l-40,40 l-100,-20"/>
    </clipPath>
</defs>

<rect x="5" y="5" width="190" height="90" style="stroke: none; fill:#00ff00; clip-path: url(#clipPath3);"/>
</svg>

• test_clippath1.svg

 

2) Won't work, a circle is inner part of the clippath

<svg viewBox="0 0 20 20" xmlns="http://www.w3.org/2000/svg">
  <clipPath id="myClip" clipPathUnits="objectBoundingBox">
    <circle cx=".5" cy=".5" r=".5" />
  </clipPath>

  <!-- Top-left: Apply a custom defined clipping path -->
  <rect x="1" y="1" width="8" height="8" stroke="green"
        clip-path="url(#myClip)" />

  <!-- Top-right: Apply a CSS basic shape on a fill-box
       geometry. This is the same as having a custom clipping
       path with a clipPathUnits set to objectBoundingBox -->
  <rect x="11" y="1" width="8" height="8" stroke="green"
        clip-path="circle() fill-box" />

  <!-- Bottom-left -->
  <rect x="1" y="11" width="8" height="8" stroke="green"
        clip-path="circle() stroke-box" />

  <!-- Bottom-right: Apply a CSS basic shape on a view-box
       geometry. This is the same as having a custom clipping
       path with a clipPathUnits set to userSpaceOnUse -->
  <rect x="11" y="11" width="8" height="8" stroke="green"
        clip-path="circle() view-box" />
</svg>

• test_clippath2.svg

 

3) Won't work, a rect is inner part of the clippath

<svg viewBox="0 0 200 100" xmlns="http://www.w3.org/2000/svg">
<defs>
      <clipPath id="clipPath">
          <rect x="15" y="15" width="40" height="40" />
      </clipPath>
  </defs>

  <circle cx="25" cy="25" r="20"
          style="fill: #0000ff; clip-path: url(#clipPath); " />
</svg>

• test_clippath3.svg

 

4) Won't work, pattern not handled

<svg viewBox="0 0 230 100" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <pattern id="star" viewBox="0,0,10,10" width="10%" height="10%">
      <polygon points="0,0 2,5 0,10 5,8 10,10 8,5 10,0 5,2"/>
    </pattern>
  </defs>

  <circle cx="50"  cy="50" r="50" fill="url(#star)"/>
  <circle cx="180" cy="50" r="40" fill="none" stroke-width="20" stroke="url(#star)"/>
</svg>

• test_pattern1.svg

 

5) Won't work, pattern not handled

<svg width="100%" height="100%" viewBox="0 0 400 240" xmlns="http://www.w3.org/2000/svg">
    <pattern id="simple-dots" x="0" y="0" width="20" height="20" patternUnits="userSpaceOnUse">
        <circle fill="#aaa" cx="10" cy="10" r="4" />
    </pattern>
    <rect width="400" height="240" fill="url(#simple-dots)" />
</svg>

• test_pattern2.svg

 

6) Won't work correctly, <use> not handled right here, it's off-positioned

<svg
   width="600.07758"
   height="1119.4221"
   viewBox="-300 -295 600.07758 1119.4221"
   version="1.1"
   id="svg27"
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:dc="http://purl.org/dc/elements/1.1/">
   <defs
     id="defs13">
    <radialGradient
       id="Gradient1"
       gradientUnits="userSpaceOnUse"
       cy="-80"
       cx="-75"
       r="405">
      <stop
         stop-color="#fff"
         stop-opacity=".31"
         offset="0"
         id="stop2" />
      <stop
         stop-color="#fff"
         stop-opacity=".25"
         offset=".19"
         id="stop4" />
      <stop
         stop-color="#6b6b6b"
         stop-opacity=".125"
         offset=".6"
         id="stop6" />
      <stop
         stop-opacity=".125"
         offset="1"
         id="stop8" />
    </radialGradient>
    <clipPath
       id="shield_cut">
      <path
         id="shield"
         d="m -298.5,-293.5 h 597 v 517 a 70,70 0 0 1 -70,70 H 70 a 70,70 0 0 0 -70,70 70,70 0 0 0 -70,-70 h -158.5 a 70,70 0 0 1 -70,-70 z"
         style="stroke-linecap:round;stroke-linejoin:round" />
    </clipPath>
    </defs>

    <g
     id="layer4"
     clip-path="url(#shield_cut)"
     style="stroke:#000000;stroke-width:3"
     transform="translate(0.03877601,459.44324)">
    <rect
       x="-300"
       y="-295"
       width="300"
       height="660"
       id="rect15"
       style="fill:#ffffff" />
    <rect
       style="opacity:1;fill:#2b5df2;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
       id="rect838"
       width="300"
       height="194.60242"
       x="-300"
       y="-293.5"
       rx="1.90099"
       ry="1.75476" />
    <rect
       style="opacity:1;fill:#e20909;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
       id="rect848"
       width="20"
       height="396.8389"
       x="-273"
       y="-98.946892"
       rx="1.90099"
       ry="1.7547599" />
    <use
       x="0"
       y="0"
       xlink:href="#rect848"
       id="use850"
       transform="translate(45.199997)"
       width="100%"
       height="100%" />
    <use
       x="0"
       y="0"
       xlink:href="#use850"
       id="use852"
       transform="translate(45.199997)"
       width="100%"
       height="100%" />
    <use
       x="0"
       y="0"
       xlink:href="#use852"
       id="use854"
       transform="translate(45.199997)"
       width="100%"
       height="100%" />
    <use
       x="0"
       y="0"
       xlink:href="#use854"
       id="use856"
       transform="translate(45.199997)"
       width="100%"
       height="100%" />
    <use
       x="0"
       y="0"
       xlink:href="#use856"
       id="use858"
       transform="matrix(1,0,0,1.038266,45.199997,3.786303)"
       width="100%"
       height="100%"
       style="stroke-width:2.94419742" />
  </g>
</svg>

• test_use2.svg

 

[Michael Collins]

Any updates on the original bug I reported? I'm really anxious for the fix.

[GarryP]

Serif generally don’t tell us what their plans are other than with release notes for updates when they arrive.

The reasonable things we can do are:

• check to see if we are using the latest version of the software;
• install the latest version if we are not using the latest version;
• check to see if that does what we want it to do.

(They haven’t released any updates in the three-and-a-bit weeks since you created the thread, so that’s a good indicator that nothing has changed.)

[Customer Feedback]

Let me translate that into a real answer:

"No."