home *** CD-ROM | disk | FTP | other *** search
- Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
- Path: sparky!uunet!gatech!paladin.american.edu!auvm!FINUHA!JTAKALA
- X-Envelope-to: NOTABENE@TAUNIVM.BITNET
- X-VMS-To: IN%"NOTABENE@TAUNIVM.BITNET"
- X-VMS-Cc: JTAKALA
- MIME-version: 1.0
- Content-type: TEXT/PLAIN; CHARSET=US-ASCII
- Content-transfer-encoding: 7BIT
- Message-ID: <01GPW3WNX9RI9ANIRJ@hylk.Helsinki.FI>
- Date: Tue, 13 Oct 92 07:39:00 IST
- Sender: Nota Bene List <NOTABENE@TAUNIVM>
- From: "J-P Takala, University of Helsinki, Sociology" <JTAKALA@FINUHA>
- Subject: Accents, Umlauts, Orbis Search
- Newsgroups: bit.listserv.notabene
- Lines: 29
-
-
- There seems to be a solution to the problem of entering accented/
- umlauted/circumflexed/non-plain-a-to-z-characters to the Orbis
- search window so simple I'm almost afraid to say it:
-
- Use a .kbd file which, instead of defining those characters as
- a sequence of the type "ni,o,ov,*,u", has the "plain" accented
- character on the right side of the definition, just like the
- non-English .kbd files in 3.0 and 3.1 have.
-
- For instance, in the Finnish, Swedish and (I guess) German keyboards
- the unshifted key no 39 is defined as>
- 39=ni,o,ov,*,u
- If you use the definition (as in 3.0, 3.1):
- 39=x
- where x stands for the actual lowercase o-umlaut, you can enter
- that in Orbis search window, too.
-
- This works for the non-shifted and shifted keyboard. I did not
- not try other tables, but would guess it works there too, because
- the problem seems to be that somehow Orbis presently cannot
- handle the OV,* procedure.
-
- CAUTION. I don't know why NBI chose not to use the 3.0,3.1
- way of mapping accented characters. If they had a good
- reason, there might be some adverse effects from going about
- it the way suggested here.
-
- j-p takala
-