Invalid SVG?

Bloke · 2025-10-04 15:21:51

Can anyone help me debug this please. I’m way out of my depth.

If I try to upload this SVG (Epson) to Txp’s Images panel – Txp 4.9.0 bleeding edge code – it works fine:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   version="1.1"
   id="svg4748"
   viewBox="0 0 300 73.748918"
   height="73.748917"
   width="300">
  <defs
     id="defs4750" />
  <metadata
     id="metadata4753">
    <rdf:RDF>
      <cc:Work
         rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <dc:title></dc:title>
      </cc:Work>
    </rdf:RDF>
  </metadata>
  <g
     transform="translate(-230.98971,-522.3902)"
     id="layer1">
    <g
       transform="matrix(2.6281465,0,0,-2.6281465,438.2711,583.07067)"
       id="g3414">
      <path
         id="path3416"
         style="fill:#003f98;fill-opacity:1;fill-rule:nonzero;stroke:none"
         d="m 0,0 c -4.881,0 -6.762,4.493 -6.762,9.059 0,4.566 1.881,9.056 6.762,9.056 4.876,0 6.762,-4.49 6.762,-9.056 C 6.762,4.493 4.876,0 0,0 m 0,22.708 c -7.686,0 -12.124,-5.759 -12.124,-13.649 0,-7.893 4.438,-13.651 12.124,-13.651 7.682,0 12.119,5.758 12.119,13.651 0,7.89 -4.437,13.649 -12.119,13.649" />
    </g>
    <g
       transform="matrix(2.6281465,0,0,-2.6281465,231.98971,525.40283)"
       id="g3418">
      <path
         id="path3420"
         style="fill:#003f98;fill-opacity:1;fill-rule:nonzero;stroke:none"
         d="m 0,0 19.259,0 0,-4.594 -13.902,0 0,-5.714 12.964,0 0,-4.478 -12.964,0 0,-6.391 13.902,0 0,-4.592 L 0,-25.769 0,0 Z" />
    </g>
    <g
       transform="matrix(2.6281465,0,0,-2.6281465,315.46174,560.74167)"
       id="g3422">
      <path
         id="path3424"
         style="fill:#003f98;fill-opacity:1;fill-rule:nonzero;stroke:none"
         d="m 0,0 -4.85,0 0,8.853 0,0.005 4.85,0 c 3.371,0 5.613,-1.467 5.613,-4.43 C 5.613,1.466 3.371,0 0,0 m -10.205,-12.322 5.355,0 0,7.732 4.85,0 c 6.564,0 10.969,3.224 10.969,9.018 0,5.795 -4.405,9.018 -10.969,9.018 l -10.205,0 0,-25.768 z" />
    </g>
    <g
       transform="matrix(2.6281465,0,0,-2.6281465,489.89471,525.40283)"
       id="g3426">
      <path
         id="path3428"
         style="fill:#003f98;fill-opacity:1;fill-rule:nonzero;stroke:none"
         d="m 0,0 -5.5,0 0,-25.769 5.252,0 0,10.438 c 0,2.857 -0.102,5.391 -0.199,7.632 0.619,-1.29 2.5,-5.166 3.367,-6.622 l 6.836,-11.448 5.5,0 0,25.769 -5.252,0 0,-10.177 c 0,-2.854 0.105,-5.654 0.199,-7.89 -0.619,1.29 -2.495,5.164 -3.375,6.618 L 0,0 Z" />
    </g>
    <g
       transform="matrix(2.6281465,0,0,-2.6281465,360.27875,570.72049)"
       id="g3430">
      <path
         id="path3432"
         style="fill:#003f98;fill-opacity:1;fill-rule:nonzero;stroke:none"
         d="m 0,0 c 0,-3.463 2.881,-4.809 5.945,-4.809 2,0 5.248,0.58 5.248,3.24 0,2.809 -3.968,3.34 -7.797,4.359 -4.015,1.063 -7.882,2.569 -7.882,7.344 0,5.323 5.035,7.875 9.738,7.875 5.43,0 10.424,-2.37 10.424,-8.384 l -5.358,0 c -0.182,3.134 -2.588,3.938 -5.322,3.938 -1.824,0 -4.121,-0.766 -4.121,-2.956 0,-2.004 1.311,-2.313 7.832,-3.992 1.898,-0.474 7.845,-1.622 7.845,-7.525 0,-4.778 -3.755,-8.347 -10.831,-8.347 -5.756,0 -11.151,2.841 -11.08,9.257 L 0,0 Z" />
    </g>
  </g>
