wnn_automaton(4) (JFP Reference Manual 4 : File Formats)

JFP Reference Manual 4 : File Formats

wnn_automaton(4)

NAME

wnn_automaton- Automaton

DESCRIPTION

Automaton performs xjsi and uum roman character–Kana conversion by referring to the entries mapped in a table (called a conversion table). Automaton can replace tables to enable versatile conversion.

Automaton performs three conversions in series according to conversion tables (in the order of preprocessing, main processing, and postprocesing) and outputs the final results. Processing is handled according to conversion tables for each of the three conversions. Atomaton also has a mode function. The mode can be switched to dynamically change the combinations of the three processing stages. Setting the mode and the switchover codes is also performed using conversion tables.

Because the conversion tables are text files, they can be replaced easily. You can use a backspace to return to the previous status after a conversion has been completed and before the next conversion is completed.

Although xjsi performs roman character–Kana conversion only between uppercase alphbets and Hiragana in the main processing stage, the preprocessing and postprocessing stages can handle various types of inputs and outputs. For example, the preprocessing can convert lowercase alphabets to uppercase alphabets. The postprocessing stage can convert Hiragana to Katakana or Hiragana to half–width Katakana.

Automaton proceeds with the operation as follows.

Input. Upper/lowercase of alphabet (half–width)
Preprocessing. Converts lower case characters to uppercase characters.
Main processing. Converts uppercase alphabets to Hiragana according to the conversion table.
Postprocessing. Converts Hiragana to Katakana or half–width Kana as required.
Output

Conversion Tables

Automaton uses the following conversion tables.

Mode definition table

Declares the mode and the correspondence tables to use. The file name is mode.
Correspondence tables
- Preprocessing tables
  
  The correspondence table used for preprocessing. The file name begins with "1".
- Main processing tables
  
  The correspondence table used for main processing. The file name begins with "2".
- Postprocessing tables
  
  The correspondence table used for postprocessing The file name begins with "3".

The mode definition table contains the mode declaration, the correspondence tables to be used for each mode, and table usage rules for them.

The correspondence tables contain lists of corresponding input codes and output codes. The correspondence tables are separated into those for preprocessing, main processing and postprocessing and any number of correspondence tables can be used for each processing.

xjsi searches for the mode definition table in the following order.

Specification by setrkfile entry in the xjsi initialization file uumrc
File name /usr/lib/locale/ja/wnn/ja/rk/mode

The following table entires can be used in the following mode definition table and correspondence tables.

. . . Indicates repeating 0 or more times.
. . . . . . Indicates one or more times.
[ ] Indicates optional.

Mode Definition Table

The mode definition table contains the mode declaration, the correspondence tables to be used for each mode, the determination standards for them, and the mode display text strings.

The mode definition table consists of the following items 1, 2, 3, and 4. The remainder of a line is treated as a comment if a semicolon (;) appears at the beginning of the line or follows leading space(s) (including tabs) unless the semicolon is escaped.

1. Special path specification

The followings are special strings to represent path names.

@HOME: Indicates the environment variable HOME
@MODEDIR: Indicates the directory containing the mode definition table.
@LIBDIR: /usr/lib/locale/ja/wnn/
~user: If user is a user name, it indicates the user's home directory.
~: Indicates your home directory.

2. Mode Declaration

The mode is declared as follows:

defmode mode_name [on|off] [r|nr]: mode_name specifies alphanumerics. [on|off] Specifies the initial status. The default is off. [r|nr] is a flag to allow Automaton to recognize roman character–Kana conversion mode. In a mode in which r is set, it is used regardless of the current mode when converting Hiragana by F6 key, etc. The default is nr.

The mode declaration is made before the mode is used.

3. Search Specifications for Correspondence Tables

Search specifications are made for correspondence tables using the following format.

search directory. . .: Specify the directory name(s) to be searched when the correspondence tables specified in the mode definition table are not in the same directory as the mode definition table. Multiple directory names can be specified by separating them with spaces. The search directory name must be specified before the correspondence tables.
path directory. . .: Overrides any directory names previously stored to search for correspondence tables and specifies to search the directory name(s) specified as the argument. Multiple directory names can be specified by separating them with spaces. The path directory name must be specified before the correspondence tables.

4. Specifications for Correspondence Tables and Mode Display Text Strings

There are three ways for the specifications.

