Accent Short Cuts

The first lower case national coded character sets were published for English (ANSI X3.4) and German (DIN 60 003) in 1963.

In 1968.

Alas for the sin of speed typing.

/hh

This would work how with touch typing?

The issue is how the industrial design is parametrised. Within one parametrisation there may be many, many implementations.

If you parametrise for a static input method, you are at sea since the coded character set is for the writing systems of world scripts (which has not dawned on the US and the UK -:)).

If you parametrise for a dynamic input method, then you have a viable parametrisation, but you also need a viable implementation in order to sell your product.

I would not say that Dell has a viable implementation even of monolingual input on its tablet, since the input method takes space on the output area.

I would not say that Nokia has a viable implementation even of monolingual input on its hard key phones - I HATE, HATE, HATE these contraptions.

I have to cycle through key presses to get from what the UK and the US gets as the Basic Latin to what I need for Danish, or Swedish, or German. This is IDIOTIC.

I saw UK and US pundits in the IT press poking fun at the trend in industrial design for phones towards input methods in touch surfaces.

I am not sure what they use for brains, but I am sure they are of the opinion that interactivity for input methods and character identification should be English and only English.

Ye gads, if a panel of industrial designers were called to evaluate interactivity for what is sold into the IT markets in the EU, they would have a collective heart attack.

/hh

I would not say that Nokia has a viable implementation even of monolingual input on its hard key phones - I HATE, HATE, HATE these contraptions.

Hmm ... a politer way of putting the point in public, perhaps.

I find that industrial design of input methods to be utterly useless if the parameter is that Basic Latin is the top level of the implementation and secondary levels of the implementation harbour Latin diacritic letters such as ä, Ä and Latin ligated letters such as æ, Æ.

The issue can be construed as one of cultural identity, but this is irrelevant to computerised communication, computerised composition and computerised cataloging in application-independent page description models and page markup models.

If information society is to work, then it must work without hardware and software that compels the everyday enduser either to transcribe to try to preserve the sound of another writing system or to transcribe to try to preserve the spelling of another writing system.

The Library of Congress and the British Library have the longest experience with computerised cataloguing based on a combination of transcription and transliteration, and these Libraries have depended on specialised cataloguers.

In the past the author prepared copy, a specialised artisan composed the copy according to correct orthographic and typographic rules, and a specialised archivist catalogued the copy in a subject index. Full phrase cataloguing was neither conceived nor was it possible at all.

In the present, the author configures character information and imageable composition for full phrase cataloguing. Neither the hardware nor the software available to the author is anywhere approaching acceptability for the challenges of this assignment.

/hh

it is critical that input methods migrate from dedicated monolingual (with a mess of modifiers for multilingual input) to dedicated multilingual.

Nobody needs to use a "mess of modifiers" if they don't want to. Switching from US to Danish or French or some other keyboard layout is just a matter of hitting Apple + space. Is your point just that whatever it is the fingers touch should also change to display the layout, as in the Optimus or the iPhone? Or also that the current arrangement of keys (or their equivalent) should be replaced by something different and bigger that lets you create many more characters without "switching" layouts?

I suspect it is more likely that technology will jump to input via dictation than that we will see radical changes in the way people "type", but you never know...

I suspect it is more likely that technology will jump to input via dictation than that we will see radical changes in the way people "type", but you never know...

Better let the developers do the developing and then discuss what they have developed when they have developed it.

Storm Petersen, a favourite humourist, wryly wrote that predictions are uncertain, in particular predictions about the future -:).

/hh

Better let the developers do the developing and then discuss what they have developed when they have developed it.

Of course. But if you do have a personal concept of an idea for a finger operated multilingual input system (for example for the Latin, Greek, and Cyrillic used officially in the EU) which avoids layout switching and excessive use of modifier keys, I would be interested in hearing/seeing some details. The EU projects I have seen elsewhere, like the MEEK, do not seem that attractive.

But if you do have a personal concept of an idea for a finger operated multilingual input system (for example for the Latin, Greek, and Cyrillic used officially in the EU) which avoids layout switching and excessive use of modifier keys, I would be interested in hearing/seeing some details.

