Nostalgia for the Selectric

John Savard

I think I have uncovered a cause for a bout of nostalgia I have been feeling for the Selectric typewriter.

In Windows 3.1, if I wished to include an APL program, or chess diagram characters, in a document, I would install a font with APL characters, or chess diagram characters, and then switch to that font. Normally, the special characters would just be assigned to the basic ASCII characters that I could type on my keyboard.

Now that we have Unicode support, I can't just switch to another font, I also need to select a special keyboard. And while Windows has keyboards for many different languages that you can install, it's not so simple with specialized keyboards. There's a special utility to install, which requires a particular version of the .NET framework.

With a Selectric typewriter, of course, switching to another set of characters also involved only one step, popping in a different element.

Going back to non-Unicode fonts in itself would be a step backwards. Having the text one types have... semantics... in addition to the correct appearance is a good thing, as it allows for later processing.

So my question is: could someone present examples of systems where fonts and keyboards are integrated in a constructive way, so that the advantage of having Unicode equivalents for almost every character is taken advantage of, and yet this does not burden the user with excessive complexity?

Thomas Phinney

If you want cross-platform, and relatively easy to use, are you familiar with Keyman?
https://keyman.com/

Helmut Wollmersdorfer

Thomas Phinney said:

If you want cross-platform, and relatively easy to use, are you familiar with Keyman?
https://keyman.com/

It's by the SIL community and I will try out keyman the next time I need it.

Some years ago I used Ukelele to compile my own keyboard for German historic texts (needs long-s, rotunda and some special combining characters).

Thomas Phinney

Ukelele is reportedly excellent; I only left it out because it is Mac-only. (Which I think means that not only does it only run on Macs, but only produces keyboards for Macs.)

John Savard

Thomas Phinney said:

If you want cross-platform, and relatively easy to use, are you familiar with Keyman?
https://keyman.com/

Thank you for calling it to my attention.

However, while it may be easier to use than MSKLC, after visiting the site, it's not clear to me exactly what it does. It seems to me that it is focused on broadening language support.

So instead of just defining a keyboard layout with it, I can define an input method (at least with Keyman Developer).

And I can use it to automatically change things like date and time conventions when I change to the keyboard for another language.

Although it sounds like a great and wonderful open-source program, it appears to be unrelated to the specific issue I'm citing; making it easier to use special-purpose fonts not associated with a language by somehow linking them to an appropriate keyboard layout.

So what I felt I was likely to be looking for was an example of an operating system, or of a typesetting system (including desktop publishing software) that facilitated working with a wide character repertoire, perhaps by presenting a more traditional paradigm to the user.

Maybe Keyman would help, although with the limited information about it on the site, it seems as though it is instead tangential to that issue.

John Savard

But perhaps I could use it to design, for example, an intelligent keyboard that could easily switch between several layouts.

André G. Isaak

Just to clarify, are you suggesting something along the lines of how script systems worked in Mac OS 6 though 9? Where switching to a font in a different script automatically switched keyboard layouts? If so, I suspect that would be difficult given that fonts are no longer restricted to contain a single script (or symbol set).

John Savard

André G. Isaak said:

Just to clarify, are you suggesting something along the lines of how script systems worked in Mac OS 6 though 9? Where switching to a font in a different script automatically switched keyboard layouts? If so, I suspect that would be difficult given that fonts are no longer restricted to contain a single script (or symbol set).

Something like that, yes. But modified to work in our world of larger fonts and especially Unicode. But not necessarily restricted to that. For example, instead, switching to a different keyboard layout might lead to fonts that include the characters in that layout being suggested.

Or, a system might be present where pairs of one font with one keyboard layout would be defined, and instead of seeing a menu of keyboard layouts or a menu of fonts, normally what one sees is a menu of these pairs. That way, one could pair a font with more than one keyboard layout.

John Savard

Further thought leads me to the conclusion that, while such a system as I've outlined would work fairly well for small fonts, which support one or two keyboard layouts, clearly one wouldn't want to install a font for something like Plex and Roboto, and have one's menu piled with entries for that typeface in combination with every possible keyboard.

So, for a font, one would have to have a mechanism by which some of the available keyboard layouts associated with that font are "starred" or favorited.

Another point to re-emphasize and clarify is that I'm not primarily making this suggestion for switching languages.

In the case of switching between the keyboards for two different languages, the font + keyboard layout model works well enough. Typically, a user will switch between two languages, and most of the installed fonts will support both of them. So associating fonts with keyboards doesn't really gain anything.

