Is there consensus or best practice on how to best access special characters (like arrows or numbers in circles) in a font?
I couldn’t find anything so I implemented something my own way with contextual alternates:
Numbers in circles can be created with Contextual Alternates enabled and typing a combination of
w or
b (white or black)
# (number sign)
and a digit (0-9)
Arrows can be created with Contextual Alternates enabled and typing a combination of
> (greater than)
with
r,
l,
u,
d (right, left, up, down)
Everything works fine this way but maybe there are drawbacks that I didn’t foresee?
Cheers, Ebern.
Comments
Basically, the argument against any of these is that you have no idea how your fonts are going to get used and adding these kinds of seemingly smart contextual alternates is that it is very, very annoying for your fonts’ users if they suddenly can’t type what they actually wanted to type, and instead get an arrow.
Most of your users will never know about / remember these features. The others can find them in their app’s OpenType features palette. So you’re really building this for expert users who are also using an app without expert features.
Long story short: do this at your own risk. It’s just not worth it from my perspective.
In our user manual, in the section for automatic OpenType feature generation, we recommend using Alternate Annotation Forms (thus the nalt feature) for digits placed in circles and squares.
When you type keys on a keyboard, you are inputting character codes, which are what are stored as text in the computer. If you decide for your font to display the character sequence '>ru' as the ↗ glyph, that will look lovely in your font, but that text is going to display '>ru' in everyone else's font. So you have not actually make it possible to type ↗, you've just hidden the fact that what was actually typed was '>ru'.
Input processing, character processing, and glyph processing are separate stages in text processing and display. It is important to understand the correct stage at which to address different kinds of issues.
Give them their correct Unicode values, and make sure they are nicely grouped when they appear in a Glyphs palette (position while in Index mode).
The arrows are in the Arrows code sheet.
\microgravity\ \phobos\ \laser\
Backslash was chosen as it's more of a programming character than a typographic character and it's available on most keyboards. Of course we don't know how backslash will be used in the future but for that project I think it was the best choice. Multiple characters were considered like {{shortcode}} or [[[shortcode]]] but we were concerned about adding more characters unnecessarily, causing overruns. You can read the PDF on this page to see a list of shortcodes. Most of the symbols have Unicode locations but a lot of them are emoji so possibly not reliable as a fallback anyway. The shortcodes were also meant to serve as an easier way for technicians to input hard-to-find characters. I wouldn't recommend shortcodes for general use but I think they can be useful for specialized purposes. I recommend using shortcodes which are human readable so the meaning can be understood if the shortcode fails.
And those few users who know the groupings of the characters they are looking for will look for them under the correct group. Plus, if they are looking at those characters across different fonts, having them shift around between groups when they shift fonts would be seriously problematic!
On the one hand: Suppose you're an app developer and need to put some icon—depicting, say, a foobie (whatever)—into the app user interface. You hope your app will enjoy a long lifespan. But throughout that time, the icon will only ever be viewed, and all that matters is that it appear as intended. You can implement it as a character in a text element displayed using some font, and nobody will ever be selecting, editing, searching, copying or re-using that text. So, it really wouldn't matter a whole lot if you created a font in which you re-purposed the "a" character for your foobie icon: the only thing impacted is you, the app developer, and whoever else maintains the app.
But on the other hand: Suppose you're creating a font that will get used by authors creating a variety of content—this seems more like your scenario. That content will have some lifespan, possibly very long, over which people will read, may edit, may search, may copy and re-use, etc. portions of the text. And along the way, the text may well get re-formatted with some other font. In this situation, the semantics of each character entity in the content matters a lot! In order for the text to be robust, to continue working as expected over that lifespan, you really want the encoded representation for each character to follow an enduring convention—the Unicode encoding standard. If you build the font so that, say, the encoded character U+0061 LATIN SMALL LETTER A displays as an arrow or anything other than "a", then people interacting with the content will encounter lots of problems. E.g., they reformat text and it suddenly presents a different meaning; they search for certain terms and encounter lots of false positives, etc.
So, this is why people are responding saying that access to symbols should be handled as a keyboard / text input issue, not as a font rendering issue.
Can this be handled through OpenType? OpenType is a font format for display of Unicode text, and the only special capability OT Layout can offer is to provide a way to support different design variants of a character—e.g., different styles of head on an arrow.
Most OSes have mechanisms for designing custom keyboard layouts. Also, apps for authoring text often provide means for users to enter any Unicode character that's supported in a font; for example, in Microsoft Word, you can enter any character using the Insert | Symbol dialog.
Apps like Word also have auto-replace features that will automatically replace a sequence of characters with a "special" character; e.g., in Word, if you type (c), it will automatically replace that with ©. But a key thing to note is that this feature can be customized by the user. For instance, I have Word automatically replace --- with an em dash for easy entry. So, that's another means that users can use to enter arrows or other symbols they frequently use.
A font developer should certainly think about documenting for customers what Unicode characters are supported in a font. In some situations, it may also be necessary to help customers explore options for easier text input of "special" characters. But in general, it's not a good idea to put into fonts gimmicks that will cause certain Unicode character sequences to display as something entirely different.
https://www.ergonis.com/products/popcharx/
Perhaps there's something comparable for Windows?
Character input could be made possible generally in a way that puts present-day restrictions of the keyboard where it belongs: into the museum. Completely.
NO excuses, please.