Punctuation that failed to make its mark
bbc.com
bbc.com
On Windows/Linux, I use a 101 key. We all know the symbols. And those are the ones I use. There are cases in which I can use an interrobang or kanji-related emoticons, but I'm doing a google search and copying and pasting. But long story short, I don't use these other symbols because they're not easily available.
Sure, I could remap my keys, at least on Xorg. (No clue how to do that on Windows. ) But then, those symbols just aren't used. It's also a reason I don't bother with APL, because the language uses dozens of characters that aren't normally on a keyboard. I'll mess with ones I can type.
Now, phones... Oh my. A phone will auto-substitute picture emoticons from things like :D . Technically, these are a Unicode character set with device implementations. It means even though the pic is a 32x32, it's only usually 2 bytes (unicode is fucky, urgh, so many bugs). I'm more leery in using unicode because of character handling and badness, but things seem to be moving that general direction.
But for the wider issue of Unicode, these "failed symbols" are right in there. But good luck exploring and finding them, since characters can be from 1-6 bytes, or 2^48 space... Alas, back to searching google and copying and pasting.
The major exception for me is em-dashes, which I use all the time.
There are also a few punctuation marks on a standard keyboard that don't get used very much outside of programming and other specialized contexts. {}\|
Another interesting thing related to punctuation is that the use of some punctation is really overloaded. Quotation marks in particular can mean literally quoting someone, a scare quote, an indication that something is a term of art, titles of certain types of works, and probably some other variants.
Nobody I know has ever used ¤ in any context at all, it seems like such an odd addition. I've used it sometimes as a footnote marker, since it's highly unlikely to clash with formatting, unlike an asterisk.
The interrobang and a few other "novel" punctuation marks are there, but many of the examples from the article haven't made it that far, AFAIK. (And probably never will.)
> characters can be from 1-6 bytes, or 2^48 space
It's a minor detail, but Unicode characters are limited to the range U+0000..U+10FFFF, so they fit in 21 bits and require no more than four bytes (in the UTF-8 encoding form) or two 16-bit code units (in UTF-16) in the usual string representations.
(No argument with your original statement regarding what we primarily use, anyhow!)
The private use planes U+F8000..U+FFFFF and U+100000..U+10FFFF can be used as the high and low surrogate ranges in a surrogate-pair encoding scheme similar to that of UTF-16. That would give a range of U+00000000..U+7FFFFFFF, which is in 2^31 space. If the Unicode Consortium removed their arbitrary upper limit of U+10FFFF for codepoints, the UTF-8 and UTF-32 schemes as presently defined would naturally fit into this space without needing to use any surrogation. Only UTF-16 would require any surrogation -- its present scheme and those private use planes for a 2nd tier -- but hopefully the use of UTF-16 would be well on its way out by then.
Case in point: Ü (works better with sans-serif fonts but doesn't it look happy?)
So does the posting of this have anything to do with the recent Interrobang episode on the 99% Invisible podcast‽
(99pi is an awesome podcast btw!).
After listening to this episode, I even added a binding to the "C-x 8" map in Emacs[0]. This key map is mainly used for inserting various Unicode characters. So now in my Emacs, "C-x 8 ?" inserts ‽.
[0]: https://github.com/kaushalmodi/.emacs.d/commit/a70dd6b7c39f0...
Expressions of type give us new technology and increased leverage: We can further our inquiries because we can communicate those inquiries more objectively (i.e. more easily cross the subjectivity barrier). This objectified information is now information-technology-tooling. Though subtle, the use of these tools can eventually lead to new learning experiences and highly refined and promising new fields of work.
One of my current areas of interest is not so much punctuation, but what I call type-marks. These are unique markers that communicate the type of information that follows, or what is meant to be done with it. I find it's best if these symbols already exist in unicode tables. An example from bullet journaling is the hollow, upward-pointing triangle, which represents a meeting or event. I use other type-marks to indicate things like potential new models or leverage points in new models that may lead to useful new technologies. I use U+2295 or &oplus for that one in particular.
Anyway thanks to OP for posting the article--I love stuff like this.
Oh, how far you have fallen, tilde.
It's a tremendously handy symbol for this purpose, as it otherwise requires a lot more thought or typing to get across a similar meaning (eg. even one or two 'approximately's or 'roughly's will rapidly reduce readability).
Denoting sarcasm would be a retrograde step -- part of the thrill & delight of being sarcastic is that the target is oblivious to it. One worry would be that accidentally inserting a single character (which already has a well understood meaning for the literate amongst us) becomes quite a big risk if it changes the entire tone of the preceding sentence / paragraph / thought. Plus of course there's the risk of rapidly escalating double-bluffs. Would ~~ be unsarcastic, or doubleplussarcastic?
I guess I could check Wikipedia, but I almost don't want to know. Like, finding out would take some of the mystery out of the world‽
For those unfamiliar with how accents work on a typewriter: There'd be a couple special accent marks such as ~ and ` and whatnot that'd put down their accent but not advance the carriage. You could then hit a letter to get e.g. à or ē. It's a pretty clever system to prevent having to have a key for every accent.
In English, it basically means approximately especially in the context of numbers--a meaning that carries over into certain technical uses as well.
I can't tell if you're being sarcastic.
Anyway, it has a legitimate meaning already, so this usage may confuse your reader(s). It's probably faster to type heeey anyway. ; )
If keyboards would send characters instead of scancodes you would lose the ability to switch keyboard layouts in software (or it would be an ugly hack, which it was before we started to use scancodes). Many people use their computers with multiple languages and find switching keyboard layouts on-the-fly very useful.
I personally think we should have both systems: The current "position dependent" system we have now, and a system for sending Unicode.
Of course it means more engineering effort. That's why we're here for.
I contend that almost no one does that (obviously outside the 2 people on this page who are so insistent on the feature), so the engineering effort is not worthwhile. And it must be weighed against all the times everyone has to select the right keyboard layout manually when installing operating systems, or they type a particular key but what shows up on the screen is different from the keycap and they have no idea how to fix it.
It's true, using a keyboard layout different from the one printed on the keyboard is unheard of in much parts of the world, but on others it's almost a necessity. Continuously installing operating systems and manually configuring keyboard layouts is uncommon, too, and it's mostly solved by automatic layout recognition, aka "write the words you see".
US layout lacks the characters necessary to write in the local language. European layouts often make it awkward to access punctuation common in English (e.g. you need Alt-Gr combos to access). Many people need to use both English and their local language (and perhaps a third European language!) in day-to-day business, hence the need for switching between layouts.
I regularly use different keyboard layouts and it has never been a problem. It does not suppose any lost of time or engineering effort. When you have to usually communicate in different languages (which is common for the most part of the world), it is very useful.
I have also built several keyboards, and I cannot imagine the pain it would be having to define a key for every Unicode character.
I personally know of how much work went into getting QEMU to support keyboard layouts. It has to convert characters back to scancodes so the guest OS can convert the same scancodes back to characters. It was a nightmare to get it right. Such a lot of effort for such a silly feature.
> I have also built several keyboards, and I cannot imagine the pain it would be having to define a key for every Unicode character.
What? There's no reason you would define a key for every Unicode character.
And what I don't understand, is how it would work in your ideal world. Let's assume we do not allow users to change keyboard layouts. How do I input characters for different languages? Am I supposed to have a different keyboard for every language or do I need a keyboard than can change layouts? Would those keyboards be included in laptops? How is this simpler than keyboard layouts in the OS?
I do not say you would have to define a key for every Unicode character, but if the OS is expecting Unicode, either you have to define some way to send it from the keyboard, or you implement in the OS some mapping, but at that point you would just be using Unicode characters as scancodes and we would be back at square one.
What, like a QMK-style C macro for every Unicode code point? that's not the only way to design the API.
Maybe back in the days of typewriters you could overlay ? and ! but I don't think it looks good today‽
I think that other fonts should follow that example too.
Until then, as I anyways use subsetted fonts on my blog, I can easily specify the font to use for the ‽ glyph.
Plus, how often do I really need to chain a question and exclamation mark together?
https://www.web2generators.com/text-related-tools/write-upsi...
Edit: it looked right in the submission box but not in the comment. Shrug.