(1): Correspondence table file names or mode display text string
(2): if Conditional_expression. Correspondence_table_specifications or Mode_display_text_string
(3): when Conditional_expression. Correspondence_table_specifications or Mode_display_text_string

File names for correspondence tables must begin with (1), (2) or (3). Path names can also be specified. Mode display text strings are text strings enclosed with quotation marks used to display the current mode.

(a)

"string"

Indicates the mode display text string when conversion is ON.

(b)

(on_dispmode "string")

Indicates the mode display text string when conversion is ON.

(c)

(off_dispmode "string")

Indicates the mode display text string when conversion is OFF.

(d)

(on_unchg)

Indicates the same mode display text string as was used before the mode was changed be used when conversion is ON.

(e)

(off_unchg)

Indicates the same mode display text string as was used before the mode was changed be used when conversion is OFF.

This text string is used by xjsi to display the mode.

(2) and (3) are used to change the correspondence table depending on specified conditions. If the condition in the if statement in (2) is true, then the specification in the if statement is referenced and the specification following the if statement is not referenced. If the condition is false, the if statement is exited and the specification following the if statement is referenced.

If the condition in the when statement in (3) is true, the specification in the statement is referenced. The specification following the when statement, however, is referenced regardless of whether or not the condition is true or false.

(2) or (3) can be used recursively to specify correspondence tables.

Any one of the following can be used for the conditional statement.

mode_name	True when the mode is ON
(and conditional_statement conditional_statement)	True when both of the conditional statements are true
(or conditional_statement conditional_statement)	True when either of the conditional statements is true
(not conditional_statement)	True when the conditional statement is false
(false)	Always false
(true)	Always true

For example, when (defmode kana) and (defmode romajikana) are both in the mode definition, (and kana romajikana) is true when both modes are ON.

Where conditional statements are represented by @, #, and *, and conversion table names are represented by A, B, and C, assume the following statement.

