home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The World of Computer Software
/
World_Of_Computer_Software-02-385-Vol-1of3.iso
/
j
/
jdic15.zip
/
JREADER.DOC
< prev
next >
Wrap
Text File
|
1992-01-12
|
9KB
|
197 lines
J R E A D E R
Japanese Text Reader with Online Dictionary Search & Yomikata Lookup
====================================================================
Version 1.1 (January 1992)
INTRODUCTION
------------
This program provides a capability to display a text file containing Japanese
characters (kana & kanji) with the option of looking up displayed words in a
Japanese/English dictionary file or in MOKE's kanji-to-kana yomikata file.
The Japanese characters in the text files can either be in the EUC, New-JIS,
Old-JIS or Shift-JIS codes. In the case of EUC and Shift-JIS, hankaku codes
are not supported. A file containing other codes, such as NEC-JIS, etc., can be
concerted into one of the supported codes using utilities such as "jc" and
"jis".
Although JREADER is intended to help non-Japanese people read Japanese language
text files, it can also be used by Japanese to read English text. Its
usefulness in this role is limited by the dictionary, which is more oriented to
the Japanese to English mode, and the fact that the dictionary search cannot
cope with things like English's "strong" verbs (swim/swam/swum, be/am/are,
go/went, etc.).
JREADER is an extension of the author's JDIC (Japanese/English Dictionary
Display) program, which has been designed specifically to operate on a
dictionary in the "EDICT" format used by the MOKE (Mark's Own Kanji Editor)
Japanese text editor. As with JDIC, JREADER's operating environment has been
designed to be similar to MOKE's, and it uses the same environment variables
and control file as MOKE. Along with JDIC, it will be updated to track MOKE
versions (at present it is aligned with the beta-test version of MOKE2.1.)
The executable code and documentation of JREADER is hereby released to the
"public domain". All usage of this program is at the user's risk, and there is
no warranty on its performance.
All the Japanese displayed is in kana and kanji, so if you cannot read at least
hiragana and katakana, this program will not be much use for you. The author
has NO intention of producing a version using romanized Japanese.
THIS DOCUMENT
-------------
JREADER is an extension of JDIC, and shares a similar operating method as JDIC.
Consequently this document file only includes details of where JREADER differs
from JDIC. Please make sure you have and read the appropriate JDICnn.doc file.
INSTALLATION
------------
This program is distributed in a "zoo" archive (jdicnn.zoo) containing the
files of both JDIC and JREADER. Follow the installation details in JDICnn.doc.
ENVIRONMENT
-----------
JREADER uses the same environment variables and moke.rc fields as JDIC (and
MOKE). These affect things like paths and colours.
OPERATION
---------
JREADER is simple to operate. The command-line invocation is:
jreader <options> text-file
The same -l, -f, and -bnn options are used as in JDIC. In addition, JREADER
uses:
-sn (2 < n < 8) specifies that the text window is to use n/10 of the screen,
The default is n = 7.
-ddictionary-file specifies the file that is to be used as the dictionary,
along with an index file with an extension of ".jdx". This
latter file must be created using the JDXGEN utility. The
default is "edict", with "edict.jdx" as the index file.
The working screen of JREADER contains two windows. The upper displays the text
being read, the lower displays control information and the dictionary and
yomikata search results.
The first screenful of the text file is displayed when the program starts. From
then on most operation is by single keystroke commands. They are:
<PgDn> reads the next screen of the file. The last line of the previous screen
is repeated as the first line of the next.
<PgUp> reads the previous screen of the file. The backspacing technique is
somewhat crude, and may under or overshoot the start of the previous screen.
<Arrow> The four arrow keys can be used to position the cursor under a
character which may be used as the start of a key for a dictionary search.
<Enter> positions the cursor at the start of the next line.
<e> positions the cursor at the end of the current line.
<b> positions the cursor at the start of the current line.
<Home> positions the cursor at the start of the screen.
<End> positions the cursor at the last line of the screen.
<Space> triggers a dictionary search using the string of characters beginning
with the one marked by the cursor. (See below.)
<l> logs the character string marked by the cursor to a file called
"jreader.log". The logged data is in MOKE's "edict" format, i.e. `kanji [kana]
/english .../', with the logged characters being inserted in the `kanji' field.
You will be prompted for the string length (up to 9 characters). If you
respond with Enter, and the cursor is on a Kanji, all the kanji in the compound
will be logged. You are also given the option of adding up to 50 characters of
English to the logged entry. (The purpose of the logging function is to
generate a file of Japanese words which are not currently in the dictionary
file. This file can be edited later, e.g. using MOKE, the yomikata and English
translation added or modified, and the entries included in the full
dictionary.)
<y> invokes a scan of the "wsktok.dat" file to find the yomikata of the kanji
compound starting with the character at the cursor. This option only works if
the "wsktok.dat" and "wsktok.ind" files are available, i.e. you need to be a
MOKE (2.0 or later) user. The longest matching sequence is displayed, and you
are given the option of logging this entry (kanji and kana) to the
"jreader.log" file, along with up to 50 characters of English. In combination
with the <l> option above, this option provides a useful way of building up the
dictionary file.
<s> skips ahead in the text file to a line starting with "Article:". This is to
simplify reading a file containing several Japanese news items.
<k> skips the cursor to the start of the next Kanji compound. If Automatic
Lookup mode is active, the dictionary is searched for this compound. (See
below)
<m> displays the next window of dictionary matches (if any).
<F1> Displays a summary of the keyboard commands.
<F2> Toggles Automatic Lookup mode (See <k> above.)
DICTIONARY SEARCHING
--------------------
The dictionary search is similar to the one used in JDIC, except that the key
is taken from the text being displayed, rather than from keyboard input. Also
the search can be on kanji keys, as well as kana and ascii.
Starting with the character marked by the cursor, the longest match found and
displayed, followed by the next longest, and so on. Usually the first match is
the one you want, although in some cases such as inflected verbs the verb entry
may be several entries down the screen. The dictionary display is identical to
that in JDIC, except that each line is preceded by the number of matched
characters. If there are more matched lines than fit in the window, pressing
"m" displays the next window-full.
YOMIKATA SEARCHING
------------------
MOKE's "wsktok.dat" file contains thousands of kanji compounds with their
readings in kana. It is sorted, and indexed on the first byte of the first
character in the "wsktok.ind" file. JREADER seeks into and scans this file for
the longest matching sequence of characters. Only one such compound is
displayed.
ADDITIONS TO PREVIOUS VERSION(S)
--------------------------------
V1.1 - Yomikata lookup, TAB expansion, Shift-JIS reading, PgUp for previous
screen.
AUTHOR'S COMMENT
----------------
JREADER is to me a natural extension of JDIC, and further exploits the fast
dictionary scanning technique used therein. It also has been written with a
need in mind. I have been using Mark Edwards' excellent VIEW and MOKE to read
fj.* news (using the SNUZ news reader into "mtfuji".) I was frustrated by the
slowness of the English lookup in MOKE (a sequential read of the entire file)
and its refusal to add a compound to the dictionary if it was not in the
kanji/kana henkan file. Also both MOKE and VIEW require precise delineation of
the search string using several keystrokes. This can result in several slow
attempts to find meanings for portions of a kanji compound. What I wanted was
something friendlier and faster in a reading environment. If JREADER seems to
be a competitor to Mark's VIEW, well so be it.
As ever, comments and suggestions are welcome.
Jim Breen (jwb@capek.rdt.monash.edu.au)
Department of Robotics & Digital Technology
Monash University
Melbourne, Australia