I tend to agree with you. As to your question, the OS was Taligent's
CommonPoint; a failure, but one that had pretty interesting technology.
(And had some pretty good lessons about how not to run a business.)
Mark
Addison Phillips wrote:
>
> Thanks for the response.
>
> Seems like this is something our dominant operating system vendors should work on improving. The proposed standard looks klutzy, but a good UI design could fix most of the existing/potential problems. Once upon a time I had memorized most of the upper 128 of code page 1252 and could almost type as fast using Alt+xxx as a translator could. ::sigh::
>
> Having composable key sequences means I'm not wasting brain cells on this garbage, but that's not going to work for Devanigari or Japanese. I agree with Markus Kuhn that hex entry is absolutely required SOMEWHERE, but as the default it stinks.
>
> If this model is going to be upgraded for Unicode support, then the variety of issues raised in this thread come into play. Ideally our major OS vendors will get to work on it. Otherwise, I guess there's an opportunity for shareware artists to make another $10 from me. /u2323
>
> Addison
>
> PS> With regard to your comments below, I think:
>
> 1. We're still going to end up having to hit the <switch keyboard> macro to activate this input mode, since IMEs and applications seem to have multiply overloaded the various keys available on most platforms.
> 2. The naming list thing is going to be a problem, since the standard defines the official names as ASCII "English" names ONLY. Transliteration only works if you know the mapping.
> 3. You're right, as an IME this is pretty simple stuff.
> 4. CM is useless and needs a replacement. KeyCaps I mentioned as something that could be adapted (currently, as you point out, it's tied to the active keyboard).
> 5. Clearly you've thought through this carefully. What OS was it that this was applied in?
>
> -----Original Message-----
> From: Mark Davis [mailto:mark@macchiato.com]
> Sent: Sunday, June 06, 1999 1:44 PM
> To: AddisonP@simultrans.com
> Subject: Re: Hexadecimal in many scripts (ISO 14755)
>
> You make some good points. My responses below.
>
> Addison Phillips wrote:
> >
> > I agree with what you're saying, but I'm with Michael (mostly) on this. I like the alternate methods you propose, although I can see some obvious problems with them. These include:
> >
> > 1. Lack of a special key available to the task. We're going to have to steal another key's functionality. On UNIX boxes, of course, the 'compose' or 'macro' key will work just fine. Mac and Windows users are in trouble (since control and alt and cetera already do things there is a risk of conflicting with the active keyboard/application base).
>
> There is that problem, though there are values in each case that can be
> used; there are already keys used for IMEs or keyboard swapping that can
> have additional modifiers or be overloaded.
>
> > 2. Name input implies that you have the full range of ASCII on your keyboard and active (otherwise you have to switch keyboards before entering the name). So:
> > <typing along, want U+2323>
> > <switch keyboard to L-1>
> > <type name>
> > <hit 'compose'>
> > <validate results>
> > <switch keyboard back>
>
> Not necessarily; fundamentally, all we had was a list of strings and the
> characters they mapped to. Multiple strings can map to the same output
> character for aliases. This list can be translated, etc. to the user's
> script or language. Moreover, if you are doing it in an IME context,
> then the operations can be:
>
> > <switch keyboard to name input>
> > <type name>
> > <hit 'compose'>
>
> compose can either be 'sticky' or return the keyboard to what it was.
>
> > 3. The parsing is somewhat nontrivial, especially if the characters have already been sent to the application. In-situ editing is going to be a mess (especially with restricted-length input fields). It would be better to activate the IME and then compose your character and then send the results to the application.
>
> I'm really in agreement. We had the freedom to have a simpler interface
> than IMEs for doing this, but it can be done with the existing IME APIs
> available on the platforms and use the same mechanisms. For example, if
> the application supports on-the-spot editing, then it can be done there;
> if not, then an off-the-spot window appears.
>
> > 3. Users outside Latin-1 and East Asia (notably Cyrillic users) will not be touchtypists in English (cf. the whole thing about the first six letter of the alphabet...) so they will hunt and peck out the name.
>
> The names can be translated (or at least transliterated), as described
> above.
>
> > 4. Composition is not evil, but our input method should try hard to precompose characters.
>
> I agree; in most circumstances, users would want that option turned on.
>
> >
> > Let's face it, this is a highly non-trivial problem. Reality is that, probably, most people will:
>
> You are right that compared to a "dead-key + hex method", this is
> substantial. On the other hand, compared to the effort of making a
> Japanese IME, this is completely trivial.
>
> > a. install the keyboards they need, alleviating most of the problem.
> > b. use utilities like KeyCaps and CharMap to find those not on their keyboards.
> > c. not use unusual characters. :-)
>
> I agree; lacking a utility (3) is what will happen (other than for those
> unusual individuals that have memorized the hex codes for large numbers
> of Unicode characters. I glossed over the differences between the
> Character Map style of entry and the IME style of entry in my first
> post. An enhanced Character Map is really a separate item, and can be
> handled pretty easily. The first step is to modify it so that CM feeds
> characters as they are chosen into the topmost other window as if they
> had been typed from the keyboard, thus avoiding the clumsy cut & paste
> operation. It would then work more like the integrated "Insert Symbol"
> dialog uses in Windows programs. By doing this, CM could be kept around
> at the bottom of the screen, and used whenever desired to pick
> characters. (The GUI could stand some redesign to make it easier to
> organize and find characters, but this alone would be a significant
> first step.)
>
> On the Mac, Keycaps really has a different design point; showing what
> you have to type to get a character rather than providing an
> organization for finding arbitrary characters. Something more like the
> Character Map on Windows would be more useful for entering Unicode
> characters.
>
> None of this is rocket science; if Apple or Microsoft wanted to do
> something like this, it would be a small amount of work compared to
> their efforts currently on international enablement.
>
> >
> > It would be nice to have a small, installable IME that can allow me to enter the hex value (possibly providing tiny squidges to click on for A-F in the GUI), the name of the character (as you propose), a property of the character (giving me choices), etc., compose the value and then send the character code on to the application. In other words, the IME is part of the operating system, not the application layer.
>
> I agree.
>
> >
> > thanks,
> >
> > Addison
> > __________________________________________
> >
> > Addison Phillips
> > Director, Globalization Services
> > SimulTrans, L.L.C.
> >
> > +1 650-526-4652 (direct telephone)
> > AddisonP@simultrans.com (Internet email)
> > http://www.simultrans.com (website)
> >
> > "22 languages. One release date."
> > __________________________________________
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:46 EDT