Add a generator library for dynamically making yED sections

[JustDerb]

This enables this repo to be easily updated with the latest and greatest AWS Simple Icons.

I've tested this by importing a few sections this script generates into yED and everything looks good!

[abesto]

Hey @JustDerb, this looks quite exciting! It's a nice way to automate more of the process and still comply with the "The Software may not be used as part of an automated process." part of the yED license.

My only concern is around the tons of SVG properties hard-coded into the template - for instance, what if one of the icons turns out to be not 60 but 80 pixels wide? I have close to zero knowledge about the internals of the yED XML format, so I expect that there are other, more complex edge-cases I don't know. What are your thoughts on this?

[JustDerb]

My only concern is around the tons of SVG properties hard-coded into the template - for instance, what if one of the icons turns out to be not 60 but 80 pixels wide?

Yep. I saw that after testing this a little bit more. I'll need to come up with a way to dynamically find the width/height of the SVG's and plumb those into the template...

My only concern is around the tons of SVG properties hard-coded into the template - for instance, what if one of the icons turns out to be not 60 but 80 pixels wide?

This is actually a standard format: http://graphml.graphdrawing.org/ From the hard-coded numbers I have in the template (other than the width/height discussed earlier), it doesn't seem to use the other ones - just that they need to be present to have yED correctly import it.

---

Overall, let me think of a way to grab the width and height without bringing in too many dependencies for this script.

[JustDerb]

Doing a little research, it seems that svgpathtools would be the go-to library to parse the svg and figure out all paths bounding boxes... sadly, the AWS icons don't have a strict format that svgpathtools expects :(

For example, the migration/Migration_AWSApplicationDiscoveryService.svg file:

<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" width="100" height="100" viewBox="0 0 100 100">
  <title>Migration</title>
  <g>
    <polygon points="40.6 64 25.65 61.2 15.9 62.19 29.95 81.48 40.6 64" fill="#99bce3"/>
    <polygon points="40.6 36.33 25.65 39.13 15.9 38.14 29.95 18.85 40.6 36.33" fill="#19486f"/>
    <polygon points="29.95 34.74 15.9 38.14 15.9 25.87 29.95 18.85 39.56 29.32 29.95 34.74" fill="#205b99"/>
    <polygon points="29.95 59.17 15.9 57.1 15.9 42.7 29.95 40.57 37.99 50.95 29.95 59.17" fill="#205b99"/>
    <polygon points="29.95 65.64 15.9 62.19 15.9 74.46 29.95 81.48 39.56 72.54 29.95 65.64" fill="#205b99"/>
    <polygon points="40.6 36.33 29.95 34.74 29.95 18.85 40.6 22.09 40.6 36.33" fill="#5294cf"/>
    <polygon points="40.6 64 29.95 65.64 29.95 81.48 40.6 78.24 40.6 64" fill="#5294cf"/>
    <polygon points="40.6 58.18 29.95 59.17 29.95 40.57 40.6 41.55 40.6 58.18" fill="#5294cf"/>
    <polygon points="73.01 27.03 73.01 75.45 79.75 71.16 83.55 52.38 80.4 28.08 73.01 27.03" fill="#205b99"/>
    <polygon points="53.1 30.24 56.39 18.85 82.75 33.88 73.13 35.23 53.1 30.24" fill="#19486f"/>
    <polygon points="50.78 70.47 60.29 78.59 82.75 66.25 73.08 64.88 50.78 70.47" fill="#99bce3"/>
    <polygon points="35.58 83.97 49.99 91.17 59.72 51.24 49.99 8.83 35.58 16.03 35.58 83.97" fill="#205b99"/>
    <path d="M50,8.83V91.17L84.1,74.12V25.88Zm29.76,57L60.22,71.68V28.49L79.75,34.3Z" fill="#5294cf"/>
  </g>
</svg>

The polygon points are formatted wrong. Instead of 40.6 36.33 29.95 34.74 29.95 18.85 40.6 22.09 40.6 36.33, it should be 40.6,36.33 29.95,34.74 29.95,18.85 40.6,22.09 40.6,36.33 (notice they are now x,y separated by spaces).

I'd need to inline fix the files somewhere (/tmp?) and then import those into svgpathtools to read them correctly, since the library only takes filename's and not content strings. flips table

[abesto]

Doesn't sound all that bad; you can use the tempfile Python module to get "safe" temp files. With that change I'd be OK merging this as good enough, we can always iterate.

[abesto]

You know what? This is good enough. Merging, with huge thanks for automating this tedious job.