</svg>

As does this one (Samsung):

<svg xmlns="http://www.w3.org/2000/svg" width="2500" height="830" viewBox="0 0 200.777 66.659"><path d="M200.653 15.87C197.923.194 150.822-4.698 95.446 4.943 72.19 8.994 51.191 14.969 34.838 21.691c2.512.055 4.375.631 5.507 1.76.885.886 1.332 2.102 1.332 3.617v1.555h-5.43V27.25c0-1.144-.686-1.853-1.901-1.853-1.021 0-1.65.461-1.853 1.369a2.63 2.63 0 0 0 .022 1.084c.581 2.375 8.644 3.85 9.521 8.233.115.564.271 1.771.025 3.498-.503 3.535-3.609 4.899-7.563 4.899-5.519 0-7.761-2.614-7.761-6.218l.004-1.705h5.821l.003 2.124c0 1.194.868 1.853 2.05 1.853 1.12 0 1.774-.451 2-1.373.105-.424.151-1.049-.04-1.527-1.077-2.702-8.606-3.964-9.533-8.333-.207-.982-.224-1.818-.052-2.875a5.606 5.606 0 0 1 .482-1.511C9.333 33.398-1.278 42.732.124 50.791c2.733 15.678 49.833 20.565 105.208 10.924 24.342-4.237 46.226-10.58 62.881-17.688-.241.012-.475.038-.725.038-3.79 0-7.174-1.42-7.525-5.294-.062-.705-.073-1-.075-1.402l.002-8.906c0-.384.045-1.058.088-1.406.449-3.744 3.409-5.288 7.512-5.288 3.175 0 7.068.911 7.496 5.291.057.55.051 1.137.05 1.33v.841h-5.484v-1.255c0-.027-.008-.496-.068-.789-.09-.447-.471-1.483-2.033-1.483-1.543 0-1.943 1.038-2.043 1.484-.057.245-.084.597-.084.987v9.679c-.005.336.012.599.046.792.027.152.304 1.486 2.1 1.486 1.783 0 2.059-1.334 2.084-1.486.047-.262.053-.574.051-.792v-2.999h-2.158v-3.23h7.631v5.746c-.002.391-.008.68-.074 1.4-.092 1.016-.412 1.876-.914 2.611 17.663-8.387 27.947-17.57 26.563-25.512zM57.065 43.653l-2.778-18.876h-.1l-2.849 18.876h-5.855l3.938-21.317h9.553l3.914 21.317h-5.823zm28.162 0l-.129-18.511h-.094l-3.445 18.511h-5.495l-3.428-18.511h-.098l-.125 18.511h-5.445l.472-21.317h8.758l2.55 15.835h.125l2.557-15.835h8.754l.47 21.317h-5.427zm25.641-4.131c-.586 4.129-4.631 4.851-7.49 4.851-4.747 0-7.683-2.029-7.683-6.158l.003-1.684h5.751l.004 2.098c0 1.139.803 1.836 2.043 1.836 1.106 0 1.754-.444 1.979-1.356.104-.425.147-1.045-.037-1.513-1.06-2.651-8.53-3.95-9.438-8.251-.208-.975-.223-1.803-.052-2.849.632-3.899 4.374-4.709 7.386-4.709 2.694 0 4.655.588 5.831 1.764.877.878 1.321 2.083 1.321 3.582v1.538h-5.378v-1.357c0-1.162-.721-1.834-1.88-1.834-1.028 0-1.65.457-1.854 1.356a2.59 2.59 0 0 0 .026 1.072c.576 2.364 8.568 3.809 9.443 8.151.113.554.268 1.743.025 3.463zm19.918-1.937c.008.4-.031 1.199-.053 1.404-.328 3.512-2.84 5.297-7.447 5.297-4.625 0-7.139-1.785-7.465-5.297a16.957 16.957 0 0 1-.053-1.4V22.331h5.502V38.07c-.006.352.012.612.047.793.068.35.416 1.486 1.969 1.486 1.548 0 1.896-1.137 1.969-1.482.031-.186.05-.459.05-.798V22.331h5.481v15.254zm23.705 5.851h-7.656l-5.139-16.885h-.086l.285 16.885h-5.336v-21.1h7.977l4.75 16.22h.111l-.281-16.22h5.375v21.1z" fill="#2d4f9e"/></svg>

