I wrote IdenticonSvg because I like using identicons as visual identifiers of HTML listings, e.g. in grids or in table rows, and didn’t want to deal with generating identicons in PNG and loading them from files or as base64-encoded data.
IdenticonSvg exposes a single generate/4 function that generates the SVG code of the identicon for the specified text argument, optionally with different identicon size, background color, and/or opacity.
Without specifying any optional arguments this function generates a 5x5 identicon with a transparent background and colored grid squares with full opacity.
Optionally, specify any combination of the following arguments:
size: the number of grid squares of the identicon’s side; integer, 4 to 10; 5 by default.
bg_color: the color of the background grid squares; string, hex code (e.g., #eee); nil by default.
opacity: the opacity of the entire identicon (all grid squares); float, 0.0 to 1.0; 1.0 by default.
Setting bg_color to nil (default value) generates only the foreground (colored) squares, with the default (1.0) or requested opacity.
The color of the grid squares is always equal to the three first bytes of the hash of text, regardless of which hashing function is used automatically.
A different hashing function is used automatically for each identicon size, so that the utilization of bits is maximized for the given size: MD5 for sizes 4 and 5, RIPEMD-160 for 6, and SHA3 for 7 to 10 with 224, 256, 384 and 512 bits, respectively.
This is great! I want to replace gravatars with SVG based generated icons and this is exactly what I planned to implement, until I found your library. Thanks for building it
Thanks! Let me know if you think that anything deserves an improvement! For example, I never got around to implementing automatic color-complementarity.
Indeed the only thing I’d add is automatic background color.
I’m using gravatar, see this page Explore - asciinema.org which displays author avatars at the bottom of each card using gravatar’s “retro” style. After replacing them with IdenticonSVG I realized the colored background in the gravatars gave it a more “complete” feel compared to the new identicon look.
For now I’ll probably use default transparent background, or a fixed color. I can look into implementing some automatic background mode in your library, and open a PR if I get anywhere with it and you’d be interested in such contribution.
New since v0.8.0: Setting bg_color to one of the following 3 atom values sets the color of the background squares to the corresponding RGB-complementary color of the automatically-defined foreground color, with the default (1.0) or requested opacity:
:basic: the complementary color, i.e. the opposite color of fg_color on the color wheel.
:split1: the first adjacent tertiary color of the complement of fg_color on the color wheel.
:split2: the second adjacent tertiary color of the complement of fg_color on the color wheel.
@ku1ik I’m working on merging rectangles and creating paths. I also realized that I don’t need to replicate the styling for each rect/path, but can wrap the foreground and background sets (when I have them working) into a <g> tag. I’ll let you know when I finally get it working, as I’m also interested in saving bandwidth, when I’m using this on listings with many different identicons.
One thing I’ve considered is that the duplication of text in the current version is probably not that bad, when your webserver applies gzip or brotli compression. Yet, I feel compelled to do it right
I think that when I will get this working, the library deserves hitting v1.0.
@ku1ik, this has been a crazy nerd-snipe… crazy fun too!
As it turns out, identifying groups of rectangles is fine – I cracked it elegantly by using Enum.reduce and Enum.reduce_until. See the PolygonReducer module.
The problem is the consequent conversion of the edges of those groups into paths, when the groups are topologically “donuts” with one or more “holes” within them.
In such cases, the outer list of edges is disjoint with the list of inner edges, which itself might contain disjoint “islands” of edge lists.
I’m in way over my head, and think that the simplest approach is this one:
Maintain the list of <rect> tags, but put them into a <g> node, which will style all of them at once.
Add a background rectangle covering the canvas.
Create a mask with the same content as the group of rectangles, to excise the foreground from the background rectangle.
Admittedly, this doesn’t save any space, but given that most web servers are likely to have gzip enabled, and also given the highly-compressible duplication of the rectangles, it would get the job done – with padding, and maintaining the ability to set the ability of the overall graphic to the same value without bg_color affecting the color of the foreground.
In fact, the example SVG linked to above is 1488 bytes long, but only 403 bytes long gzipped.
So, I think I’ll call it quits on solving this, and will approach this as in the list above.
Compared to v0.8? How so? Using single background rect (in my PR) reduced the size by almost 50%, and you mentioned you’ll do this in your impl too. So, is there extra overhead somewhere else which reduces the overall win? I guess read it wrong
There’s overhead because the foreground group of rectangles needs to be duplicated in the file; the first time, it’s the foreground. The second time, it’s to define a cut-out mask.
I had an idea yesterday though, so I’m not giving up yet.
For every “polygon” (a grouping of rectangles), first remove the duplicate edges – those are the internal ones.
What’s left is a list of edges that may contain disjoint sublist of edges. For example, on the image shown here, each polygon’s edgelist is made up of the edges of the outer boundary and of the inner “hole” boundary. It’s possible (actually verified through randomization) that a polygon has more than one “holes”.
So, for each polygon, I’m now coding each edge in a way that’s direction independent, so that I don’t have to check coordinates of the edge’s vertices to determine connectivity. Then, I intend to utilize the exact same approach as in PolygonReducer to split the edgelist of a polygon into sublists.
Oh yeah, I forgot to say – v0.7.0 was too simplistic. Already taking the styling out of every single rect and putting it on a <g> with that styling already saves a lot of space.
I saw you released v0.8. It’s without the padding support, correct? Does the latest version in master branch support padding? I guess I could point mix directly to the repo then.
