Potential improvements to be made to the generated svg code

[CodeF53]

Lets start by looking at your outputted nixos-logomark-black-flat-minimal.svg, (with a couple of newlines and tabs added for readability

<svg xmlns="http://www.w3.org/2000/svg" viewBox="-1650.8306325798367 -1496.4918977395098 3301.6612651596733 2992.9837954790196">
  <polygon fill="#000000" points="-624.0 249.4153162899184 -496.0 27.712812921102 63.99999999999994 997.6612651596733 -192.00000000000006 997.6612651596733 -320.00000000000017 775.9587617908571 -448.00000000000034 997.6612651596732 -576.0000000000003 997.6612651596732 -640.0000000000003 886.8100134752651 -448.0000000000001 554.2562584220408"></polygon>
  <polygon fill="#000000" points="-528.0000000000001 -415.6921938165305 -272.0 -415.69219381653056 -832.0 554.2562584220408 -960.0 332.55375505322456 -832.0000000000001 110.85125168440817 -1088.0 110.85125168440794 -1152.0 -1.7053025658242404e-13 -1088.0 -110.85125168440834 -704.0000000000001 -110.85125168440811"></polygon>
  <polygon fill="#000000" points="95.99999999999983 -665.1075101064489 223.99999999999991 -443.4050067376326 -896.0000000000001 -443.40500673763245 -768.0000000000001 -665.1075101064487 -512.0000000000001 -665.1075101064489 -640.0 -886.8100134752652 -576.0 -997.6612651596733 -448.0 -997.6612651596733 -256.0000000000001 -665.1075101064489"></polygon>
  <polygon fill="#000000" points="624.0 -249.41531628991848 496.0 -27.71281292110206 -64.00000000000007 -997.6612651596733 191.99999999999994 -997.6612651596733 320.00000000000006 -775.9587617908571 448.0000000000002 -997.6612651596732 576.0000000000002 -997.6612651596733 640.0000000000002 -886.8100134752652 448.00000000000006 -554.2562584220408"></polygon>
  <polygon fill="#000000" points="528.0000000000002 415.6921938165302 272.00000000000017 415.69219381653045 831.9999999999998 -554.2562584220411 959.9999999999999 -332.5537550532249 832.0000000000001 -110.85125168440845 1088.0 -110.8512516844084 1152.0 -2.8421709430404007e-13 1088.0 110.85125168440794 704.0000000000001 110.85125168440788"></polygon>
  <polygon fill="#000000" points="-96.0 665.1075101064489 -224.00000000000009 443.40500673763256 896.0 443.4050067376328 768.0 665.107510106449 511.9999999999999 665.1075101064491 639.9999999999997 886.8100134752656 575.9999999999997 997.6612651596736 447.99999999999966 997.6612651596737 255.9999999999999 665.107510106449"></polygon>
</svg>

All of the decimal precision here is comical, you do not need 13 digits of precision here, you literally have multiple instances of stuff as bad as 255.9999999999999 and 704.0000000000001 I would recommend a pass through svgo to get rid of these

Why are you specifying fill="#000000" when 1: you could do #000 instead, and 2: the default fill is already black so you don't even need a fill attribute. A pass through svgo would also fix this

6 redefinitions of <polygon> when they are all exactly the same shape is a bit wasteful, here is how I would improve it with <use>

<svg xmlns="http://www.w3.org/2000/svg" width="512" height="512">
  <defs>
    <polygon id="hl3" points="-99.5,5 -128.5,55 -94.5,114 -142.5,196 -127.75,221.25 -99,221.25 -65.5,164 -32.5,221.25 25,221.25"  />
  </defs>
  <g transform="translate(256,256)">
    <use href="#hl3" fill="#fff"/>
    <use href="#hl3" fill="#f5a9b8" transform="rotate(60)"/>
    <use href="#hl3" fill="#5bcefa" transform="rotate(120)"/>
    <use href="#hl3" fill="#fff" transform="rotate(180)"/>
    <use href="#hl3" fill="#f5a9b8" transform="rotate(240)"/>
    <use href="#hl3" fill="#5bcefa" transform="rotate(300)"/>
  </g>
</svg>

I would make a pr but I cant for the life of me understand this repo and how it generates stuff, I really prefer the old one

[TheArcaneBrony]

user is upset about floating point roundating errors, natural to floating point computing, showing up in generated code

Sure, lol

[numinit]

Hey there! I see that you submitted a PR on nixos-artwork where the repo transition was mentioned. To quote the original issue's response from djacu:

You are also more than welcome to submit a PR but there is a non-trivial amount of tooling to become familiar with. Totally up to you. Let me know if I can be of any help.

Do you need help? There's an overlay on this repo where all the outputs are generated with FODs (and a script to regenerate the FODs), and a set of python scripts that generate the SVGs. I assume the precision can be controlled, though it uses svg.py to generate the SVG.

[piegamesde]

I may understand being upset about floating point rounding errors, but why in everything on earth would one want to use the #fff color syntax? I've always only ever viewed it as a legacy syntax quirk kept alive only because of backwards compatibility.

[dcarosone]

@CodeF53 please reword the title and content of this issue to be more considerate of the other people whose work you are critiquing, in line with our code of conduct

Constructive criticism of the code is valid (although as others have pointed out, may at present be somewhat misplaced as the machine-generated code has already been noted as suboptimal). But it's harder to see the comments as constructive with this phrasing.

(on behalf of @NixOS/moderation)

[CodeF53]

Rewrote issue in an attempt to be more constructive

[djacu]

Well you certainly changed the title and added another sentence.

All of the decimal precision here is comical, you do not need 13 digits of precision here, you literally have multiple instances of stuff as bad as 255.9999999999999 and 704.0000000000001 I would recommend a pass through svgo to get rid of these

You could certainly round 255.9999999999999 to 256, but what should 249.4153162899184 be rounded to? I saw that floating point issue in early development but a solid metric for rounding, it's a recipe for potential issues.

Why are you specifying fill="#000000" when 1: you could do #000 instead, and 2: the default fill is already black so you don't even need a fill attribute. A pass through svgo would also fix this

Color values are handled by coloraide.

6 redefinitions of when they are all exactly the same shape is a bit wasteful, here is how I would improve it with

Might be possible. Will think about it.