Meziantou.Framework

Stable colors

edit

The color pair of an avatar is hash(name) % Palette.Count: the same name always gets the same colors, for a given palette and a given version of the package.

// The same name always gives the same avatar; surrounding whitespace is ignored
Assert.Equal(AvatarGenerator.CreateSvg("Ada Lovelace"), AvatarGenerator.CreateSvg("  Ada Lovelace "));

// The color depends on the palette: adding or removing an entry changes the color of most names
var options = new AvatarOptions();
options.Palette.RemoveAt(options.Palette.Count - 1);
Assert.NotEqual(AvatarGenerator.CreateSvg("Ada Lovelace"), AvatarGenerator.CreateSvg("Ada Lovelace", options));

What changes the color

  • The palette. The number of pairs and their order are part of the mapping: adding or removing a single pair changes the color of nearly every name, not only of the names that used the changed pair.
  • The case of the name. The name is trimmed and normalized to Unicode Normalization Form C before it is hashed, so surrounding whitespace does not matter, but the case does: "john doe" and "John Doe" can get different colors.
  • The version of the package, if a future version changes the hash or the default palette.

Bigram, AccessibleLabel, Shape and Size do not change the color.

Invariant globalization mode

The normalization to Form C needs ICU. When the application runs with InvariantGlobalization, it does nothing: a name that is not already in Form C, such as a name whose accents are separate combining characters, then gets another color than in a process with ICU. If avatars are generated by processes of both kinds and must agree, normalize the names yourself before calling CreateSvg.

Caching and storing avatars

Because the output is deterministic, you can cache avatars, or store the generated files. When you change the palette or update the package, regenerate them, or users will see different colors in different places. Keying a cache on the name and a version number of your palette makes this explicit.