refactor: simplify public/images/banner.svg for easier manual editing

[mskiptr]

This removes about 20 KiB of unnecessary fluff from the SVG banner logo (out of ~40 KiB in total). None of that should change the visual appearance of the logo, though.

To ease the review process I strived to keep every commit narrowly focused. In cases where the default line diffs were not readable, I also included examples of git commands that make the actual change clearly visible.

That doesn't mean much review is actually needed here – the resulting SVG looks exactly the same as the original and passing it through the W3C's validation tool no longer raises any errors nor warnings (before my changes, it used to complain about a few old Inkscape things).

[mskiptr]

Hi @MightyCreak (I see this might be a lot of commits to review for little immediate benefit, so no worries if you don't have the time to look through them.)

I was hoping to make the banner logo easier to tweak from CSS and small enough so that inlining it into the HTML isn't a problem. Both of those would make resolving #332 much easier I believe. This patchset contains only pure refactors – no commit here should have any observable effect on the website. However, I would like to eventually follow it up with a few more changes – e.g. to the grid in the background of the banner (a few lines there are slightly misaligned and every single one is a whole independent object). That would also lower the file size quite a bit.

Whether the file size part actually matters is rather unclear though. The generated HTML absolutely dwarfs the SVG in character count – they are at 1369 KiB and 38 KiB respectively (with this patchset bringing the SVG down to just 19 KiB). But thankfully, the web server doesn't send out 1.4 MiB to every single visitor. Compression makes a huge difference here:

$ curl --write-out='%{size_download}\n' -so /dev/null https://mesamatrix.net
1401874
$ curl --compressed --write-out='%{size_download}\n' -so /dev/null https://mesamatrix.net
51835
$ curl --write-out='%{size_download}\n' -so /dev/null https://mesamatrix.net/images/banner.svg
39366
$ curl --compressed --write-out='%{size_download}\n' -so /dev/null https://mesamatrix.net/images/banner.svg
39366

It brings the HTML down to a much more manageable 51 KiB. Though it doesn't seem to kick in for any of the images for some reason:

$ curl --compressed --write-out='%{stderr}%{size_download}\t' -s https://mesamatrix.net/images/feed.svg | wc -c
1128    1128
$ curl --compressed --write-out='%{stderr}%{size_download}\t' -s https://mesamatrix.net/images/mesamatrix-logo.png | wc -c
19272   19272
$ curl --compressed --write-out='%{stderr}%{size_download}\t' -s https://mesamatrix.net/images/gears.png | wc -c
4033    4033
$ curl --compressed --write-out='%{stderr}%{size_download}\t' -s https://mesamatrix.net/'css/style.css?v=3.0' | wc -c
4076    15723

I guess inlining the SVG into HTML would right now actually be a net benefit. At least bandwidth-wise. Later on, I would like to see what exactly makes the site weigh that 1.4 MiB.

Anyway, back to the main topic:
Would you find it helpful if some other contributor tried reviewing these commits, or even just acked them?

[MightyCreak]

While I see the gain, I'm not sure I want to go in this direction in terms of maintainability.

Here's my rationale: the SVG comes directly from Inkscape. Right now, if I want to update the logo, I can simply open it in Inkscape and do the changes (and anyone can actually do that). With your changes, then someone (you?) will have to do all the work you just did all over again.

For instance, I just opened the image in Inkscape and the file is apparently very old and Inkscape wants me to upgrade the file, which adds/changes the content and would indubitably create conflict with your changes if I wanted to push them.

If we want to minify this file, we need to find a automatic way of doing it (I don't know if that exists already). And even if we find a tool for that, then it will change the way I deploy the website as I would have to "compile" the project before publishing it, so that the tool would run and minify everything that requires it (such as CSS and JS scripts).

This is a much more modern workflow that I willingly didn't use (mostly because I didn't know how to at the time, but also because, at first, I just wanted a simple website to follow Mesa's improvements on OpenGL).

I know you've put a lot of effort into that, and I'm sorry that my answer doesn't go in your direction. I hope you understand the reasons why.