resolves #2 propose colors for logo

[marianhlavac]

⚠️

Looks cool on my MBPro Retina display. But I can't say the same when viewing the logo on other monitors I'm using, or my colleagues use.

The logo goes more pink-ish on lower quality monitors (which could affect a lot of users).

We should take care of this, before setting the final color. I will collect screenshots, photos, compare them and open a new issue about it.

[mojavelinux]

Thanks for doing this research, @mmajko. I don't mind working on those changes as part of this issue.

Notice that I revised the SVG slightly as well. I removed the doctype declaration and also the width and height on the root element. I think that makes the SVG easier to embed and style in HTML, though I'm far from an expert on the matter.

I also removed the IDs. However, I think those might actually be useful to keep for editing purposes.

[marianhlavac]

Edits in raw SVG are appreciated, I haven't changed the SVG after exporting from Affinity Designer.

[ggrossetie]

The logo goes more pink-ish on lower quality monitors (which could affect a lot of users).

The logo looks fine on my desktop (Samsung SyncMaster P2350 1920*1080) and mobile screen (Moto Z Play).

It's true that the logo is a bit more pinky-ish on a low end screens but it's not too bad... the logo still looks fine! I guess it's because low end screens are not correctly calibrated and/or the color balance is bad ?

[mojavelinux]

I am fine with keeping the SVGs in raw state, but I think we should agree that we'll using Inkscape as that makes it most accessible to contributors. We may also have an optimized folder for simple distribution. But eventually we'll want a build process to manage that folder.

[graphitefriction]

I like having the base images in raw (un-optimized) format since it can make it easier to manage individual objects/layers (optimization squashes layers and reconfigs groups). I'm not so in love with the "use inkscape" part - even though it's my main SVG tool - if the xml from a specific SVG program needs to be massaged/stripped before merging a PR we can just pull it in and re-save with Inkscape, then merge. (Because we all love some sodipodi in our SVGs :tada: :wink: ). As for a dir for optimized SVGs - sure, but how much do you want to optimize, because there's basic optimizing, then there's run it through 2-4 different processors optimizing :stuck_out_tongue_winking_eye:

[graphitefriction]

It may not be directly applicable for this but I've been meaning to look into the sprite generation/SVG linting in this repository: https://gitlab.com/gitlab-org/gitlab-svgs/tree/master and see if they've automated the processes enough (and the output is quality enough) to make setting something similar up a good use of time. (Or maybe it's more useful for managing/optimizing UI graphics and icons)

Node.js tool for SVG optimization: https://github.com/svg/svgo

[mojavelinux]

The reason I suggested Inkscape is because programs tend to completely modify the XML when making edits, so the only way we're going to be able to collaborate effectively is if the XML remains somewhat stable from one change to the next. And since Inkscape is free and open source (and very capable), I think it's a reasonable compromise. I'll keep an open mind about it, though.

[mojavelinux]

Let's deal with favicons and optimized images in a separate issue.

[mojavelinux]

I'm extremely happy with how these images look now, especially the accent color. After trying out a couple more colors in different settings, I settled on #e40046 (rgb 228, 0, 70). It's a very robust carmine color (and recognized by the pantone color system).

Thank you @graphitefriction and @mmajko!!

With that settled, I'm prepared to move forward.

[mojavelinux]

I forgot to mention that we decided to drop the black border around the icon. I think the icon looks really good on its own. Besides, everyone wants to crop logos these days anyway, so this makes it more portable.