[venice_benice]

> I cut-&-pasted Buttrick's quote from his website without alteration directly into HN's edit box and the uppercase text was immediately converted to lowercase. I'd not planned this but I could hardly have had a better illustration of the problem than this excellent example.

This has nothing to do with typewriters; the text is actually lower case, it's just being used with the small-caps variant of the typeface (I haven't directly verified it, but I am familiar with Butterick's site, and he uses them frequently). It's not really a Unicode problem either; small caps are not encoded in Unicode (well there's something similar for use in phonetic representation but it doesn't have the X for example).

I agree with the other points; keyboards (with the possible exception of handmade ones) have all standardized to a quite limited range of input keys, all traceable back to typewriters, leading to most people I know irl replacing curly quotes with straight quotes, all the dashes with just hyphens, and so on.

In his book, Bringhurst brings up this limitation of modern keyboards, and muses over the possibility of a fully programmable keyboard (in hardware and key displays, not just layers or software hacks like OS/environment-dependent modifier keys). It would be nice to press a button or two and have any keyboard layout I want, multiple scripts, and so on.

[hilbert42]

I forgot to mention the limitations of modern keyboards. I've always wanted a second row of programmable function keys that could be edited quickly as part of an OSD (perhaps even a small display on the KB itself for said purpose). I reckoned this would be minimally disruptive to the current ecosystem and yet offer most of what people need.

I haven't yet read Butterick's book. I was tempted to buy it the first time I visited his site but didn't. From what you say, it's time I did so.

[hilbert42]

"This has nothing to do with typewriters; the text is actually lower case, it's just being used with the small-caps variant of the typeface"

I'm not denying that for a moment. Perhaps I should have been more specific in what I said but I thought my meaning was obvious.

What I meant is that there is no agreed method of converting or moving text from one source (editors, WPs, etc.) to another. This means that unless great care is taken then entropy will increase with a transfer, simply information is lost in the process (as in this instance/example), and there are any number of similar cases.

This is a huge ongoing problem that remains to be addressed. Converting text from one environment to another usually increases entropy as information is lost, it's an intrinsic problem by design (or more aptly the lack thereof). Just changing the typeface alone will do that as likey the author of the text relied on some characteristic of the typeface to convey meaning.

A simplistic example is where say a superscript is converted into a normal character during conversion, for example, 2(^2) is 4 and not 22 as is often the case after conversion (or it's lost altogether). (Yes, in this instance I can fix the problem without great difficulty as there is a Unicode superscript 2 but there are other cases that would be much more difficult). [Edit: OK, with some effort I've done it, 2², U+00B2 Superscript Two.]

Mathematical equations are notoriously difficult, have you noticed how often they are converted to GIF images or that they require JavaScript to display them? Turn off JS on a typical webpage with math in it and it'll look like gibberish—and this is despite the existence of MathML which would largely solve the problem. Why isn't MathML used? Because people can't be damn-well bothered to take the minusculely short time to learn it. Another paltry excuse it that not all browsers render MathML the same way (now, whose fault is that?).

Nothing is much worse than OCR, with OCR accurate conversions are almost impossible. With the current state of OCR development it's inevitable that we get a considerable loss of information through 'read' errors (comprehension errors through lack of accurate recognition), typeface and text size errors and page layout errors—it's a diabolical mess, a first-class shambles. Want some quintessential examples? Just go to the Internet Archive and look at PDFs with embedded text, almost every file is diabolically bad, hardly a paragraph goes by without errors. On performance, and after some 40 or so years of development, OCR is still not fit for purpose without major human intervention (hopefully AI will rectify that).

And I put much of the reason for this situation down to the indifference of technical people, mainly programmers, who are only interested in transliterating text character by character, in effect they've SFA interest in other information that texts convey, essentially they've no concern that this other information is lost. If it had been just left up to most of them we'd still be using Courier New or System typeface. Want evidence? Then just look at how the internet RFC specifications are written and presented, by today's standards they're archaic (it's almost as if they don't want anyone other than themselves—the self-styled cognoscenti—to read them).

Thus, it's little wonder that even the simplest case of moving texts between editors/WPs still hasn't been resolved after some 70 years or so of computing development.

Let's go to a slightly more complex matter but still a practical example: I used to use typewriters and it was dead easy to enter text between lines (for corrections, notes, etc. including handwritten comments) by manually turning the platen (platten if you prefer) by half a line or to any degree desired. Come OCR (or any similar schema), and any such conversation becomes one hell of a mess. For starters, can you name any editors or wordprocessors that allow information to be entered into a fraction of a CR/LF (carriage return/line feed)? If you know of any outside of say very specialist DTP stuff then let me know.

The fact is there's precious little being done to rectify the problem specifically for reasons I've mentioned.