Your previous post pointed to dictation. In industrial design, this would work if and only if the input method were used where dictation is permitted. A touch surface is silent, opposite non-manual dictation and opposite a clattering manual keyboard.

One way is to try to direct development to a preferred implementation and another way is to publish what development has done over three decades to direct development away from what was obviously wrong. If you want to publish anything, then you are better off with the latter than with the former.

There is a 1992 video with Steven Jobs demonstrating the Digital Librarian in NeXTStep release 3. There are many, many technical documents on the Macintosh project. There are also many, many technical documents on PostScript, QuickDraw, and QuickDraw GX.

I'll give you an example. Did you know that the feature selectors for mapping letter o and letter slash to ø or letter l and letter slash to ł was intended for UK users and US users so they would be able to draw what was not directly depicted on their keyboards? Or in other words, that TrueType 2 was in part implemented to supplement the hardware keyboard and the software KeyCaps accessory. I know you think this is a truly terrible idea, but it is interesting that the idea went from idea into implementation. A lot of ideas went from ideas into implementations, even if the ideas were truly terrible. I'm not clairvoyant and I don't have a crystal ball, all I have is a collection of developer discussions and technical documents reaching back decades.

Reference:
http://www.youtube.com/watch?v=j02b8Fuz73A

I'm not clairvoyant and I don't have a crystal ball, all I have is a collection of developer discussions and technical documents reaching back decades.

If your historical collections have given you any more specific ideas about how multilingual input could be better organized for future systems, let us know.

If your historical collections have given you any more specific ideas about how multilingual input could be better organized for future systems, let us know.

Sorry, missed this note.

We already discussed this at the turn of 2008. If you imagine 23 writing systems in 3 world scripts where multilingualism is politically presupposed, then you would want mechanisms as well in hardware as in software to simplify character selection. You would specifically not want 450 million users working with primary writing systems, less familiar secondary writing systems, and still less familiar tertiary writing systems trying to simulate by using transliteration or transcription since transliteration and transcription are not invertible to the real spellings of the simulated writing system.

ISO 6937-1:1983 and PostScript in 1984-85 both have somewhat the same mechanism. ISO 6937 encodes alphabetics and accents separately, but accents are not considered separate characters and only such combinations of alphabetics and accents that are also specified as precomposed characters are permissible. Similarly, PostScript allowed runtime rendering (not by mark attachment but by offset attachment) if and only if the named components to be combined were defined as precomposed in the encoding vector of the font program dictionary. There is more to the problem of transliteration and transcription in computerised cataloguing than the above mathematical mechanisms, but a distinction between single spelling, serial spelling, and synthetic serial spelling is a step.

Currently, the command Show Character Selected in Application availabl in the Apple Character Palette cannot decompose glyphs drawn from other glyphs (Apple MORX and Microsoft GSUB drawing) nor can the command decompose combining character sequences. There is also no way to represent the character writing spaces / sample character repertoires of the Common Locale Data Repository of which Apple is chair. You wouldn't want to try to teach the Unicode character model and the Unicode character-glyph composition model with the state of Apple's implementation as it stands. It simply is not good enough.

/hh

Thank you. Simple answer.

CAUTION
The input method is not the same worldwide.
It is linked to the language which is used by the operating system.

True.

Let us take a moment to be thankful for the static hardware input method, a truly well thought out work of industrial design. It has given us the KeyCaps desk accessory with which we wangle a change of key code to character code mapping (and have to check the display to know what the condition of the keyboard is in), it has given us complicated mnemonic keyboard shortcuts that compete with the complications of Adobe's charts for accessing the glyphs you want in a Type 1 font file, it has given us access to supplementary writing systems by combinations of key accent code + key alphabet code = precomposed 10646 level 1 character code.

Great for FIGS (French, Italian, German, Spanish). Greater still for the lesser languages spoken by five or ten million each. An admirable technology - along the lines of Adobe PostScript that does not even have the concept of a coded character set.

/hh