-1

I'm currently writing a c++ parser to load and draw several SVG files. I use GDI+ as drawing library. This worked well, until I found a SVG that apparently contains some incorrect values. Here is the SVG content:

<svg xmlns="http://www.w3.org/2000/svg" width="64" height="64" viewBox="0 0 64 64">
  <circle fill="#83BF4F" cx="32" cy="32" r="30"/>
  <path fill="#FFF" stroke="#FFF" stroke-miterlimit="10" d="M44.125 45.045c-1.4-1.076-2.914-3.112-3.215-5.043 3.275-4.105 5.716-9.195 4.947-14.506-.09-.629-.814-1.188-1.396-1.134-1.356.124-2.588.538-3.617 1.214v-3.93c0-.162-.025-.306-.06-.441-.349-3.004-2.514-5.039-5.39-5.198-1.627-.089-3.037.69-4.018 1.898-.978-1.114-2.363-1.809-3.982-1.898-1.621-.089-3.024.685-4.005 1.884a5.506 5.506 0 0 0-3.989-1.884c-1.869-.053-1.865 3.036 0 3.089 1.35.038 2.494 1.045 2.549 2.524 0 .009-.004.018-.004.026a95230194961536300000 95230194961536300000 0 0 1 2.904 21.948l-.005-21.862c.001-.029.007-.055.005-.086l-.001-.014c.194-3.301 4.923-3.295 5.097.014v21.948c0 1.991 2.898 1.991 2.898 0V21.646c.174-3.316 4.928-3.316 5.102 0v8.898a1.739 1.739 0 0 0 0 .368v8.046a38.165 38.165 0 0 1-3.576 3.543c-1.444 1.267.618 3.438 2.05 2.185a38.31 38.31 0 0 0 2.245-2.141c.855 2.069 2.368 3.913 3.998 5.165 1.52 1.17 2.963-1.512 1.463-2.665zm-1.08-17.262c.84 3.449-1.473 5.797-2.201 7.104v-4.343c.154-1.454 1.074-2.322 2.201-2.761z"/>
</svg>

As you can see, one of the arc contains a radius value of 95230194961536300000. When I read this SVG, my engine is able to generate the arc correctly, respecting the received value, but the result is completely surreal and GDI+ does not like it at all. Finally, only the green round is drawn and GDI+ ignores the path completely and not draws it at all.

So I have a lot of questions:

  1. What is this value? Is it a limit, like e.g. std::numeric_limits<float>::max() or std::numeric_limits<float>::infinity() ?
  2. This may be a GDI+ limit, that e.g. not supports a such value? If yes, what is the max possible value supported by GDI+ for a coordinate?
  3. I noticed that browsers like Chrome or Firefox draw this SVG almost correctly, by skipping the incorrect part of the path. How they do it?
  4. What is the correct way to catch a such error (if it is really an error) while the SVG is parsed? And if it's not an error, how a such arc should be interpreted?

Regards

Jean-Milost Reymond
  • 1,833
  • 1
  • 15
  • 36
  • For questions #1/#2: http://stackoverflow.com/questions/3468495/what-are-the-hard-bounds-for-drawing-coordinates-in-gdi – Thomas Voß Oct 02 '16 at 06:32
  • For question #3/#4: You need to parse the svg yourself and remove those parts which are incorrect. As an example for parsing have a look here: http://stackoverflow.com/questions/5115388/parsing-svg-path-elements-with-c-sharp-are-there-libraries-out-there-to-do-t – Thomas Voß Oct 02 '16 at 06:38

1 Answers1

0

First, the numbers are wild and useless.

Honestly, I think that your question #3 is a good hint about how to answer #4. #4 is totally up to you to decide if you want no output or just "the best you can do given weird SVG input." If something incorrect is better for you than nothing unless correct, join the FireFox/Chrome decision.

For me, I'd decide based upon what happens if you reject that SVG file as bad, particularly since someone producing it will point to Chrome and say "this browser displays it perfectly, why doesn't your code work?" It's incorrect technically but likely politically prudent to display what you can, log the flaw, and make a reasonable attempt to figure out what produces the flaw.

Good luck!

John Griffin
  • 377
  • 2
  • 8
  • In fact, that is my problem. I already decided to show what I can, and to catch up such issues whenever possible. But what I need to determine is how to do that. For that, I need to take a decision about how to treat a such case, and for that I need to understand better what this number represent, how and why they were generated, and what are the limits of my graphical library. It's the reasons behind the questions #1 and #2 – Jean-Milost Reymond Sep 30 '16 at 13:27