The first step would be to support stroke-dasharray and stroke-dashoffset attributes.

On native/flash the svgs are rendered perfectly, but on html5 it seems someone has pulled a fork through some images:

svg file
haxelib list

Inkscape, the foremost open source SVG editor, always inserts a viewBox attribute when it creates a new SVG. This library ignores viewBox, causing it to scale these images incorrectly.

To demonstrate, I made a new Inkscape file, resized the canvas to 128x128px, and filled it with a circle:

Which looks like this in the XML:

<svg
   width="128px"
   height="128px"
   viewBox="0 0 210 297"
   version="1.1">
  <!-- ... -->
</svg>

And looks like this when rendered in a browser:

But that's taking viewBox into account, which openfl/svg doesn't. Here's what you get when you use this library:

Note that you get the exact same result if you delete the viewBox attribute in Inkscape:

I may look into this further at some other point, but I'm hoping someone who already knows this library already knows where to go to fix this. I think you should scale based on the minimum of width and height, but don't quote me on it.

Hi!

When i try to build, i get an error:

/Users/pablomartin/Documents/workspace/sdks/HaxeToolkit/haxe/lib/svg/git/format/svg/SVGData.hx:139: characters 29-33 : On static platforms, null can't be used as basic type Float
/Users/pablomartin/Documents/workspace/sdks/HaxeToolkit/haxe/lib/svg/git/format/svg/SVGData.hx:143: characters 29-33 : On static platforms, null can't be used as basic type Float

I had to change this line to -cp format to get it to build.

After that, tests succeeded except for:

Class: MacroTest .
Class: SvgGenerationTest ...!.......
    FAIL: massive.munit.AssertionException: fancy-sun.svg has 28% pixels different, which is over the threshold of 10% at SvgGenerationTest#compareGeneratedToExpected (246)

