🔣🖼️ Ethan's Text-Color ID

Pretty much any letter, number, symbol, emoji, weird dingbat, or other thing you can type or display on a screen, is part of a giant system called Unicode. Every character in Unicode gets its own unique number, called a code point. The code point for A is 65. Some emoji are way, way up past 128,000.

This tool takes that Unicode code point number and runs it through a 32-bit avalanche mixing function, from the same general family of hashing tricks used in things like Murmur3. "Avalanche" basically means that even a tiny change to the input, like flipping one single bit, should scramble the output enough that roughly half of its bits change too. That's important because some simpler methods can look random-ish at first while still producing patterns underneath.

The actual mixing is a little ugly, in a good way. The number gets XORed with a right-shifted copy of itself, multiplied by a large odd constant, then put through a couple more rounds using different shifts and constants. Each pass smears the influence of the original bits farther across the whole 32-bit number. And this uses true 32-bit integer multiplication through JavaScript's Math.imul. Regular old * in JavaScript uses floating-point numbers, and once the numbers get big enough, you can lose some of the exact low-bit information we're trying to preserve. Math.imul avoids that.

We need three numbers for a color: a red value, a green value, and a blue value. Rather than mix the code point once and chop that one result into pieces, the tool mixes it three separate times. Before each pass, it XORs the code point with a different fixed "salt," so the red, green, and blue channels each get their own independent scramble of the same original character. Then it takes the top 8 bits from each 32-bit result and uses those three bytes as the final RGB values.

RGB values just describe how much red, green, and blue a color contains, with each number running from 0 to 255. So RGB(255, 0, 0) is pure red: imagine the "red lever" all the way up, while the "green and blue levers" are all the way down. Similarly, RGB(255, 0, 255) gives you a bright purple/magenta, because red and blue are both maxed out while green is zero.

The reason for going through all this trouble is that nearby Unicode characters shouldn't automatically end up with nearby colors. "abcd" are consecutive code points, but there's no reason their color blocks should look like four tiny variations of the same hue. At the same time, characters from totally different writing systems shouldn't collapse onto the exact same colors just because some half-arsed formula only looked at the last byte of their code point. Unicode is huge. If you only use a tiny piece of each number, you're throwing away most of the information before you even start. Here, the whole code point gets brought in for the final color, and the full RGB color space is available.

Once the first symbol has its color, the tool does the same thing for the second, then the third, then every character after that until it reaches the end of the text. Those colors get arranged into the most convenient square-ish block possible, and if there are any empty spaces left over at the end, they're filled with alternating black and white tiles.

In theory you could make this reverse-translatable too. But that's another day. For now, enjoy your unique text-color ID block!