I am developing a bespoke type family for a client that requires a set of fairly general pictograms to be included. There are toilets, elevator, stairs, parking, etc.
I didn't think much about it at first, assuming that such basic pictograms, extensively documented by ISO, would certainly be encoded in Unicode...
But it turns out some are not, even though they are probably amongst the most widely-used signage signs you could think of. 'First aid', for example, does not seem to have a corresponding Unicode value, neither does 'exit' (!!), 'parking', 'wheelchair accessible toilet', 'defibrillator', 'dogs prohibited', 'waiting area', 'stairs', etc...
Because I cannot quite believe that this is the case, I am asking for your expert advice: am I right, are they really missing from Unicode? Or did I miss a whole set of code charts? And if so, is there a background story that even comes close to explaining such omissions in view that any shit, literally, has a Unicode point? Is it because ISO claims some kind of IP on these signs? It's just baffling to me.
Thanks in advance!
Titus
1
Comments
To make the point, computer keyboards have characters printed on the keys—the characters that get generated when keys are pressed, and those characters are encoded in Unicode. But keyboards might have other icons printed on the keys for special actions, and those icons won't necessarily be encoded in Unicode: they would only be candidates for encoding in Unicode if they are used in text.
And by implication you seem to suggest that in the below images from a random google search some are worthy of being called text and thus encoded, and the others not? How does the use of these signs differ? As far as I can see both – emoji and pictograms – work as iconographic depictions alongside alphabetic text.
thank you for your kind suggestion. I have consulted the Unicode website and code charts, which formed the basis of my understanding and brought me here. I guess this confirms what I had already established, that's a start.
The Unicode Standard does not instrinsically absorb symbols in existing ISO standards, although at its inception, it did that so with certain national standards. At the present, every new character enters the standard through the help of an advocate; that is, someone who proposes its addition. For instance, if you don't find certain AIGA travel symbols, you could gather that information, prepare a proposal, and submit it for consideration. The submission procedure is explained on the Unicode site.
ISO symbols are in the public domain but are not included in Unicode. Some of them have Unicode equivalents here and there but you won't find a complete ISO set in Unicode.
Although its focus on text, Unicode is far from pure-text due to backward compatibility. Many symbols were already present in previous text standards. Many other were added later (following the procedure Kamal described). And there was the landslide of emojis, making Unicode less text-focused. Actually, Unicode is a bit like Frankenstein's creature, but still an amazing tool.
As a type designer, I do not limit the symbols to Unicode. If I find that something may be really useful to the user, I include it. Many times, Unicode ends also including these symbols in future versions. Version 13.0 brought 278 new symbols and in the version 14.0 are planned ~40 more.
Emoji is to communication what coprophagy is to nutrition.
There are a single foot, and footprints (above) emojis in Unicode, but a <Left Footprint> and <Right Footprint> would have been more suitable for making “Stand Here” COVID floor graphics.
@Thomas Phinney
I did see this Unicode value and wondered about the intended implementation in a font. It's not particularly user friendly for the general office worker, but certainly better than nothing.
A common approach seems to be assigning PUA values to unencoded pictograms, but that is so conceptually unsound that I am reluctant to go down this road. As @Igor Freiberger notes, the Standard does evolve, and re-assigning a 'proper' value to a glyph hitherto encoded with a PUA value would wreck existing documents.
Obviously I also 'do not limit the symbols to Unicode', but unfortunately there are still apps that struggle with unencoded glyphs and OT support remains inconsistent and incomplete throughout, making the accessibility of glyphs and thus the usability of the fonts a real concern.
For now, I follow John Hudson's advice and do not add. But I may change this because in FontLab 7 you can set more than one code to a given glyph. So, it is easy and secure to update a font with future additions to Unicode.
I remember that a few years back, some makers of various pictographic signs using that symbol were sued by a company which claimed ownership of the red circle with slash over an icon, despite its origin in European traffic signs. Unfortunately, I do not remember the details.
Fonts seem like convenient delivery mechanisms for little pictures, until you want to use them for a little picture that has no text encoding. We need a better delivery mechanism for little pictures, and cramming emoji into a text encoding didn’t make that need go away.
If the font fails, you'll get something readable instead of a .notdef. Consider that other fonts might have their own PUA characters. In the case of font substitution it might not display a .notdef...maybe something that changes the meaning entirely. If you use shortcodes you have the option of leaving those custom characters unencoded.
I did this for the Canada1500 typeface and used several languages for each shortcode. It's in the public domain if you want to check the source. If you're nervous about people inadvertanly triggering shortcodes with brackets, use a typographically unimportant keyboard character like backslash or asciitilde. I used \shortcode\