OSM icons for website to SVG

[hiddewie]

Part of #850

Split off from #4775

This pull request replaces PNG images for the OSM logo with their minimized SVG variants, to ensure screens with high pixel densities can display the OpenStreetMap website with beautiful graphics.

Email has not been changed because SVG support in e-mails is difficult (ref #4775 (comment)).

[tomhughes]

Looks good to me. How sure are we that all OpenGraph consumers are going to cope with SVG icons?

[AntonKhorev]

See #4793 (comment)

What would you rather edit
or ?

Some people want to edit the logo: https://community.openstreetmap.org/t/binary-numbers-on-osm-logo-could-be-changed-to-have-a-real-meaning/100498

[gravitystorm]

for the signup and terms illustrations

copy+paste error in the issue description

What would you rather edit...

I agree with Anton. These are source files, they should be created in a way that helps the developers/designers first and foremost. Performance is a secondary matter. If we need to change options or whatever with svgo then lets do it there, rather than making the source files harder to work with.

Otherwise, it makes it harder for new developers to get started. A developer should be able to use common tools (e.g. Inkscape) to create a new icon, without having to hand-edit (using an undocumented process, btw) the file to get it ready for a PR. So again, it's more important that the tooling does whatever we need it to, rather than add constraints onto the developer/designer.

[hiddewie]

copy+paste error in the issue description

Oops, fixed. I was indeed copy-pasting all of the PR descriptions as I split them off from the initial PR.

Some people want to edit the logo: https://community.openstreetmap.org/t/binary-numbers-on-osm-logo-could-be-changed-to-have-a-real-meaning/100498

Yes indeed, I checked the history of the logo:

So in more than 10 years, the logo has been created and modified once. The other 2 commits are renames.

---

On the topic of using a tool like svgo for minifying / optimizing such SVGs. I tried this locally, and I found some problems with this approach, taking the source design files and using them directly to produce (minified) output for the web.

Problems:

• Clips sometimes do not work as expected
• Text is not rendered correctly if the font is not present on the system, or not at all
• Images such as in the OSM logo are still persisted (outside the viewable area) into the output SVG.

I ran the svgo tool like

svgo --input ... --output ...

so with the default plugins enabled. I could not find any plugins in the list of plugins that would help us solve the above problems.

Some example output of the terms SVG:

My conclusion is that the svgo tool cannot solve the SVG minimization problem right from the source illustration files. So if the design illustrations should be kept intact, then they should be kept in a different directory (where assets/ in the project root?).

Then the process to convert such a designer SVG file into a file ready for minimization, would be:

• Convert all text to paths
• Remove clips by intersecting the paths in the clip with the clip mask
• Remove any content outside the viewbox
• Remove any image content

Then, I put the files in https://vecta.io/nano to minimize them, but they could also be processed by svgo (as long as all plugins are enabled, some are disabled at the moment in https://github.com/openstreetmap/openstreetmap-website/blob/master/config/image_optim.yml#L5).

After that I auto-formatted (Jetbrains IDE) the minimized SVGs to make them nicer to read for humans with newlines and indent.

[hiddewie]

It seems that Facebook does not like SVGs as opengraph images, so I will revert that one as well.

[tomhughes]

I assume the cleanupIDs svgo plugin is disabled because we have things that use ids to pick out parts of sprite images for display and removeUnknownsAndDefaults is disabled because of openstreetmap/iD#4105.