(Manual) birth of a logo (2)

I did it again. I mentioned it when talking about my “cool S” experiments, that the proposed Fediverse logo suffers from the issue of all SVGs drawn via graphical software, that the code ends up being just “a bunch of numbers”, even when there's a clear mathematical/geometric way to describe the drawing.

So yeah, I decided to redraw it, hand-crafting an SVG that followed the mathematical principles behind the original design, and the results are clear: you can code the same (or similar) graphic in half the (disk) space, and in many ways it's a more elegant design, even when there are little or no aesthetic differences.

My SVG has several advantages, including a better centering of the pentagon in its bounding box, and having no intrinsic width, allowing it to adjust better to its surrounding:

OK, in this case there are some small differences, but the main reason for this is that I had to do some guesswork about the sizing of the elements, and due to my passion for powers of 10 and powers of 2, I ended up drawing a slightly larger pentagon: the nodes have a 16-unit radius, and the whole pentagon including them fits in a 100-unit circle, so the radius of the pentagon circumcircle is 84 units; the original one was apparently slightly smaller, which gives the impression that the connectors in my drawing are thinner, at least in proportion to their length. (Also I lied, all lengths have been scaled up by a factor of 10, to avoid using decimals, so it's 160 out of 1000, but the idea is the same.) I may revisit this particular aspect in the future, to build a more accurate recons

There were a few things that were a bit frustrating when preparing this design, but the biggest one was probably that there is no easy way in SVG to do an “inverse clip”: it's easy to say “draw the part of this element that is contained inside this other element”, but not the reverse (“draw the part that is outside of this other element”), and while one can abuse masks for this, the setup is more complex than it should be, and the results are often underwhelming, since some browsers suffer from “early rasterization” when masks are involved, ruining the advantage of SVG for vector art in the first place.

This makes the sides and diagonals of this particular drawing more complex to draw than would be needed otherwise: instead of being simple rectangles clipped to not touch the nodes or create the over/under pattern, they have to be replaced with more complex paths that have to follow the boundaries of the clipping region.

(Still, if anybody has suggestions on how to do this in a more compact way with clipping, do let me know.)

My SVG is also more elegant “internally”: instead of being a bunch of paths with numbers of unclear meaning, the symbol is built “conceptually”: I define one element for each conceptual element (the node, the side, the “split” diagonal), positioned in their “initial” position:

<defs>
<circle id='node' r='160' transform='translate(0,-840)'/>
<path id='side' d='M 0 -50 h 320 a 180 180 0 0 0 0 100 h -640 a 180 180 0 0 0 0 -100 z'
 transform='rotate(36)translate(0,-680)'/>
<path id='diag' transform='translate(0,-260)' d='
 M -100 -50 h  725 a 180 180 0 0 0 0  100 h -757 z
 M -278  50 h -348 a 180 180 0 0 0 0 -100 h  381 z'/>
</defs>

and then simply “paste” them five times around the center, rotating by 72° each time:

<use href='#node' fill='#ffca00' transform='rotate(  0)'/>
<use href='#node' fill='#64ff00' transform='rotate( 72)'/>
<use href='#node' fill='#00a3ff' transform='rotate(144)'/>
<use href='#node' fill='#9500ff' transform='rotate(216)'/>
<use href='#node' fill='#ff0000' transform='rotate(288)'/>

<use href='#side' fill='#ebe305' transform='rotate(  0)'/>
<use href='#side' fill='#30b873' transform='rotate( 72)'/>
<use href='#side' fill='#5b36e9' transform='rotate(144)'/>
<use href='#side' fill='#d0188f' transform='rotate(216)'/>
<use href='#side' fill='#f47601' transform='rotate(288)'/>

<use href='#diag' fill='#dbb210' transform='rotate(  0)'/>
<use href='#diag' fill='#57c115' transform='rotate( 72)'/>
<use href='#diag' fill='#5496be' transform='rotate(144)'/>
<use href='#diag' fill='#a730b8' transform='rotate(216)'/>
<use href='#diag' fill='#ce3d1a' transform='rotate(288)'/>

This obviously defines the symbol “straight up” (upper vertex straight in the middle, bottom side parallel to the side of the bounding box), so all of this is wrapped in a group that is rotated 10 degrees, and then translated to center the result inside the bounding box:

<g transform='translate(-50,30)rotate(10)'>
 <!-- stuff shown above --->
</g>

Not only the SVG source is clearer about what it does, but even with generous whitespace the total file size of this minimal version is only 1480 bytes, which is around 2/3rds of the 2237-byte currently on Wikipedia, which is itself already optimized for (disk) size.

Of course the full thing includes metadata and a “debug” pentacle that makes the size grow to 3496 bytes (at the moment of writing), but as already discussed the last time this is mostly due to the metadata about authorship and license. The “debug” pentacle alone isn't enough to blow the size over the Wikimedia Commons size!

Again, this is thanks to judicious use of a more abstract geometric description of the figure. The only thing that remains to be solved in this sense is the description of sides and diagonals. Here's to someone managing to crack this nut.

OK, an update. I've tried to reconstruct the length ratios from the original design and from what I can see it was an entirely “visual” design. If there was an intent for “obvious” ratios in the original design they have either been lost through subsequent editing (scaling, rotations, etc) or they were based on some less obvious and potentially irrational aspects like the golden ratio.

I've been taking notes about it on the Fediverse, but the gist of it is that the figures are all quirky. The main design rotation angle seems to be around 9.12° (9°7'12"), the node radius something like 16.57, outer node radius 18.23 and so on and so forth.

If I try to scale everything so that the node radius is 16 units, then the outer node radius is closer to 17.5 (i.e. the gap between the nodes and the side bands is around 1.5 units) the side and diagonals have a thickness of around 10.5 units and the over/under gap is around 2 units, with a circumcircle radius (the one passing through the center of the nodes) of 71.5 units.

So I've come to think that I have two possible paths to follow here, if I want to make my design closer to the original one: one is to stick as close as possible by scaling units up to make them integer, and the other is to round them up myself and go again my own way, while still trying to stick close to the original.

The rounding up would still have some weird lengths/ratios, though. For example, multiplying by 2, the circumcircle radius would be 143, the node radius 32 with an outer radius of 35 (3 units gap around them), sides and diagonals would have a thickness of 21 units and an over/under gap of 4 units. The angle would still be a weird 9.12 degrees.

But I think in this case it's OK to diverge from the original design a little bit, to try and give figures some kind of meaning. This would mean a circumcircle radius of 72 (inspired by the pentagon's inner angles of 72°), a node radius of 16, a side/diagonal thickness of 10 units, and make all gaps 2 units wide. The figure would be rotated by 9°, which happens to be 1/8th of the pentagon's inner angle.