Here's a list of things that should, but don't, render correctly (or aren't supported).

• #13: background incorrectly translated
• SVGs which use translate(x) (but no y): the SVG spec is translate(x, [y = 0]). You get a warning on build, but it appears to display correctly.
• SVGs that have a viewBox property on the svg tag, but no width and height properties, are rendered with the default size of 400x400 instead of the viewBox size.
• This sun SVG icon has a myriad of issues. Specifically, the path with id="path9599" (orange circle background) appears correctly in many SVG viewers (Windows, Linux) but appears mis-translated to the right and down when the icon is rendered. (You can repro this by deleting everything from the icon except the root g tag and this path tag.)
• #23: text, gradients, and rotation
• #29: dashed lines.
• #31: three-character hex colours don't work
• #32: stroke width doesn't work
• #35: Stroke thickness is off by ~sqrt(2)/2
• #38: Parent/child object relationships are broken
• #41 Rotation doesn't work

Given this SVG:

<?xml version="1.0" encoding="UTF-8"?>
<svg width="512px" height="512px" viewBox="0 0 512 512" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
    <defs>
        <path d="M34.4356168,3.86684421 C34.5458031,6.52287169 34.6008954,9.02262477 34.6008954,11.3661784 C34.6008954,15.8970488 34.4080723,19.9591476 34.0224201,23.5525965 C32.2043458,23.0838858 30.771945,22.849534 29.7251749,22.849534 L25.8411264,22.7323569 C24.4087042,22.7323569 23.6925038,22.8495328 23.6925038,23.0838881 C23.5823175,24.1775465 23.5272251,26.4820064 23.5272251,29.9973369 C23.5272251,36.871761 23.7200483,55.3855572 24.1057005,85.539281 C22.5079987,85.9298732 20.6348593,86.1251664 18.486226,86.1251664 L16.0896854,86.1251664 C13.3350273,86.1251664 10.8007798,86.3985769 8.48686696,86.9454061 C8.32158747,86.5548138 8.19762972,85.7541117 8.11498997,84.5432756 C8.03235023,83.3324396 8.01857714,82.2192683 8.07367031,81.2037284 L8.07367031,75.4620506 L8.15630964,64.9161119 C8.15630964,50.698553 7.93594029,36.8327351 7.49519499,23.3182423 C6.8891702,22.9276501 6.03523899,22.7323569 4.93337574,22.7323569 L1.62780252,22.849534 C-0.245365011,22.849534 -1.59512725,22.6542407 -2.42152469,22.2636485 C-2.58680417,21.7949377 -2.72453501,20.5060026 -2.83472134,18.3968043 C-2.94490766,16.287606 -3,13.9050288 -3,11.2490013 C-3,7.34307856 -2.97245383,4.53085635 -2.91736067,2.81225033 L0.636130549,2.81225033 L3.85906444,2.69507324 L8.48686696,2.69507324 L13.2799481,2.57789614 C21.4888294,2.57789614 28.1825482,3.0075412 33.3613055,3.86684421 L34.4356168,3.86684421 Z M58.3597075,31.5206391 C58.4148007,31.5206391 58.4285738,31.5011098 58.4010272,31.4620506 C58.3734806,31.4229914 58.3872537,31.4034621 58.4423468,31.4034621 C59.7645827,30.1535668 61.2933951,29.1575714 63.0288297,28.4154461 C64.7642643,27.6733207 66.4858998,27.3022636 68.1937879,27.3022636 C71.8299366,27.3022636 74.6396457,28.5521402 76.6229996,31.0519308 C78.1656081,33.0048921 78.9369008,39.449568 78.9369008,50.3861518 C78.9369008,53.5890085 78.8818085,58.4713387 78.7716222,65.0332889 C78.6614359,70.6578177 78.6063435,74.6808578 78.6063435,77.10253 C78.6063435,79.7585574 78.6614359,82.7270142 78.7716222,86.0079893 C75.7414982,86.632937 72.7665121,86.8672888 69.8465745,86.7110519 L65.9625259,86.7110519 C65.8523396,84.3674983 65.7972473,79.8366958 65.7972473,73.1185087 L65.7972473,67.2596538 L65.7146079,58.9400799 C65.6595148,58.4713692 65.6319686,57.6901963 65.6319686,56.5965379 C65.5768754,54.2529843 65.4253715,52.4562868 65.1774523,51.2063915 C64.9295331,49.9564962 64.7091637,49.1753234 64.5163376,48.8628495 C64.3235116,48.5503757 64.0342768,48.1597893 63.6486247,47.6910786 C63.2078794,47.3004863 62.5743175,47.1051931 61.7479201,47.1051931 C60.7562431,47.1051931 59.8747658,47.6129554 59.1034615,48.6284953 C58.3321572,49.6440353 57.9189647,51.3235569 57.8638715,53.6671105 C57.8087784,54.8388874 57.7812322,56.6355849 57.7812322,59.057257 C57.7812322,61.0102184 57.8363245,63.8614992 57.9465109,67.6111851 C58.0566972,71.5171079 58.1117895,74.446506 58.1117895,76.3994674 C58.1117895,79.9147979 58.0016048,83.0394892 57.7812322,85.7736352 C56.2937168,86.3204643 55.0954585,86.6524628 54.1864213,86.7696405 C53.2773841,86.8868182 52.271949,86.9063475 51.1700857,86.828229 C50.6742473,86.7501106 49.8754084,86.7110519 48.7735452,86.7110519 C47.5064024,86.7110519 46.2668249,86.7891692 45.0547753,86.9454061 L45.0547753,77.5712383 L44.9721359,63.9786951 C44.9170428,57.7292186 44.8894966,46.4412712 44.8894966,30.114514 C44.8894966,15.193889 44.944589,5.27299398 45.0547753,0.351531292 C46.8177565,0.664005113 48.1950649,0.82023968 49.1867418,0.82023968 C50.1233256,0.82023968 51.0323491,0.742122397 51.9138397,0.585885486 L53.3187083,0.351531292 C55.1367827,0.117175925 56.1008986,0 56.2110849,0 C57.5333208,0 58.221975,0.351527776 58.2770682,1.05459387 C58.3872545,3.24191063 58.4423468,7.53836123 58.4423468,13.9440746 L58.3597075,24.6071904 L58.3597075,31.5206391 Z M103.687381,59.8774967 C103.742474,62.4554057 103.838885,64.3497498 103.976618,65.5605859 C104.114351,66.7714219 104.486225,68.0408278 105.092249,69.3688415 C105.532995,70.5406184 106.111464,71.4389671 106.827675,72.0639148 C107.543886,72.6888624 108.287633,73.0013316 109.058937,73.0013316 C110.215894,73.0013316 111.152463,72.1225121 111.868674,70.3648469 C112.584886,68.6071816 112.887893,66.0097819 112.777707,62.5725699 C114.375409,62.8850437 116.083271,62.963161 117.901346,62.8069241 L125.669443,63.3928096 C125.669443,66.9081401 125.490393,70.4624765 125.132287,74.0559254 C124.774181,77.6493744 124.0993,80.3834793 123.107623,82.2583222 C122.00576,84.445639 120.421856,85.9493967 118.355862,86.7696405 C116.289868,87.5898843 113.879579,88 111.12492,88 C110.07815,88 108.618203,87.9218827 106.745036,87.7656458 C105.863545,87.6875274 104.568875,87.6484687 102.860987,87.6484687 C101.153099,87.3359949 99.445237,86.4767048 97.7373489,85.0705726 C95.0928771,82.1020713 93.1370992,77.8837379 91.8699564,72.4154461 C90.6028137,66.9471542 89.9692518,61.0102406 89.9692518,54.6045273 C89.9692518,47.8863401 90.6303599,41.7150747 91.9525958,36.0905459 C93.054459,32.5752154 95.0928755,29.8411105 98.0679062,27.8881491 C101.042937,25.9351877 104.348477,24.9587217 107.984626,24.9587217 C109.96798,24.9587217 111.896212,25.2711908 113.769379,25.8961385 C118.011553,27.0679153 121.110496,29.8996668 123.066304,34.391478 C125.022111,38.8832892 126,44.2538525 126,50.5033289 C126,51.5188688 125.944908,53.2765077 125.834721,55.7762983 C124.787951,56.1668905 122.391435,56.5379476 118.6451,56.8894807 C114.898765,57.2410137 111.400401,57.4167776 108.149905,57.4167776 L103.687381,57.4167776 L103.687381,59.8774967 Z M113.527659,38.7856192 C112.519842,38.0825531 111.61282,37.7310253 110.806566,37.7310253 C108.454991,37.7310253 106.775321,38.3559636 105.767503,39.6058589 C104.759686,40.8557541 104.155004,42.613393 103.953441,44.8788282 C103.886253,45.1913021 103.852659,45.5428298 103.852659,45.9334221 C103.852659,46.4021328 104.05422,46.6755433 104.457347,46.7536618 C104.860474,46.8317802 105.868276,46.8317802 107.480784,46.7536618 L111.915159,46.7536618 L114.938597,46.8708389 L116.248753,46.8708389 C116.450317,46.9489573 116.58469,46.9489573 116.651878,46.8708389 C116.719066,46.7927204 116.752659,46.6364859 116.752659,46.4021305 L116.752659,45.9334221 C116.752659,44.2929345 116.500709,42.8477648 115.9968,41.5978695 C115.492891,40.3479742 114.804226,39.4496255 113.930784,38.9027963 L113.527659,38.7856192 Z" id="path-7"></path>
        <rect id="path-9" x="0" y="0" width="240" height="88"></rect>
    </defs>
    <g id="title" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
        <g id="Title">
            <g id="The" transform="translate(133.500000, 105.000000) rotate(-90.000000) translate(-133.500000, -105.000000) translate(72.000000, 61.000000)">
                <mask id="mask-8" fill="white">
                    <use xlink:href="#path-7"></use>
                </mask>
                <g id="ui/fills/color/base" mask="url(#mask-8)">
                    <mask id="mask-10" fill="white">
                        <use xlink:href="#path-9"></use>
                    </mask>
                    <g id="Background"></g>
                    <g id="ui/atomic/quark/color/neutral-2" mask="url(#mask-10)" fill="#252B2C" fill-rule="evenodd" stroke-width="1">
                        <g id="ui/fills/color/material2/neutral-2">
                            <rect id="Fill" x="0" y="0" width="240" height="88"></rect>
                        </g>
                    </g>
                </g>
            </g>
        </g>
    </g>
</svg>

expected outcome:

got:

running:
haxe 3.4.7
openfl 8.8.0
lime 7.2.1
svg [master]

Some features are not supported like text, gradient, rotation

Can you write up a usage example for this? I can't seem to write to the .graphics property of my sprites.

Here's an apple logo:

<svg viewBox='0 0 90 100' xmlns='http://www.w3.org/2000/svg'>
  <path fill='#AAA' d='M62,0c2,10-9,24-20,24c-3-14,9-22,20-24M5,36c5-8,13-12,21-12c7,0,12,4,19,4c6,0,10-4,19-4c6,0,14,3,19,10c-16,4-15,35,3,39c-7,17-18,27-24,27c-7,0-8-5-17-5c-9,0-11,5-17,5c-7-1-13-7-17-13c-9-10-15-40-6-51' />
</svg>

The fill='#AAA' renders as blue:

@openfl/svg-contributors @openfl/lime-contributors @openfl/svg-contributors

We have a couple of PRs in the queue; one is about two weeks old (and aging). We really need someone with experience in the code-base to vet these, and/or merge them.

Is anyone interested in doing this, who has experience working with the SVG code-base?

Is anyone interested in doing this, who doesn't have much experience, but is willing to learn?

• Every commit and PR should run tests
• The travis-ci output should include text information similar to the HTML report about images and percentage diffs.

Describe the bug
The contours of a simplistic black-and-white SVG get heavily distorted on rendering, though the general shape is still somewhat recognizable. As if some of the key points of the Bezier curves are misplaced (and some aren't). Favicon is also affected by this bug.

To Reproduce
Just launch the app

Expected behavior
Shape rendered by openfl and shape rendered by browser when the SVG file itself is opened should look the same

Screenshots
Original image (tested in latest Chrome & Maxthon):

Result in OpenFL:

Environment
Target: html5
Haxe version: 4.2.4
Libraries:

lime 7.9.0
openfl latest git (bug is present even for stable 9.1.0)
svg latest git (bug is present even for stable 1.1.3)

Additional details
<icon> tag can be removed from project.xml, it doesn't affect anything. It is there just to demonstrate that this effect is present even for the favicon.
This bug forced me to try unchecking "Make Adaptive" and choosing "Presentation Attributes" style preference in the Adobe Illustrator SVG export options. The attached archive is the final version of the repro. Still, the bug is there for the default export settings too.

Testing.zip

Tested targeting ... html5 debug, windows cpp debug.
Look like the path "z" parameter always ignoring.
original svg

rendered svg

svg file code<?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" width="800" height="200" viewBox="0 0 800 200" version="1.1" id="svg8"> <defs id="defs2" /> <metadata id="metadata5"> <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> <path id="path4485" d="m 30,80 c 0,0 -8,-49 20,-52 28,-2 33,53 33,53 z" style="opacity:1;fill:#f7ff2f;fill-opacity:1;stroke:#ffadfe;stroke-width:5;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> <path id="path10" d="m 13,13 q 50,60 30,0 " style="opacity:1;fill:none;fill-opacity:1;stroke:#ff0000;stroke-width:5;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> </svg>

<path id="path4485" d="m 30,80 c 0,0 -8,-49 20,-52 28,-2 33,53 33,53 z"... must be closed

<path id="path10" d="m 13,13 q 50,60 30,0 "... must be not closed

This PR was merged in, but wasn't reviewed. It still needs a review. @ibilon

I tried rendering the openfl.svg file with this library and the background is translated to the left.

Code used:

public function new () {

    super ();

    var svgFile = Assets.getText("openfl");
            var svg = new SVG(svgFile);
            svg.render(graphics, 0, 0);
    cacheAsBitmap = true;
}

Add a minimally reproducable test program to the project, written with OpenFL, which demonstrates the use of SVG-based images.

I haven't done a full test-case yet, just noticed this a few times : If a group has display="none" it won't be displayed. ( good )

However if an element - e.g. circle - is top-most ( not in a group ), display="none" seems to be ignored.

package;

import format.SVG;
import openfl.display.Sprite;
import openfl.Assets;

class Main extends Sprite {
	public function new () {
		super();
		var svg = new SVG(Assets.getText("assets/flixel-different-colors.svg"));
		svg.render(graphics, 0, 0, 150, 150);
	}
}

The result looks like this:

While Inkscape and Chrome render it with the correct colors:

Tested with OpenFL 8.1.1, Lime 6.3.1 and SVG 1.1.2.

SVG asset used.

Sources use import flash.[...], shouldn't it be import openfl.[...] already? Can I create pull request for this?

I was using svg with openfl 3 and have already completed the project but to get advantage of openfl 5 I updated and now svg has a bug...

/usr/lib/haxe/std/js/_std/Xml.hx:25: lines 25-332 : Field nodeType has different type than in core type
/usr/lib/haxe/std/js/_std/Xml.hx:25: lines 25-332 : XmlType should be XmlType
/usr/lib/haxe/std/js/_std/Xml.hx:25: lines 25-332 : Field parent has different property access than core type

I would love to help you, If I can understand what is going on in line number: 25 as it states

@:coreApi class Xml

present.txt

Rename the extension to 'svg' and test this file?
Not sure if I'm using the lib incorrectly but this loads as black on my office pc.
Thanks.

With a simple test SVG, I'm finding that the stroke thickness is off by a factor of sqrt(2)/2 (and, less critically, the default joint type seems to be rounded instead of miter.)

Here's the test SVG:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="256" height="256" version="1.1">
  <rect x="0" y="0" width="256" height="256" fill="#FFFFFF"/>
  <rect x="32" y="32" width="192" height="192" style="fill:#0F0;stroke:#000;stroke-width:32;stroke-opacity:0.5"/>
  <circle cx="128" cy="128" r="32" fill="#0000FF" stroke="#000000" stroke-opacity="0.5" stroke-width="32" />
</svg>

And this is OpenFL on the left vs eog/gimp/etc on the right:

I can hack the extra scaling factor into SVGRenderer.hx and it fixes the issue, however, I'm not sure where this extra factor should go in the lib:

Hi @jgranick and @ibilon ,

I would like your input on how we generate expected/good PNGs from SVGs for our tests. Currently, I have two SVGs (both circular logos) that I generated by rendering them in GIMP (which is free). This produced quite a big pixel difference (7% and 12%), mostly due to aliasing artifacts.

We need a "canonical" or "gold standard" renderer which we can use to generate these images. What comes to mind:

• Use an online "SVG to PNG converter" (so others can easily generate PNGs)
• Use GIMP, or some other free tool
• Run the tests and use the rendered output of the svg library itself to generate the "actual" images. (That means someone has to add a bunch of SVGs, and just verify that they look "good enough.")

How would you like to proceed?

P.S. if you have a sizable body of SVGs on-hand which already render correctly, I would like to add those to the tests too.

In BitmapDataManager.hx: "import format.svg.SvgRenderer;"
while target file is named "SVGRenderer.hx"

This will error below on compile:
Module format.svg.SVGRenderer is loaded with a different case than format.svg.SvgRenderer

Flash target fails to build on svg 1.1.0 but succeeds on 1.0.9

Is that possible to get the SVG data from this loader somehow? What I'm trying to make is a geometry loader, to use some vector graphics editor to draw maps to the project that 'm working on now. So what I need is not only an rendered picture but also a geometry ( anchor points basicaly ) position. I've run through the lib's interface, but I can't really find anything usefull out there. Even a tiny documentation would be a blessing.

There is a closing bracket missing in

function lineStyle(style:LineStyle){...

.....+ f2a(style.miterLimit) );

should be

.....+ f2a(style.miterLimit)+ ");" );

When the SVG contains a polygon element with transform="rotate(-x, y)", SVG generates errors that rotate is an unknown transformation, and it doesn't rotate the element.

Here's a small SVG of a diamond (square rotated 45 degrees) which appears unrotated.

<svg width="50" height="50" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">
 <!-- Created with SVG-edit - http://svg-edit.googlecode.com/ -->
 <g>
  <title>Layer 1</title>
  <rect id="svg_2" height="25" width="25" y="12.5" x="12.5" stroke-linecap="null" stroke-linejoin="null" stroke-dasharray="null" stroke-width="0" stroke="#000000" fill="#0000ff" transform="rotate(45 25,25) "/>
 </g>
</svg>

把 OSS 中所有 SVG 的Content-Type 由 "image/svg+xml" 修改为 "text/xml"。

Wouldn't it be nice?

It doesnt compile with the newest libs - neither on flash or windows. Didn't tested other platforms.

Is it possible to use it without openfl since it's huge dependency for those using it in command line applications ? Can't it render to a RGBA 8-bit depth or similar image bitmap (in a type like Bytes) for example ? User is responsible to convert it to any image format he needs. This way the library get's agnostic from output format too which is more flexible, even for openfl users. Thanks

Here's a fairly simple graphic:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
  <g fill="#F00" stroke="#3b5998" stroke-width="4">
    <path d="M28,6h44v16l-22,21l-22-21z" fill="#6d84b4"/>
    <path d="M28,95h44v-16l-22-21l-22,21z" fill="#6d84b4"/>
    <path d="M6,30v42h15l21-21l-21-21z" fill="#afbfde"/>
    <path d="M95,30v42h-15l-21-21l21-21z" fill="#afbfde"/>
  </g>
</svg>

It's supposed to have a stroke:

This library renders it without a stroke width:

There are fairly significant problems with parent/child element containment and the inheritance of properties, as illustrated by this example:

<svg id="svg1" viewBox="0 0 256 256" xmlns="http://www.w3.org/2000/svg" width="256" height="256">
  <rect width="256" height="256" style="fill:#FFF" />
  <rect x="10" y="10" width="236" height="40" style="fill:#f00;stroke:#000;stroke-width:20;" opacity="0.5"/>
  <g opacity="0.5" stroke="#000" stroke-width="14" transform="scale(0.33 1)">
    <circle cx="80" cy="150" r="60" fill="#f00"/>
    <circle cx="130" cy="150" r="60" fill="#aa0"/>
    <circle cx="180" cy="150" r="60" fill="#0f0"/>
    <circle cx="230" cy="150" r="60" fill="#0aa"/>
    <circle cx="280" cy="150" r="60" fill="#00f"/>
    <circle cx="330" cy="150" r="60" fill="#a0a"/>
    <rect x="50" y="160" width="300" height="80" fill="#ff4" stroke="#552" opacity="0.5"/>
  </g>
</svg>

Here's the rendering in OpenFL vs eog/gimp/etc:

As you can see:

1. In the top box, the opacity should apply to the object as a whole, but it's being applied separately to the stroke and fill. So you can see the overlap between the stroke and fill.

2. With the set of circles in a group:

   a. again the alpha should be applied to the whole group
   b. the scaling isn't being applied properly (different x / y scaling)
   c. the stroke properties should be inherited (issue #32) except where overridden (rectangle)

I haven't looked into the architecture of how SVGs are rendered onto Shapes, but I know in theory how ending fills (or composing Shapes/Sprites) might fix some of these issues.

It may be beyond me, but I'll have a quick look into these issues.

Would be nice if there were tags corresponding to releases.

Haxe 4.2.5, on Windows target.
I created a very simple SVG file for an icon for a Lime project, and it had a clipPath tag for removing a section from one element. I set the icon path to its path in Project.xml using the icon tag. The SVG looks correct when I view it in Chrome and in the editor what I was using, Inkscape, but the icon shown in the taskbar when running the app had nothing clipped from it.

The icon should look like this:

But, instead, it looks like this:

I'm getting the following errors whenever I attempt to build the html5 target via lime.

.../format/gfx/GfxBytes.hx:249: characters 38-53 : flash.display.CapsStyle should be EnumValue
.../format/gfx/GfxBytes.hx:249: characters 38-53 : For function argument 'e'
.../format/gfx/GfxBytes.hx:250: characters 38-54 : flash.display.JointStyle should be EnumValue
.../format/gfx/GfxBytes.hx:250: characters 38-54 : For function argument 'e'

I got it to work (sort of) by editing GfxBytes.hx and commenting out lines 249 and 250. However, all my open path segments were rendered as closed paths. In addition, the stroke was at full opacity where I had it at around 50%.

Here's the SVG file I tried to load with the svg library:
map_00_optimized.svg