(when @ A (if # B ) C ) (if * D ) E

Also assume that conditional statements @, #, and * have been met. Examine the statement from the beginning. First comes (when @ A (if # B) C). Because @ has been met, "A (if # B) C" is examined and table A is selected.

Next comes (if # B ) and # has been met so table B is selected. Because this is an if statement and the conditional statements have been met, the rest of the current series "A (if # B)C" need not be examined. Although this ends examination of "A (if # B)C," this series is contained in a when statement, so the remainder of "(when @ A (if # B )C) (if * D) E" is examined.

The next portion is (if * D). Table D is selected because the condition statement * has been met. Because this is an if statement, the rest of "(when @ A (if # B ) C ) (if * D ) E" is not examined. As a result, tables A, B, and D are selected.

Next we'll use the mode definition tables used by xjsi as an example.

Three modes are defined in the mode definition table. There are specifications for correspondence table and mode display text string to be used from 2A_CTRL to the end. This table is referenced each time the mode changes and the tables to be used are selected as described above.

(defmode romkan)
(defmode katakana)
(defmode zenkaku)
2A_CTRL (if romkan
         1B_TOUPPER
         2B_ROMKANA 2B_JIS
          (if (not katakana) "[Ar]")
          (if zenkaku 3B_KATAKANA "[Ar]")
          3B_HANKATA "[AIr]")	; "A" and "I" are half-width Katakana.
2B_DAKUTEN
(if (not katakana)
         1B_ZENHIRA
         (if zenkaku 3B_ZENKAKU "[A ]")
         "[AA]")
(if zenkaku
         1B_ZENKATA
         3B_ZENKAKU
         "[A ]")
         "[AIA]"	; "A" and "I" are half-width Katakana.

Initially romkan , katakana, and zenkaku are all OFF. 2A_CTRL is selected as the table at this point. Because romkan is OFF, the following if statement is not referenced, and 2B_DAKUTEN is selected. The conditional statement for the next if statement, (not katakana), is true because katakana is OFF. The inside of the if statement is referenced and 1B_ZENHIRA is selected. Next the if statement inside the if statement is referenced. Because zenkaku is OFF, the conditional statement is false. The if statement is thus not referenced.

Next the mode display text string "[A[hiragana-A]]" is selected and the rest of the conversion table series is not examined.

Correspondence Tables

The correspondence tables contain the conversion data (input codes and corresponding output codes) for preprocessing, main processing, and postprocessing.

Preprocessing and postprocessing play supplemental roles for main processing. The following restrictions thus apply to preprocessing and postprocessing correspondence tables.

Preprocessing Table: Item (2), below, is not possible. Also, there can only be one form for each input and output code in item (1) that results in a character when evaluated. The buffer remainder cannot be entered.
Postprocessing Table: Item (2), below, is not possible. Also, there can only be one form for each input code in item (1) that results in a character when evaluated. The buffer remainder cannot be entered.

All lines in the correspondence table must contain one of the following items (1) to (3) or must be empty. Lines of this form are repeated to form the correspondence table.

(1): input_code [output_code [buffer_remainder]]
(2): input_code function
(3): Variable declaration

Each entry must occupy no more than one line. The remainder of a line is treated as a comment if a semicolon (;) appears at the beginning of the line or follows leading space(s) (including tabs) unless the semicolon is escaped.

The output code or buffer remainder will be treated as a null string if omitted. Input codes, output codes, and buffer remainders must contain strings of the following without intervening spaces: forms that evaluate to characters and forms that evaluate to text strings.

Forms are considered to evaluate to characters or text strings if the form is replaced by the character or text string.

The following types of forms evalutate to characters.

(1) Character Notation

Character notations are shown below (these differ from character notations treated as forms that evaluate to text strings).

Character: Characters excluding "(", ")", "'", """, "\", ";", and space characters
'Characters': Characters excluding "'", "\", and "‸" characters.
'‸Character': Represents control characters. The characters can be ASCII code 32 to 126. ‸? indicates a DEL code.
'\Character': Characters do not include numerics, "o", "d", and "x". "\n", "\t", "\b", "\r", "\f" indicates the characters same as escaped codes in the C language. "\e", and "\E" indicate escape characters. The other characters are literally interpreted.
'\octal code. . . . . .': Indicates a character corresponding to the specified octal code.
'\ooctal code. . . . . .': Indicates a character corresponding to the specified octal code.
'\ddecimal code. . . . . .': Indicates a character corresponding to the specified decimal code.
'\xhexadecimal code. . . . . .': Indicates a character corresponding to the specified hexadecimal code.

(2) Function Name with Form that Evaluates to a Character

Function name	Description
`toupper`	If the augument is a lowercase alphabet ASCII character, it is changed to an uppercase character. Example: (`toupper a`) -> `A`
`tolower`	If the augument is an uppercase alphabet ASCII character, it is changed to a lowercase character. Example: (`tolower A`) -> `a`
`toupdown`	The case of the alphabet ASCII character is changed from upper to lower or from lower to upper. Example: (`toupdown a`) -> `A` (`toupdown A`) -> `a`
`tozenalpha`	If the argument is an ASCII character, it is converted to a full–width Japanese roman character. Example: (`tozenalpha A`) -> `A`
`tohira`	If the argument is full–width Katakana, it is converted to Hiragana. Example: (`tohira` A) -> A
`tokata`	If the argument is Hiragana, it is converted to full–width Katakana. Example: (`tokata` A) -> A
`tozenhira`	If the argument is half–width Katakana, it is converted to Hiragana. Example: (`tozenhira` A) -> A ; "A" is half-width Katakana.
`tozenkata`	If the argument is half–width Katakana, it is converted to full–width Katakana. Example: (`tozenkata` A) -> A ; "A" is half-width Katakana.
`value`	Converts a character code to its actual numeric value. Example: `value 0` -> `'\x0'` `value A` -> `'\xA'` `value F` -> `'\xf'`

(3) Function Name with Two Forms that Evaluate to Characters

Function name	Description
+	Finds the sum of the arguments. Example: (+ A '\d256') -> A (+ 0 (value 3)) ▻ 3
–	Finds the difference of the arguments.
*	Finds the product of the arguments.
/	Finds the quotient of the arguments.

(4) Variable Names

Variable names are any alphanumeric text strings beginning with an alphabet that do not correspond to function names, functions, and declarations (defvar). Where, an underscore '_' is considered as an alphabet.

The following types of forms evalutate to characters.

(1) "Character Notation. . ."

Character notations are shown below (these differ from character notations treated as forms that evaluate to text strings).

Character: Characters excluding """, "‸", and "\".
‸ character: Indicates a control character. It can be an ASCII code 32 to 126 character. ‸? indicates a DEL code.
\Character: Characters do not include numerics, "o", "d", and "x". "\n", "\t", "\b", "\r", "\f" indicates the characters same as escaped codes in the C language.
\octal code. . . . . .[;]: Indicates a character corresponding to the specified octal code. Specify a semicolon (;) if number(s) follow.
\ooctal code. . . . . .[;]: Indicates a character corresponding to the specified octal code. Specify a semicolon (;) if number(s) follow.
\ddecimal code......[;]: Indicates a character corresponding to the specified decimal code. Specify a semicolon (;) if number(s) follow.
\xhexadecimal code......[;]: Indicates a character corresponding to the specified hexadecimal code. Specify a semicolon (;) if number(s) follow.

"" indicates an empty character string.

(2) Function Name with Form that Evaluates to a Character

Function name	Description
`tohankata`	If the augument is full–width Hiragana or full–width Katakana, it is converted to half–width Katakana. Example: `tohankata` [hiragana–GA]) to [hankakukana–GA]
`last=`	Examines the argument (a form that evaluates to a character) to see if it matches the last character of the last–matched text string. If the character matches, an empty text string is returned. Example: `last=` A ▻ [A] `last=` can only be entered for input codes.
`todigit`	Converts the code given as the first argument to a number in the number base code given as the second argument.
`dakuadd`	Adds a Dakuten (voiced constant mark) after the argument.
`handakuadd`	Adds a Handakuten (semivoiced constant mark) after the argument.

(3) Function Name with Mode Name

The mode name must be defined in the mode definition table.

Function name	Description
`if`	If the mode given as the argument is ON, (`if` `mode_name`) returns an empty string. Example: `(if katakana)VU` [katakana–VU]
`unless`	If the mode given as the argument is OFF, (`unless` `mode_name`) returns an empty string. Example: `(unless katakana)VU` [hiragana–BU]
`on`	Turns ON the mode given as the argument. Example: `(on katakana)`
`off`	Turns OFF the mode given as the argument. Example: `(off katakana)`
`switch`	Switches the state of the mode given as the argument, i.e., ON to OFF or OFF to ON. Example: `(switch katakana)`

However, if and unless can only be entered for on, off and switch can only be entered for output codes in the main processing table.

(4) Function Names Only

The following function names can only be entered for output codes in the main processing table.

Function name	Description
`allon`	Turns ON all modes.
`alloff`	Turns OFF all modes.

Precautions on functin usage

Because functions are forms that evaluate to characters or text string, it can be represented as (toupper (tolower Y)). However, if evaluated as follows, a function that evaluates to text string cannot be used as arguments for other functions.

(toupper (tohankata [Hiragana KA]))

Functions

The following functions can be used. These functions can be used independently.

(error): An error will be generated if the corresponding input code is received.
(restart): The previous mode definition table is read again to reset conversion. If there is an error in the new conversion table, an error message is displayed and the settings in the previous (original) conversion table are used.

Variable Declarations

(defvar variable_notation (list character_notation......)): list uses its arguments as the variable range.
(defvar variable_notation (all)): all uses all the characters as the variable range.
(defvar variable_notation (between character_notation1 character_notation2)): between uses characters between character_notation1 and character_notation2 (both inclusive), when sorted in the code order, as the variable range.

Variables that can be used as forms that evaluate to characters and the range of the variables is defined. Variables are declared in the table that uses it.

Variable notations are given as variable names or as (variable_name... ... ). Character notations are the same as forms that evaluate to characters.

The variable definitions are effective on the entire table. The same variable cannot be declared twice by defvar in a table.

You can define a variable a1 in a table, and define it in another table with different specifications. Two variables of a1 are processed independently.

Variables

Variables can be used effectively when the same patterns appear many times in conversions, such as in the following example.

(defvar a1 (list  K S T H Y R W G Z 
D B P))
(a1)(a1) [small tsu] (a1)

The above two lines achieve the same conversions as the following lines. Both show methods of handling assimulated sounds (Sokuon) in roman character–Kana conversion.

KK	[small tsu]	K
SS	[small tsu]	S
TT	[small tsu]	T
...
(omitted)
PP	[small tsu]	P

The variables declared in the variable declaration are processed.

(between A E) and (list A B C D E) are the same.

Precautions on variables

Variables to be used must be defined by variable declaration in the table.

You can define the variable a1 in two different tables as required and the a1 will be treated as two separate variables. You cannot, however, define the same variable twice in one table. Variable definitions are valid anywhere within the table. You can define the variable a1 within two different tables as required and the a1 will be treated as two separate variables. The definitions of variables are effective in the entire table. You cannot, however, define the same variable twice within any one table.

A variable always has the same value within a single line in a correspondence table.

(defvar a1 (list  A  B))
	(a1)(tolower (a1)) 3

The text strings "Aa" and "Bb" will be converted to "3" in the above example and not to "Ab" and "Ba".

Input code is matched with input codes in the tables starting at the left. Thus, when examining input codes from the left in the tables, a variable must not be used where it will be treated as the argument of a function before it is matched to specific characters, such as in the following example.

(defvar a1 (list a b))
	(toupper (a1))(a1) 3

"Aa" will not be converted to "3", because the argument of (toupper(a1)) is the variable a1, which does not yet have a value. This type of setting is checked when tables are read into the system.

In this case, if you make changes as follows, the result will be as expected.

(defvar a1 (list a b))
	(a1)(toupper (a1)) 3

If "aA" and "bB" are input, they are converted to "3 ".

(defvar a1 (list A B))
	(a1)(toupper (a1)) 3

If "Aa" and "Bb" are input, they are converted to "3 ".

Any variable appearing in the output codes or buffer remainder section must appear in the input code section, i.e., must have been assigned a value when matched to an input code.

(defvar  a1  (list  K  S))
	(defvar  a2  (list  a))
	(a1)(a1)   (a2)    (a1)

The above programming is not correct because the variable a2 is not matched to an input code, but appears for an output code.

Conversion Method by Correspondence Table

Preprocessing

First, the code that is input is grouped into character units (characters of 2–byte codes are also treated as one character). This is called the input code.

In preprocessing, each input code corresponds to one output code. The output code from preprocessing becomes the input code for main processing.

Input codes in the preprocessing table currently used are examined in the order from the beginning. When a match is found for the input code, the corresponding output code (i.e., the output code written on the same line as the input code) is output.

If there is more than one table specified in the mode definition table, they are examined in the same order as listed in the mode definition table. If no matching input code is found in a table (including when no table is specified), the input code is output unchanged. This is also true for main processing and postprocessing.

Main processing

In main processing, input code is continuously added to the buffer as long as there is still a chance that a longer match will be found in the input codes in the table (i.e., when some number of characters from the beginning of the current section of input code have already been matched sometwhere in the table).

Each time more input code is added to the buffer, comparisons are again done in the order from the beginning of the input codes listed in the main processing table. As long as there is a chance of the input code in the buffer matching with the longest entry in the table (i.e., when some number of characters from the beginning of the current section of input code have already been matched somewhere in the table) a conversion is not finalized and more input code is awaited. The code in the buffer is, however, output as nonfinalized characters to enable displaying and other processing.

Codes for input errors and mode changes are also output. These codes are differentiated from normal output codes and do not undergo postprocessing. When the contents of the buffer matches the longest possible input code in the table (if more than one match is made, then the first one in the table is used), the corresponding output code is output. If no buffer remainder has been specified, the part of the buffer that was matched is deleted from the buffer. If a buffer remainder was specified, it replaces the portion in the buffer that was matched and the above operation is repeated.

If no possibility of a match is found in the table, the first character in the buffer is output unchanged. If the output code for a matched input code is a function that changes the mode (on, off, switch, etc.), the correspondence table is changed according to the specifications in the mode definition table. The functions that change the mode should be placed in the tables where they are required regardless of the status of the modes.

If a match is found for the input code corresponding to the function (restart), the mode definition table will be reread. However, the same file as the one for the previous mode definition table will be used. This function can be used to change to an edited version of the conversion tables (including the mode definition table) while the Automaton is running without having to stop the Automaton.

Postprocessing

In postprocessing, more than one output code can be output for one input code as the final output. In all the other ways, postprocessing is the same as preprocessing.

In the following example "ls -la (carriage_return)" is output when "Ls" or "LS" is input.

Preprocessing table

(defvar   a1   (list s))
(a1)  (toupper (a1))

Main processing table

LS        "LS –la\n"

Postprocessing table

(defvar   a1   (all)) (a1)
(tolower (a1))

SunOS 5.9 Last Revised 2 Sep 1998

NAME | DESCRIPTION | Conversion Tables