For the view box size, we need 144 units from the diameter of the circumcircle, plus 16 in each direction to account for the node radius, going to 176. If we add 8 units of slack/padding on each side we get to 192 units, which —while not a power of two— is not an uncommon “large icon” size, being $4\times 48$ or $3\times 64$.

Since even with these choices we end up needed fractional units for centering and the diagonal definitions, we can once again scale everything up by a factor of 10, and the result is the following:

The new version is much closer to the original. If we look at the amount of padding in the image, however, we see that the 8 units we had planned, after proper centering of the figure we have nearly 24 units of slack, due to the fact that the diameter of the pentagon is around 10% of a radius shorter than the diameter of the circumcircle. This can be seen in the new “debug” symbol, that includes an “inner frame” with tight spacing around the final symbol:

(The actual sides of the inner squares are 169 units.) This is actually consistent with the original logo, but may be too much whitespace for some, so for the “minimal” version of the SVG (no metadata, no debug) I've decided to provide both a “slack” and “tight” version.

Of course, the reduced slack leads to an apparent larger size for the symbol when seen side-by-side with the version with more generous spacing, but it allows more precise control of the symbol placement and sizing in all other contexts.

The new minimals are 12 bytes larger than the v1, but that's only because I was a bit more generous with the whitespace and made the root svg element addressable (with id logo). We're still at around two thirds of the Wikicommons version, but with a scalable, geometric designed. It's a definite win.

And it's even better for the monochrome version, that drops to 1080 bytes including “dark color scheme” aware styling:

Another update. Apparently I'm not the only one who looked into a more algorithmic definition of the logo. Here for example there's someone who went as far as looking for an algorithmic definition of the colors, while building a Julia program for the design. I like the idea of the fractal design presented there, possibly because I was thinking about something similar as a prelude to combining my rebuilt Fediverse logo with the cool S design for the new “Share to the Fediverse” image. The animation on the other hand is a bit distressing, which is also driving me off an idea I was starting to ponder along the lines of the Fediverse logo rolling inside the “cool S” symbol. Aside from the complexity of the animation (nothing that can't be tackled), I'm now aware of how distracting it would be to have an always-on-animation, so if I ever get to something like that it'll only be on hover or something like that.

Yet another update! The author of the original proposal graciously commented on my Fediverse thread about the geometric reconstruction of the logo, and revealed that the aim of the rotation was to try and make the rotated pentagon fit in a square.

As it turns out, however, it's not actually possible to do this while keeping the (circum)center of the pentagon in the same position as the center of the square: the only way to get a square is with a 9° rotation (plus or minus multiples of 18°), but that does require a shift. (I might write a Mathesis article on this some time in the future. But as things stands, no changes to my geometric SVGs are necessary. phew)