A Unicode Woe Solved

Something that had always bugged me about Era Legis was the way the astrological symbols were rendered. Rather than being drawn as plain black linework that is typical for most characters in a typeface, they would get drawn as these tacky purple emoji bubbles. For example, here this symbol for Sagittarius: ♐. The specifics would vary a bit from platform to platform. On iOS and Mac, the system fonts would render the purple bubble form. On some Android devices or when using Google web fonts it would show as a flatter, Material-looking emoji. Somewhat more attactive, but still an emoji.

The way Era Legis output gets used, having portions of it emojified really screws with the aesthetics of the rendering. It shouldn’t look like “We will celebrate our next Mass at ☉ in 6° ♒, ☽ in 16° ♎.” It’s unnecessarily distracting to the reader’s flow, and just plain ugly. The inconsistency of it was also irritating, that it changed so dramatically from platform to platform.

I figured there was little I could do about it, though. I assumed it was a fixed property of the typeface in which the page’s text was rendered, and the Era Legis service doesn’t control the fonts selected for the page in which it is embedded.

But it’s not true! I know Unicode is enormously sophisticated and is designed to handle all the major edge cases of human fixed-symbol communication, a truly vast endeavor. It handles left-to-right and right-to-left scripts and ways to combine them. It handles base characters combined with one or more diacritic marks. Those combined characters can sometimes be composed into a single different code point, and then decomposed into a sequence of code points. It’s all over the place trying to apply a coherent system over the multiplicity of human written language. I would say it’s not as complicated as reliably discerning dates throughout history, but it’s known to be pretty daunting for software developers digging into it for the first time.

Helping support multi-ligual library systems and their catalogues, I’ve had to program for Unicode fluency a lot and have gotten comfortable working with it. But there’s always something new. What I didn’t know until today is that it also has a set of combining characters that influence variations of the same code point, called “Variation Selectors.” These control points tell the renderer to check the font for alternative instances of the immediately preceeding character. Two of these sixteen codes direct the use of either an emoji (VS16) or non-emoji (VS15) variant.

If no VS character succeeds a given character, the rendering platform gets to choose which one it will opt for. (There may even be a default specified in the font package; I’ve not looked deeply into that). Apple, Google, Microsoft, and others seem to have at some point settled on defaulting the astrology code points to VS16, so they get displayed as cutesy emoji bubbles. And it turns out that if you append a VS15 control character onto each astro symbol, you can now announce “We will celebrate our next Mass at ☉︎ in 6° ♒︎, ☽︎ in 16° ♎︎.” No emoji!

With this new finding I’ve updated the underlying library that Era Legis uses (the Perl module DateTime::Format::EraLegis) to sprinkle VS15s after all the astro symbols. Anyone who uses the REST API or the date picker tool will see this changes immediately. Oh, to scratch an old itch!