But this one (Lexmark) results in “Only .gif, .jpeg, .jpg, .png, .svg, .webp, .avif file types allowed” error when I try to upload it:

<svg viewBox="79 199 1000 198.3" xmlns="http://www.w3.org/2000/svg"><path d="m238.2 199.5h-158.7v38.6l14.5 57.4 45.5 2.6 38.6-38.6 76.4-16.4z" fill="#00c425"/><path d="m79.5 238.1v158.7h38.6l64.6-5.4-4.5-54.7z" fill="#3af23a"/><path d="m118.1 396.8h158.7v-38.6l-16.9-51.4-43.2-8.7z" fill="#006446"/><path d="m1035.8 277.8-34.9 31.7 34.9 31.9v18.4h-1.1l-51.8-47v44.7h-15v-135.2h15v84.5l51.5-46.9h1.4zm-676.9 79.7h76.6v-15.1h-61v-115.7h-15.6zm129.6-97.5c-23.5 0-44.9 19.1-44.9 49.9 0 29.9 19.6 49.7 47.8 49.7 12.6 0 24.2-3.2 34.7-10.8v-16.1c-11 9.2-23.2 13.1-34.2 13.1-16.9 0-31.9-10.5-33.3-30.1h71.4c.2-1.9.6-6.1.6-7.7 0-31.5-19-48-42.1-48zm.1 13.7c13.3 0 26.8 8.6 27.3 28.9h-57.4c.9-15.7 13-28.9 30.1-28.9zm251.9-13.7c-12.7 0-21.9 6.7-27.4 16.6-4.6-10.6-13.1-16.6-26.7-16.6-11.9 0-20.7 6.9-25.5 16.1h-.4l-1.8-14.2h-11.9v95.5h15.2v-60.3c0-11.7 7.3-22.6 20.5-22.6 12.9 0 18.6 7.6 18.6 21.4v61.6h15.2v-61.4c0-11.1 7.4-21.6 20.4-21.6 13.1 0 18.7 7.6 18.7 21.4v61.6h15.2v-63.7c.1-20-9.2-33.8-30.1-33.8zm91.7 0c-22.8 0-44.1 19.3-44.1 49.9 0 30.2 21.2 49.7 44.1 49.7 14.3 0 27.8-6.7 35-20h.2l1.8 17.9h12.4v-95.5h-12.4l-1.8 17.9h-.2c-7.2-13.1-20.7-19.9-35-19.9zm2.8 14.2c18 0 31.7 14.5 31.7 35.6 0 21-13.6 35.6-31.7 35.6-17.7 0-31.7-14.3-31.7-35.4 0-21.5 14-35.8 31.7-35.8zm111.4-13.3c-8.3 0-20.9 3.9-27.4 16.3h-.2l-1.6-15.2h-12.2v95.5h15.2v-55c0-22.1 17.9-29 32.6-26v-15.1c-2-.3-3.9-.5-6.4-.5zm-319.1-1.1h-1.2l-39.9 39.8-39.8-39.8h-1.2v19.3l30.7 30.7-30.7 30.5v19.5h1.2l39.6-40 40.1 40h1.2v-19.6l-31-30.7 31-31.2zm408.5-35.4v-2.1h16.6v2.1h-7v16.6h-2.5v-16.7c-.1.1-7.1.1-7.1.1zm25-2.1 7.2 15.8 7.2-15.8h3.4v18.7h-2.4v-15.7l-7.2 15.7h-2.1l-7.1-15.7v15.7h-2.4v-18.8h3.4z" fill="#32323c"/><path d="m276.8 358.2v-158.7h-38.6l-60 60z" fill="#008a44"/></svg>

And this one (Brother) uploads but doesn’t display anything when I use <txp:image name="brother.svg" />:

