I got an email from Andy Fitzsimon the other day about some projects he’s working on. One of which was logomono, something I thought looked pretty interesting and shared the other day. I thought, rather than trying to figure things out and re-explain them myself, I’d just ask Andy himself to answer my questions. Interview style.
My questions as headers; Andy’s replies follow.
Can you give us a quick explanation of exactly what logomono is and what the motivation is behind it?
logomono is a big(ish) and growing GitHub repo of one-color SVG logos. The project exists to promote care for how we use and reference logos on the web.
The site also covers some techniques, a few tools, and some tutorials aimed at making it easier for designers and developers to use logos.
To keep things super simple, all the SVG’s are made of only a few flat <path>s and no color.
The first thing presented on the logomono homepage is an idea for making logos work on dark or light backgrounds. Is that a problem you’ve faced? Do you think that’s a prereq for any truly robust logo?
For so many existing logos, inverting correctly is certainly a polite and a nice thing to consider. It is a feature of logos that is largely ignored today. If the logo you use features shading (or a handful of other considerations), there likely a different version and you should use on dark backgrounds. For logo designers, it’s a commitment to make multiple variants of logos to work for both light and dark situations, but it’s a fairly common need. Remember your logos aren’t always exclusively used by you.
logomono was was born from frustrations at my day job as a brand manager at Red Hat. Shadowman (the icon in the Red Hat logo) has a shadow cast over his eyes. It doesn’t really work when the same fills are inverted on dark. He’d be more a laser-eyed man with those dark bits filled in white.
The same can be said for my two favourite open source project logos:
Inkscape (which features inky the splotchy mountain) and Linux (with Tux the penguin)
We know Penguins have black wings and white bellies. We know that ice caps on mountains need to be lighter than the mountain. It’s amazing that this detail can be so looked over.
To help with this problem, we could tell this a million times to a million designers through our lifetimes. Or, we could write it down and try make it useful enough to remember. That’s why logomono exists.
At work I’m always getting proofs of things from customers, partners or staff using a wrongly inverted one color Red Hat logo. It hurts double time. One, because it’s the wrong logo. Two, because some poor bugger had to go to the effort of making it from the full color logo they probably found on Wikimedia. Maybe they even guff up the coordinates. Maybe our logo loses it’s nose.
Some designers search “one color [company name] logo” and find the right thing for the right background. But today, all they get are sites like Brands of the World and Wikimedia. Not to mention there are nasty sites out there with downloadable files created from auto-traced vectors and very old logo versions that just won’t die. I want to proactively serve them the better versions. I want to raise awareness that inversion is a thing the folks behind the logo would like to be considered.
Being mono-color is part of the deal, too. In my case, I want our red hat to be, well, red, but when stacked next to other company logos I can understand the the need for visual harmony.
It looks like an inversion-ready logo requires some hide/show flip-flopping and sometimes additional elements. Is resource size any concern there? Or the embedding technique?
I suggest two optional classes for potentially three types of <path>s:
- Normal paths. No classes needed. They should show all the time. Usually logo text and, for many brands, the entire logo outline. Nike, IBM, Intel… You lucky brands!
- Only light backgrounds. Use
class="only-light-background"for shapes that should be rendered as darker fills on lighter backgrounds.Think: anything with eyes. You want the path that draws the pupils dark. Look at brand marks for Hadoop, Tux, or even companies without mascots like Ford that prefer their name be written as light text and inverted accordingly.
- Only dark backgrounds. Use
class="only-dark-background"for paths that only work as a light fills on a dark background.
Defaulting to the assumption of a light background is how we’re storing them in the repo. That way the files are still usable in their raw form. That means inline style="display: none;" is in use on the paths for only dark backgrounds. This can be removed in the build process.
How you use logomono could be different depending on what you need to do. If you have some interactivity that inverts the background, then it makes sense to keep all paths together in the SVG and overwrite the display, opacity or visibility values in your CSS to flip the light and darks as you need them.
If you only need one version (a dark or light version) then you could use logomono logos but have a tool like Gulp or Grunt run a task that strips the paths you don’t need.
You suggest using a viewBox but not height or width attributes. Is that recommended in production, or do you mean those can be added later? I’ve found without a default width/size, the SVG will be as-wide-as-it-can-be until CSS resizes it, which can be an unfortunately janky loading experience.
It’s to keep the repo lean and mean. We want width and height to stay away until the user knows what they want.
If you take every logomono file and add some random dimensional attributes like width="100px" height="76px" to the <svg>, nothing will break. You’ll have every logo in the size you declared and avoid the janky load. That can’t be said for a folder full of different sized logos. We can’t know your preferred dimensions ahead of the time, so we don’t add them (but you can).
Sites like Slides.com do this in a nice way, if you upload a viewbox-only SVG, the importer adds width and height attributes using the viewbox dimensions.
Another thing you recommend is 4% spacing around the logo because of aliasing. Can you elaborate on that? I would worry that aligning logo exactly to an edge then requires potentially frustrating pixel by pixel nudging.
This is something I’d like more feedback on. The problem is antialiasing overflows.
At first I was like “let’s make the source repo SVG’s go straight up against the wall: 0 0 min and max of their viewBox!”.
My thinking was that we could always use post processing to add the same gap dims to the viewbox to avoid antialiasing overflows. So for example, say a logo has viewBox=”0 0 120 150″. The processing makes it viewbox="-4 -4 124 154". Say another has viewBox="0 0 50 70". It becomes viewBox="-4 -4 54 74". This dodges the potential overflows.
But then I got thinking that adding and removing 4 to each axis in the viewBox would be different for SVG’s that have “big” coordinate systems versus “small” coordinate systems. Maybe it has to be based on a calculated percentage of the total of the viewBox lengths.
Then I realized doing all this in post processing would mean the source logos in repo would all be prone to the scaling aliasing issues as-is, which is a no-go because these files must be useful in their own right.
Then I got to thinking that this “4%” suggestion gives logo contributors a very small amount of discretion for optical adjustments.
Even if we lived in a magical land where scaled SVG had no hard edge aliasing problem, logos are like typography. Round forms and angles like O’s and W’s need to be nudged over the perceived edge lines to appear straight. 4% seemed like the easiest compromise.
For now, we’re throwing this whole idea into the “too hard basket”. Maybe we’ll re-compute the coordinates for the existing logos, but not today.
We designers are doomed to do the nudging when we layout our work. Hopefully with 4% as a general rule this becomes as minimal as possible. For the life of me, I can’t find out the right way to store and respect all the balancing factors at play that designers want to juggle:
- Logo and text along a baseline
- Thickness and weight balance
- Left/Right optical alignment
All while making these files “raw” enough to be basic building blocks of the web: easy to contribute; easy to use. At least now they’ll be close enough for forgiving eyes to deal with. Nudge away, soldier!
Maybe in the future when the web has wonderful things like element media queries we can expand logomono to include a general rule of thumb for vertically or horizontally stacked logos, or logos that collapse to an icon. For today, let’s keep things simple.
Can anyone contribute? If they can, what would be the most useful work?
Anyone can contribute:
- Mono-color Logos. By far the most useful contribution. Find the logos that are missing and send a pull request. Boolean those clip paths, outline that text, combine those duplicate control points.
- Tool and project page improvements.
- Awareness that some logos need inversion love.
It helps greatly if you are responsible for the brand in question so that the files can be optimised exactly as you want. But don’t let that stop you if you’re looking to add another logo.
