New backends

[p3jawors]

Both light and dark, full and square logos for nengo dl, spa, spinnaker, loihi, braindrop, and fpga.

[bmorcos]

When I added the favicon I noticed it was a little small. Looks like we need to crop everything to have tighter borders (even with the transparent background).

I'll look at resizing them this afternoon.

[tbekolay]

Thanks @bmorcos! And @p3jawors of course for the original logos, with the new website work we'll definitely be wanting to merge these in pretty quickly.

[bmorcos]

I think they should be all good now. LGTM?

[bmorcos]

FYI I didn't touch anything in general.

[drasmuss]

Sorry just getting to this now. I've only looked at the NengoDL stuff, but some comments on those:

favicon.ico

Size has been reduced from 32x32 to 16x16. I think 32x32 is better, makes the icons crisper. Having the gradient on the N lines also just ends up looking blurry to me at this size, but that might be solved by moving to 32x32.

full-light.svg

I like the look of adding the gradient to the N lines on this one 👌

full-dark.svg

The N lines look washed out to me
old:

vs new:

square-dark.svg

The gradient on the N lines looks backwards to me; I think that we want the "brightest" line on top, fading to darker colours at the bottom.
old:

vs new:

icon.png

Size increased from 100x100 to 800x800. But for sphinx themes (the most common use for these logos I suspect) the logo width needs to be <= 200 (http://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_logo).

[bmorcos]

I can take a look at making these changes if everyone agrees with Dan

[bmorcos]

I went ahead and made the Changes @drasmuss highlighted.

• I made the logo.png 150x150 instead of 100x100
• I made the favicons 48x48 instead of 32x32

[bmorcos]

We can probably close #4 as well.

[drasmuss]

Thanks! All looks good to me now, except for full-dark. Sorry, I couldn't really figure out why it looked off to me before, but now I see. I think the idea with the gradient is that we want it to fade from the base colour (e.g. orange) at the top into the background colour at the bottom. So if the background is white, that means going from orange->light orange (as in full-light or square-light), but if the background is dark, that means going from orange->dark orange (full-dark). Right now it goes from orange->light orange, which is what seems off to me.

Note that the way I did that originally was by using one base colour and then adjusting the alpha, as opposed to adjusting the RGB. That makes it nice and easy, and means that we only need to worry about one canonical colour for each logo. But I'm not sure if there is a reason to prefer the RGB method.

[bmorcos]

Good point, I inverted the gradient on the dark logo, how's this?

We can also go lighter, but we risk getting back to the washed out look you cited before.

Regarding the RGBa colours, I just used what @p3jawors came up with (I believe he used a website that generates tints based on a colour). It may be easier to use a single colour and adjust alpha, but in that case the background colour comes into play. So I believe using different RBG values will actually give us a more consistent logo across different uses.

[tbekolay]

Yeah I was going to say also that browser support for transparency in SVGs is not as good as one might expect, so it would maybe be good to make sure none of them use transparency. Would be good also to write up a short list of rules / guidelines as to how these logos are made, though I don't want that to block the PR. Similarly, it would be good to write the pirmary color's hex code in the README.rst for each project so we don't have to pull out the eyedropper to get it later on. But yeah, those are nice-to-haves but not blocking for merging.

[drasmuss]

Personally I would have it start with the "base" orange and then fade to dark from there, rather than starting with the whitish-orange and then fading from there. But I don't feel that strongly about that one, if others like it the other way around I'm totally fine with that.

[bmorcos]

Alright, let's get a vote in so we can move forward.

base colour fade to dark 🎉

white fade to base colour ❤️

We can get that settled and open issues to address the other points from @tbekolay (README details and transparency).

[bmorcos]

Ready for another review!

• I made sure no logos are using transparency
• I added the base colour to the project README and added some details to the guidelines file
• Made the dark logos fade from the base colour to dark

[p3jawors]

I think the base fade to light makes more sense since it's fading towards the white text, the gradient transitions better.

[bmorcos]

Added a script that takes the RGB of the base colour and prints the tuning curve colours for each logo.

12:18:17 ben@phoenix ~/Git/design new_backends*? ∴ python generate_colors.py 0 192 222
#######  full-light  #######
Top   : #00c0de (0, 192, 222)
Middle: #32cce4 (50, 204, 228)
Bottom: #66d9eb (102, 217, 235)
#######  square-light  #######
Top   : #00c0de (0, 192, 222)
Middle: #32cce4 (50, 204, 228)
Bottom: #66d9eb (102, 217, 235)
#######  full-dark  #######
Top   : #00c0de (0, 192, 222)
Middle: #0099b1 (0, 153, 177)
Bottom: #007385 (0, 115, 133)
#######  square-dark  #######
Top   : #ccf2f8 (204, 242, 248)
Middle: #99e5f1 (153, 229, 241)
Bottom: #66d9eb (102, 217, 235)

[drasmuss]

Looks good! I pushed a fixup with some minor changes (simplifying things a bit, pep8 stuff, using numpydoc conventions, and adding some u's because God Save The Queen).

[drasmuss]

Was just doing some testing for a different issue, and noticed that despite what the documentation says logos >200px seem to work fine. So what I said above isn't true, it's probably fine to include logos that are a bit higher resolution if we want.

[tbekolay]

This has lingered for far too long! I want to get this merged in today or tomorrow, but the main sticking point is to do with filenames. With the way things are set up now, all the svg files in here will end up getting copied to the _static directory when Sphinx builds the docs, and the filenames will not reflect the project they belong to (i.e., _static will contain full-light.svg, full-light-1.svg etc and it's not clear which project will be which, and whether that will change over time). @drasmuss and I have a few ideas about how to do this, depending on the kinds of hooks that Sphinx provides, which we'll look into today. It shouldn't take long though, so if anyone was hoping to comment / suggest anything on this then now's the time.

Also an FYI, in the merge, I will also edit text / add a short note to reflect the decision made in #9.

[drasmuss]

Added a commit to take care of those filenames. Now there will be nengo-fpga-full-light.svg, nengo-dl-full-light.svg, etc.

I also renamed all the nengo_project names to nengo-project.

[tbekolay]

Did a once-over of the logos, all looking good to me, and added more text to the guidelines. It could be improved, but I want to get this merged now so we can start linking to the logos. Thanks for the awesome Inkscaping @p3jawors and @bmorcos!