<svg clip-rule="evenodd" fill-rule="evenodd" height=".64in" image-rendering="optimizeQuality" shape-rendering="geometricPrecision" text-rendering="geometricPrecision" viewBox="0.038 0.034 2.605809061125626 0.5923850260083584" width="254.4" xmlns="http://www.w3.org/2000/svg"><g fill="#005cab"><path d="M2.565.138c-.146 0-.224.082-.227.188a.233.233 0 0 0-.233-.19.23.23 0 0 0-.23.188.186.186 0 0 0-.183-.188.162.162 0 0 0-.115.047V.035h-.11v.33l-.001.033C1.459.466 1.413.5 1.363.5c-.052 0-.1-.024-.1-.102L1.26.37V.247h.171V.143h-.17V.035H1.15v.29A.235.235 0 0 0 .738.222V.138H.725C.582.138.505.218.5.32A.221.221 0 0 0 .282.138a.186.186 0 0 0-.137.056v-.16H.038V.37C.04.5.13.604.27.604.39.604.477.526.5.422v.171h.11V.38.35C.613.282.655.243.723.242a.235.235 0 1 0 .428.172c0 .114.09.19.2.19.046 0 .086-.02.117-.052v.04h.11V.36.346c.003-.075.047-.107.095-.107s.09.032.09.106l.001.018v.23h.112V.42c.02.112.116.185.23.185a.216.216 0 0 0 .221-.169h-.108a.119.119 0 0 1-.113.078c-.06 0-.111-.04-.124-.108h.357v.188h.11V.38L2.45.35c.002-.067.046-.106.116-.106h.012V.138h-.012zM.269.498A.127.127 0 0 1 .141.37C.141.3.197.242.27.242c.073 0 .129.056.129.128a.127.127 0 0 1-.129.128zm.65 0A.127.127 0 0 1 .793.37C.792.3.847.242.92.242c.073 0 .128.056.128.128A.127.127 0 0 1 .92.498zm1.067-.18a.125.125 0 0 1 .119-.09c.07 0 .11.056.119.09zM2.526.545c0 .03.025.055.055.055a.055.055 0 1 0 0-.11.055.055 0 0 0-.055.055zm.007 0a.048.048 0 1 1 .096 0 .048.048 0 0 1-.096 0z"/><path d="M2.565.52h.022c.009 0 .012.004.012.011 0 .008-.003.012-.012.012h-.022V.52zm0 .03h.022c.006 0 .01.005.01.013V.57L2.6.578h.01V.577L2.606.569V.56C2.605.554 2.602.549 2.598.547c.006-.002.01-.008.01-.017 0-.01-.007-.018-.02-.018h-.032v.066h.009V.551z"/></g></svg>

I’ve run them through validators and ImageOptim in the hope it would “fix” whatever Txp is choking on, but so far nothing. I suspect the Brother one is because something is limiting its size somehow. Because the resulting <img> tag is rendered with width="3" height="1", even if I remove the width and height attributes in the .svg file.

Anyone got any clues why these latter ones are refusing to behave?

colak · 2025-10-04 15:47:10

I was thinking that there might be something wrong with either the self closing or the wrapping tags but everything appears OK to me. There is this svg validator which breaks down the xml structure and I see no errors. The w3 validator does return some errors. (Click on More Options, and select your svg version under Document Type).

gaekwad · 2025-10-04 16:21:32

I can’t answer why the SVG upload chokes, but here’s a working Lexmark one (open your supplied SVG in Affinity Designer, export to SVG, run through ImageOptim):

