Back before there was OpenType, and before Windows had Unicode support, if someone wanted to type text in Georgian or Greek or Armenian, they had to use a special font that printed the glyphs for the characters desired for the character codes within ASCII or at least ISO 8859-1.
Although that's a highly deprecated practice, it is awkward to change keyboards in Windows. Furthermore, I'm not aware of a chess diagram keyboard, for example.
It has occured to me, therefore, that some people might find it very useful to be able to type special characters by the following process:
Have 7-bit or 8-bit fonts which replace ordinary characters by characters in the more distant parts of Unicode, but which also associate with each character the value of the Unicode code for the character the image of which is being printed...
and provide in word processors, including simple editors with text styles (i.e. WordPad and the like) a "Paste as Unicode" function. (Of course, that pastes text in a default font, one would then have to change it to the Unicode font you want.)
Comments
Not really. The process is similar to that for other platforms. If you want to make it easier to provide a custom keyboard, e.g. for entering chess piece symbols, I recommend Keyman.
By 7-bit fonts, I think John Savard means fonts with 128 characters (ASCII), and by 8-bit fonts I guess he means 256 characters (ANSI fonts).
One way to do what you want: at the font level, encode the glyphs to multiple characters. That is easily done. However, it does not really tell anyone which are the primary characters, and which are a bogus convenience character mapping.
But the other problem is, what mapping of special characters to “ordinary characters” do you use? How do you share those mappings? This proposal involves re-inventing codepages all over again.
Keyboards are in fact the elegant solution to this. I am not convinced that switching a software keyboard is harder than the proposed system—I find it fairly easy. If it *is* harder, then the solution is to make it easier to switch software keyboards.
Don’t get me wrong. If I invent a font of wacky arbitrary symbols that don’t have legit encodings, aimed at a relatively lay audience, I will encode them to the same Unicode slots as ASCII without worrying too much about it. I have done this.
But if you want to make it easier to access chess symbols, darn, just make a chess keyboard! Way easier than anything else.
ornm
tag, then.I am struggling to understand what the real advantage is to this. Because we *do* have Unicode now. Plus, we can even encode a single glyph to multiple codepoints in existing formats. So you can get very close to this capability without anything new.
If this proposal is implemented in a way that requires new kinds of data in fonts, I just can’t imagine it getting the traction it would need, because the costs are high and the benefits are very small.
How would it know which values? It's all Unicode.
You could write a text edit macro that converts a text input using characters from e.g. the US English keyboard to Unicode chess symbol characters, but I don't see that having to run such a macro every time you want to create a document including chess symbols is any easier than switching to a custom keyboard.
Heck, if you want people to be able to avoid switching keyboards on their system, make a web virtual keyboard. It's not like people will be composing lengthy texts composed of chess symbols such that they need to be able to touch-type them. A webpage with a simple text field and clickable chess symbols to input would work fine, and could be used in concert with regular typing from the keyboard for non-chess characters.
ornm
tag, then.Maybe I've been dealing with multiple scripts and languages, and specialist publishing, for too long, but switching keyboards really doesn't seem to me a difficulty. Millions of people around the world do it several times each day.