Rework 'make generate-images'

[silverwind]

• Remove external dependencies and replace it with a node script that does does the same.
• Move detail removal from gitea-sm.png to favicon.png
• Remove favicon.ico and its generation, it is unused and we already serve favicon.png in its place.

Fixes: #12314

[stertingen]

Thanks for this PR as this will fix my initial problem. (#12314)

But isn't it a bit overkill to download chromium just to build a bunch of png images? Why not use the original SVG image instead of the PNG images?

logo.svg: 5.6K (base image size)
gitea-lg.png: 33K
gitea-512.png: 17K
gitea-192.png: 4.2K
gitea-sm.png: 3.2K
favicon.png: 4.1K
apple-touch-icon.png: 4.1K

In some cases, the resulting PNG files are much bigger than the original SVG file, even after compression. I see that favicon and apple-touch-icon have to be a rasterized, but using the SVG for the larger variants might reduce the amount and size of transmitted images.

[silverwind]

But isn't it a bit overkill to download chromium just to build a bunch of png images

Probably is, but svgexport was just the first cross-platform tool I've found that was up to the job that can be easily installed with only our existing dependencies on Node/Go and which does not require messing with PATH (like Inkscape would).

Probably possible to use https://github.com/lovell/sharp but it'll be more involved.

Why not use the original SVG image instead of the PNG images?

I agree we should ideally only use the SVG image in the UI but it'd be quite a bit of work and I think some parts of the code can only work with bitmap images (avatar) and then there's the issue that not every image can be represented as an SVG (think photos).

[silverwind]

Updated to use a node script and two npm modules in place of previous Chromium-based solution. It uses JSDOM's canvas renderer under the hood whose SVG implementation is probably not as complete as Chrome's but seems to work fine for our logo.

Those modules are now only installed on demand, otherwise we would gain 215 new transitive devDependencies which I think are better avoided for such a rarely used task.

Reviewers should check the diff on public/img/gitea-sm.png which gained some detail. I think the change is fine to keep.

[stertingen]

I like this better, thanks!

[lafriks]

You could just use domxml to remove layer in svg before generating gitea-sm

[silverwind]

xmldom you mean? Yeah, certainly possible and probably better than the string modification.

I'm still contemplating whether to add the dependencies to devDependencies. Probably better in the long run.

[silverwind]

I think I will actually do the layer removal but only for the favicon because that is rendered the smallest (16px):

gitea-sm is used on the page header at 30px and I think it would benefit from the detail, especially on hidpi screens:

Regarding devDependencies: I will keep it the current way because zopflipng requires a native dependency and that's a no-go for our bundled node_modules in the src tarballs.

[lafriks]

Yes, xmldom :) It's already dependency for svg2img so that would not add much to node_modules size

[silverwind]

Done. Detail is now removed from favicon.png instead of gitea-sm.png previously. Also squashed and update description.

[silverwind]

Updated to use fabric to render into the canvas which allows us to skip a few wonky dependencies.