<svg clip-rule="evenodd" fill-rule="evenodd" stroke-linejoin="round" stroke-miterlimit="2" viewBox="0 0 1000 199" xmlns="http://www.w3.org/2000/svg"><g fill-rule="nonzero" transform="translate(-79 -199)"><path d="m238.2 199.5h-158.7v38.6l14.5 57.4 45.5 2.6 38.6-38.6 76.4-16.4z" fill="#00c425"/><path d="m79.5 238.1v158.7h38.6l64.6-5.4-4.5-54.7z" fill="#3af23a"/><path d="m118.1 396.8h158.7v-38.6l-16.9-51.4-43.2-8.7z" fill="#006446"/><path d="m1035.8 277.8-34.9 31.7 34.9 31.9v18.4h-1.1l-51.8-47v44.7h-15v-135.2h15v84.5l51.5-46.9h1.4zm-676.9 79.7h76.6v-15.1h-61v-115.7h-15.6zm129.6-97.5c-23.5 0-44.9 19.1-44.9 49.9 0 29.9 19.6 49.7 47.8 49.7 12.6 0 24.2-3.2 34.7-10.8v-16.1c-11 9.2-23.2 13.1-34.2 13.1-16.9 0-31.9-10.5-33.3-30.1h71.4c.2-1.9.6-6.1.6-7.7 0-31.5-19-48-42.1-48zm.1 13.7c13.3 0 26.8 8.6 27.3 28.9h-57.4c.9-15.7 13-28.9 30.1-28.9zm251.9-13.7c-12.7 0-21.9 6.7-27.4 16.6-4.6-10.6-13.1-16.6-26.7-16.6-11.9 0-20.7 6.9-25.5 16.1h-.4l-1.8-14.2h-11.9v95.5h15.2v-60.3c0-11.7 7.3-22.6 20.5-22.6 12.9 0 18.6 7.6 18.6 21.4v61.6h15.2v-61.4c0-11.1 7.4-21.6 20.4-21.6 13.1 0 18.7 7.6 18.7 21.4v61.6h15.2v-63.7c.1-20-9.2-33.8-30.1-33.8zm91.7 0c-22.8 0-44.1 19.3-44.1 49.9 0 30.2 21.2 49.7 44.1 49.7 14.3 0 27.8-6.7 35-20h.2l1.8 17.9h12.4v-95.5h-12.4l-1.8 17.9h-.2c-7.2-13.1-20.7-19.9-35-19.9zm2.8 14.2c18 0 31.7 14.5 31.7 35.6 0 21-13.6 35.6-31.7 35.6-17.7 0-31.7-14.3-31.7-35.4 0-21.5 14-35.8 31.7-35.8zm111.4-13.3c-8.3 0-20.9 3.9-27.4 16.3h-.2l-1.6-15.2h-12.2v95.5h15.2v-55c0-22.1 17.9-29 32.6-26v-15.1c-2-.3-3.9-.5-6.4-.5zm-319.1-1.1h-1.2l-39.9 39.8-39.8-39.8h-1.2v19.3l30.7 30.7-30.7 30.5v19.5h1.2l39.6-40 40.1 40h1.2v-19.6l-31-30.7 31-31.2zm408.5-35.4v-2.1h16.6v2.1h-7v16.6h-2.5v-16.7c-.1.1-7.1.1-7.1.1zm25-2.1 7.2 15.8 7.2-15.8h3.4v18.7h-2.4v-15.7l-7.2 15.7h-2.1l-7.1-15.7v15.7h-2.4v-18.8h3.4z" fill="#32323c"/><path d="m276.8 358.2v-158.7h-38.6l-60 60z" fill="#008a44"/></g></svg>

gaekwad · 2025-10-04 16:25:45

…and Brother:

<svg clip-rule="evenodd" fill-rule="evenodd" height="47" stroke-linejoin="round" stroke-miterlimit="2" width="255" xmlns="http://www.w3.org/2000/svg"><g fill="#005cab" transform="matrix(77.7872 0 0 77.7872 22.8947 -2.64477)"><path d="m2.565.138c-.146 0-.224.082-.227.188-.021-.111-.12-.192-.233-.19-.112-.002-.21.078-.23.188.001-.102-.081-.186-.183-.188-.043 0-.084.017-.115.047v-.148h-.11v.33l-.001.033c-.007.068-.053.102-.103.102-.052 0-.1-.024-.1-.102l-.003-.028v-.123h.171v-.104h-.17v-.108h-.111v.29c-.022-.109-.119-.189-.23-.189-.071 0-.137.032-.182.086v-.084h-.013c-.143 0-.22.08-.225.182-.019-.105-.111-.182-.218-.182-.051-.001-.101.019-.137.056v-.16h-.107v.336c.002.13.092.234.232.234.12 0 .207-.078.23-.182v.171h.11v-.243c.003-.068.045-.107.113-.108-.025.038-.038.082-.038.128 0 .129.106.235.235.235.113 0 .21-.081.231-.191 0 .114.09.19.2.19.046 0 .086-.02.117-.052v.04h.11v-.246c.003-.075.047-.107.095-.107s.09.032.09.106l.001.018v.23h.112v-.173c.02.112.116.185.23.185.105.005.198-.067.221-.169h-.108c-.017.047-.063.079-.113.078-.06 0-.111-.04-.124-.108h.357v.188h.11v-.214l.001-.03c.002-.067.046-.106.116-.106h.012v-.106zm-2.293.36c-.001 0-.004 0-.004 0-.07 0-.127-.057-.127-.127v-.001c0-.07.056-.128.129-.128s.129.056.129.128v.001c0 .07-.057.127-.127.127zm.647 0c-.069-.001-.126-.058-.126-.127v-.001c-.001-.07.054-.128.127-.128s.128.056.128.128v.001c0 .07-.057.127-.127.127zm1.067-.18c.015-.053.064-.09.119-.09.07 0 .11.056.119.09zm.54.227c0 .03.025.055.055.055s.055-.025.055-.055-.025-.055-.055-.055-.055.025-.055.055zm.007 0c0-.026.022-.048.048-.048s.048.022.048.048-.022.048-.048.048-.048-.022-.048-.048z"/><path d="m2.565.52h.022c.009 0 .012.004.012.011 0 .008-.003.012-.012.012h-.022zm0 .03h.022c.006 0 .01.005.01.013v.007l.003.008h.01v-.001l-.004-.008v-.009c-.001-.006-.004-.011-.008-.013.006-.002.01-.008.01-.017 0-.01-.007-.018-.02-.018h-.032v.066h.009z"/></g></svg>

