Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!cernvax!chx400!ugun2b!ugsc2a!fisher From: fisher@sc2a.unige.ch Newsgroups: comp.binaries.ibm.pc.d Subject: Re: ALED goes to .... (technical answers) Message-ID: <1991Jun17.183352.480@sc2a.unige.ch> Date: 17 Jun 91 16:33:52 GMT References: <19965@csli.Stanford.EDU> <1991Jun16.122436.12392@cbfsb.att.com> Organization: University of Geneva, Switzerland Lines: 138 In article <1991Jun16.122436.12392@cbfsb.att.com>, mbb@cbnewsb.cb.att.com (martin.brilliant) writes: > My wife and I use Microsoft Word 4.0, and we use ALT- to > enter extended ASCII (8th-bit) characters. I mention my wife because > in the teaching of the history of the English language she needs such > characters as barred-d and thorn; I mapped them to extended ASCII > characters and programmed Word to draw them on our daisy-wheel printer. > > ALED supports the same method of entering extended ASCII. The original > complaint was that that method was awkward. Not Fully. Some charcters are ignored, some other returen a "Macro not defined". Try chars 128-130, for example. You were lucky to choose some that ALED does support. Anyway, the ALT- is *not* the preferred method. Further: > I would welcome some explanation of how you tell MSDOS (or the editor) > that P is to be mapped into a-with-circle-on-top, and how you can get > a P (if Finnish uses P, as I think it does). Basically, you tell that MS-DOS. It used to be a stand-alone TSR, called KBXX.COM, where XX is the code for your country. Now (DOS 3.3, I don't remember since what version), it's a TSR linked in memory, the loader being KEYB.COM, with it's keyboard map KEYBOARD.SYS. Even standard US versions (which I prefer for other reasons) have this fully explained in the manual. For some languages, characters not in the US-IBM-PC-extended- ASCII-char-set (wheew!) must be implemeted through the code-page feature. It's really no big deal, as the keyboards come with the correct engravings (?) on the keys. Internally, the keyboard send scan-codes for every key that is pressed or released (limiting the number of keys to 127 for that system, as you use a 7-bit integer to designate the key, with the 8th bit set to high for key release). > My main question is this - do word processors newer than MS Word > provide a form of 8th-bit support that Word 4.0 does not have? Or do > versions of MSDOS newer than 3.3 provide a new form of support? If so, > what is it? The limitation factor is the 8-bit set. I know at least one product in the PC world that dropped that limitation - WordPerfect since 5.0. The coding is a little heavy (4 chars for every extended character...), but it allows you work with some 1500 chars. It's also the only word processor that implements full support for these characters (more about the standard half- support later...). In nelson@sun.soe.clarkson.edu (Russ Nelson) write: > How about it, you non-English speakers? Give us English-speaking programmers > a break and tell us what we need to do to get our programs to work on your > computers... Ok, this is what I'm doing... (languages used in desktop publishing on the PC: french, german, italian and english). The main problem with ALED is that it wants to improve on DOS's keyboard driver. That means that the keyboard interrupt is trapped and the active shift state is checked. Before doing that, you should really look at the keyboard mappins supported by DOS first. This is a common problem, you can check is with the following: C:\DOS> KEYB SF 437 (path\)KEYBOARD.SYS This loads the swiss-french keyboard driver into memory. No fear, it is _almost_ the same as the standard BIOS US driver. The main difference is that the Z and Y are inverted, and that you'll have troubles finding the punctuation. No fear though, as the sequence ALT-CTRL-F1 switches back to good ol' US key mappings, and ALT-CTRL-F2 let's you try the swiss pecularities again... Please note that there is an additional key: the AltGr (replacing the Right-Alt?), and that there are so-called "dead keys", allowing to type first the diaresis (e.g. ~) and then the letter (e.g. n) to get the accented character. This is done entierely by the keyboard driver. Now load (to pick two) any version of XTREE or derivatives or the program FONTED (a shareware E/VGA font editor) and try to answer a (Y/N) question. You will notice the you must type the "Y" of the US-map, that is my "Z". This is because the scan-code of the key is checked, not the resulting character... Now take Word 4.0 (this has been corrected, I think, in ver. 5.0). Try to enter a backslash at the prompt "enter filename". Word used to think that you don't need to format the filename (the main usage of ALT-keys in Word), thus disabling the alt-key during the entry... You had to type ALT- to get it. How's that for clean programming? Plese note that this problem was also with the *french* version of MS-Word. Now load ALED. You will remember that a swiss-french user expects to find ('e) and (`a) on the keys next to the "P" (american ; and '), with ("o) and ("a) in shifted state (american : and "). Try them! If ALED simply crippeled the Alt-, it would be a mere disfeature. As it stands, it doesn't respect DOS's key translations. That's a *bad* thing, diserving complaint by european users, if not a public flame war on Usenet. FOR PROGRAMMERS: If you want to intercept the keyboard interrupt, please call the real driver as a sub-function, and check whether the resulting character in the buffer is (1) a control character, (2) a "normal" character, including those from the higher table, or (3) an extended key. Then decide if you really want to override the user's expected behavior. The reason for the virulent attacks is probably a case of "ras le bol" - the bowl is full (what is the english equivalent?). It is true that european users often need more technical knowlege to get started (remember it was impossible to work with Word 4.0 without knowing the ALT- method, often ignored by US users...). The common problem of the Y/Z switch in Yes/No ansers needs also a bit of explanations. Of course, we are used to that. How many programs insist that the month comes before the day (exept in "the fourth of July" that would have been the way to go!), that the day had only 12 hours when we wish it had at least 36, that the decimal point is always a "period", or that an accented "e" is sorted alphabetically after the "z"... (even my user name is misspelled on our system... sigh!). IMPORTANT NOTE FOR PROGRAMMERS: The above misfunctions are due to a lack of knowlege of MS-DOS. After selecting a "country" code in config.sys, DOS offers full information about format of dates, time display, decimal character, case conversion and even (I think) sorting order. Another big source for misbehavior is the usage of the standard c functions/macros islower, toupper, etc. They are defined only in 7-bit mode. (I should clean-up my replacment macros and drop them on Simtel20, I know... :-) The problem is alas that the support for international characters is very far from being perfect: convert a lowercase (`e) to uppercase, and you'll get either no change or an uppercase E, without the accent (it was forgotten when creating the IBM-extended-ASCII-(etc.) :-). Converting it back yields, of course, a lowercase e... If you want to know what full support of international characters might mean, take a look at WordPerfect (and I'm only a *very* pleased user!). Enough for today, it seems this *is* a sensible matter for europeans (UK possibliy excepted due to relative US-compatibility :-) Markus G. Fischer fisher@sc2a.unige.ch