But for specialized fonts, for things like chess diagram symbols, or the APL computer language, and so on and so forth, that's where pulling up the font and the keyboard at the same time will help matters. Here, changing to one of these fonts may occur frequently in the middle of text, and the appropriate keyboard won't be built into Windows either (so it's not just choosing the keyboard, but installing it, that needs to be simplified; the idea also includes distributing fonts together with keyboard layouts and the list of associations).

Helmut Wollmersdorfer

AFAIR (used it last ~1986) the IBM APL keyboard had the special characters on the planes <ALT> and <ALT>+<SHIFT>.

Additional keys you can use to get to additional planes are <SHIFT-LOCK> and <CTRL>. That's more you need.

Thomas Phinney

I should have been more specific: Keyman is the thing that lets you use the keyboards. Keyman Developer is the tool you want.

https://keyman.com/developer/

John Savard

Thomas Phinney said:

I should have been more specific: Keyman is the thing that lets you use the keyboards. Keyman Developer is the tool you want.

That's all right; I realized that after visiting the site. Actually, though, my concern was that even Keyman Developer might not really do what I was thinking of.

It was the post by André Isaak that inspired me so as to clarify my thoughts further, to see that there actually was a way to get what I did want.

At first, I didn't really know what I wanted. I knew I wanted something more than even what Keyman Developer would provide - a better way to design new keyboard layouts.

What I wanted was the following:

I'm preparing a text document; it's going to have portions in it that consist of special characters.

I want to be able to do this very simply; instead of doing two things, selecting a font to use, and selecting a keyboard layout to use, I want to do just one thing.

So I want to fix Windows or Linux or whatever operating system so that users don't have to even think of keyboard layouts unless they want to, even when they're using different keyboard layouts.

So if I've got a font of chess diagram characters, and it's a Unicode font, so I need to generate special characters to use it for its intended purpose, I want the keyboard layout and the font to change together.

How is that even possible?

What I came up with was this:

In your typical word processing application, next to and preceding the drop-down for fonts, there would be one for font/keyboard layout pairs.

I noted that fonts usable with many languages, like Plex or Roboto, wouldn't fit well into this paradigm; so there would have to be a way to "favorite" some of the keyboard layouts associated with any given font, and have only the favorites appear in the drop-down.

If you select text, and change the font, that works normally; perhaps, if you select text, and change the font-keyboard pair, the characters would be translated appropriately...if that can be made to work. (It's all right in the absence of composed characters and input methods, of course. If both keyboards involved have such complications, though, it would be impossible, since one couldn't work backwards from characters to keystrokes.)

And, as a further clarification: I'm qute aware this is a really wild idea, out-there and crazy. The simplicity of the age where all fonts were "ASCII fonts", or where you put an element in a typewriter to type special symbols, which mapped those symbols to the existing keys... is not a good fit to the Unicode era, where different characters also have different internal codes, so that documents with special characters or multiple languages can be fully processed by the computer, not just printed and read by humans.

Another detail on how it might have to work in practice:

At the time one installs a font, one would manage its bindings to keyboard layouts. How that is done depends on the font.

If it's a text font for a single language, and you have a keyboard for that language installed on your computer, it's obvious what to do, and you may not even be prompted for a selection.

If it handles multiple languages, you will be prompted to select which of the possible keyboard layouts you will usually want to use with the font.

If it's a special character font, for which no keyboard layout is included with Windows to install, a keyboard layout would normally come with the font, and that would be installed also and bound to the font.

I hope what I'm thinking of has now been made clear.

John Savard

And another point: currently, in Windows, the font you are typing in is local to the application, while the keyboard layout in use is global. That's why the font is selected by a drop-down in the application, and the keyboard layout is selected at the lower right of your screen, in the taskbar.

So another change this involves is having a local keyboard layout state within applications.

John Savard

Further thought leads me to ask: perhaps creating a new kind of object, a linked keyboard and font pair, is going too far, trying to shoehorn fonts in the Unicode world into an exact match to ASCII fonts or Selectric typeballs.

Instead, how can the issue be addressed with the least change?

Instead of having a menu of keyboard/font pairs, simply have a menu of keyboard layouts. Select a keyboard layout. Then, the list that drops down for the font menu is re-ordered; when you go to select a font, those fonts that cover the character range associated with the selected keyboard layout are on the top, above a horizontal line, followed by all the other fonts.

That would be a much less radical change which would still make things a lot simpler for the user who wants to start typing "in Bengali" or "chess diagram characters" at a given point within a document.