Bloke · 2025-10-04 21:00:19

gaekwad wrote #340835:

I can’t answer why the SVG upload chokes, but here’s a working Lexmark one (open your supplied SVG in Affinity Designer, export to SVG, run through ImageOptim):

Ahhh, good workaround. That version you posted does indeed work and uploads to Txp fine.

I thought validating the original I downloaded and then running through ImageOptim would solve it, but it didn’t. Opening in Affinity and saving is a good way to force it to regenerate it properly. Thanks for the tip.

I initially presumed our SVG implementation was choking on one of these attributes: clip-rule="evenodd" fill-rule="evenodd" stroke-linejoin="round" stroke-miterlimit="2" because most of the rest is the same. But the Brother image contains at least half those and is fine, so it may be the miterlimit/linejoin, or just some weird combination or attribute order that it’s complaining about. A mystery, Scoob. Given SVG support is new in 4.9.0, it would be nice to find out why and perhaps patch it.

gaekwad wrote #340836:

…and Brother

That is slightly altered and shows up fine on the site (because I’m controlling the size from CSS), but the HTML <img> tag still thinks it’s 3px wide and 1px high.

All very baffling, but at least it works now, thank you.

gaekwad · 2025-10-04 21:25:52

With the risk of making more work for you, you could consider a set size Affinity Designer workspace / artboard in a new document, then copy & paste the layers in from the existing SVG. On export, you can choose to flatten the layers (if there’re multiple), and then chuck it into ImageOptim.

Bonus points awarded for an Automator Folder Action to watch a directory for new files and chuck ‘em into ImageOptim with one or two fewer clicks / taps / presses.

jakob · 2025-10-04 22:02:22

Wild guess: maybe something to do with the heights / widths and/or viewbox?

The third one (lexmark) has no width or height and a viewbox starting from a less usual starting point.
The last one (brother) has an inch unit in the height but not the width and a minute bounding box.

Bloke · 2025-10-04 22:24:39

jakob wrote #340852:

Wild guess: maybe something to do with the heights / widths and/or viewbox?

Could be. Perhaps Txp rejects images without any dimensions set? I’d have to try and grok the code to be sure.

I don’t really understand viewbox. Seems to be 4 random numbers that, if you edit them by just a single digit in any direction, cause chaos.

jakob · Yesterday 06:48:25

Did your edit from last night help?

From what I can see, an SVG file will be rejected:

if an svg has no numeric width or height attributes and also no viewbox (here)
if an svg has no numeric width or height attributes and the width or height calculated from the viewbox is negative (here)

This means:

The lexmark height calculates to less than zero (in the current code) -> discarded
The brother has an in (presumably inches) dimension. The code skips the given width (because not numeric) and calculates it from the viewbox. The dimensions there are given in fractions of an inch but the code understands that as pixels, so it’s calculated width (with the current code) is half a pixel. -> doesn’t show.

BUT … the way the width and height is currently calculated in the code may be wrong. If I’m reading it correctly, the code as it is now assumes x-min, y-min, x-max, y-max to determine the width, but viewbox numbers are actually x-topcorner, y-topcorner, width, height. See, for example, Josh Comeau’s interactive diagram. We should probably amend that to:

$viewbox = preg_split('/[\s,]+/', trim($svg['viewBox']));
$width = (float)$viewbox[2];
$height = (float)$viewbox[3];

(apparently viewBox can also support commas as separators, hence the switch from explode).

It might also be prudent to check whether all four values are present and x-topcorner and y-topcorner are greater than zero.

To work with the inches dimension, we’d have to detect the unit, then convert to pixels (assuming a dpi?) and scale the other numbers by that factor. I looked up what units and conversion factors apply (with dpi=96):

$unitToPixelFactors = [
    'px' => 1,
    'in' => 96,
    'cm' => 96 / 2.54,
    'mm' => 96 / 25.4,
    'pt' => 96 / 72,
    'pc' => 16, // 1 pica = 12 points = 1/6 inch = 16px
];

PS: Potentially this means some existing uploaded SVG files could have wrong dimensions. That will only be the case when a viewBox doesn’t start from 0 0, which is relatively uncommon.

EDIT: Added unit-to-pixel conversion factors.

phiw13 · Yesterday 07:28:53

Aside – when I first tested this issue this morning, my test site stubbornly refused to upload anything SVG with no error message at all. It is only after I checked the httpd error log that I realised that I wasn’t fully up to date and Stef had patched something SVG related (rather important…).

Should TXP admin issue some error message here? The site is in full debug mode.

–^–

To add to the list of error / failure triggers that Julian posted: a large <style>…</style block with mediaqueries, an empty <defs></defs> line, and a misspelled viewbox (it must be viewBox, capital B).

Bloke · Yesterday 09:17:38

Great feedback guys, thank you. So it looks as if we can be smarter here.

My rudimentary thinking is that SVG, being scalable, doesn’t necessarily need a width and height but Txp requires them simply because we have to add them to the database table. Is that an accurate assumption?

If so, I’m torn whether to patch this or leave it. Because when we move to on-demand image scaling, the nominal dimensions of the uploaded image may well become redundant. We might (probably will) axe the width/height and thumbnail aspects of the txp_image table.

What do you think? Worth making width/height required now and then making it unrequired in future?

Dealing with units is a great idea. We can’t always assume px, so that scaling table is a great yardstick. I might be tempted to set a config constant for the DPI value, with default 96, then at least people can tweak it if they use higher or lower res images in their site.

Viewbox stuff needs looking at. And yes the checks for top/left > 0 would make sense here. We could be a little less opinionated on case, perhaps? So we accept nothing forms of viewBox or viewBox? Or does the spec mandate one or the other?

If anybody would like to prep a patch with any/all the above, please raise your hand. Otherwise I’ll see if I can look at it this week.

Bloke · Yesterday 09:21:27

phiw13 wrote #340858:

Stef had patched something SVG related (rather important…).

Yes, rather embarrassingly forgetting to change the function itself was stupid. In my defence I’d been messing with something else in txplib_misc.php and discarded my changes which also threw out the function name change as I was testing it and I forgot to add it back in.

Should TXP admin issue some error message here?

No, it was a syntax error I made, which borked the Ajax request, hence nothing was returned. Apologies.

Textpattern CMS

Textpattern CMS support forum

#1 2025-10-04 15:21:51

Invalid SVG?

#2 2025-10-04 15:47:10

Re: Invalid SVG?

#3 2025-10-04 16:21:32

Re: Invalid SVG?

#4 2025-10-04 16:25:45

Re: Invalid SVG?

#5 2025-10-04 21:00:19

Re: Invalid SVG?

gaekwad wrote #340835:

gaekwad wrote #340836:

#6 2025-10-04 21:25:52

Re: Invalid SVG?

#7 2025-10-04 22:02:22

Re: Invalid SVG?

#8 2025-10-04 22:24:39

Re: Invalid SVG?

jakob wrote #340852:

#9 Yesterday 06:48:25

Re: Invalid SVG?

#10 Yesterday 07:28:53

Re: Invalid SVG?

#11 Yesterday 09:17:38

Re: Invalid SVG?

#12 Yesterday 09:21:27

Re: Invalid SVG?

phiw13 wrote #340858:

Board footer