From: nisikimi Date: Fri, 9 Jan 2009 05:03:18 +0000 (+0000) Subject: *** empty log message *** X-Git-Tag: XML-base~9 X-Git-Url: http://git.chise.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=bfa4b762c4d68e12330372a985f0b3c674942bef;p=m17n%2Fm17n-db.git *** empty log message *** --- diff --git a/FORMATS/FLT.txt b/FORMATS/FLT.txt index cc7dda4..b06fca3 100644 --- a/FORMATS/FLT.txt +++ b/FORMATS/FLT.txt @@ -307,13 +307,17 @@ For @c LANGSYS, @c SYMBOL specifies a Language System tag name. If @c LANGSYS is omitted, the Default Language System table is used. -For @c GSUB-FEATURES, each @c SYMBOL in @c FEATURE LIST specifies a -GSUB Feature tag name to apply. '*' is allowed as the last item to +For @c GSUB-FEATURES, each @c SYMBOL in @c FEATURE-LIST specifies +a GSUB Feature tag name to apply. '*' is allowed as the last item to specify all remaining features. If @c SYMBOL is preceded by '~' and the last item is '*', @c SYMBOL is excluded from the features to apply. If no @c SYMBOL is specified, no GSUB feature is applied. If @c GSUB-FEATURES itself is omitted, all GSUB features are applied. +When @c OTF-SPEC appears in a @c FONT-SPEC, @c FEATURE-LIST specifies +features that the font must have (or must not have if preceded by +'~'), and the last'*', even if exists, has no meaning. + The specification of @c GPOS-FEATURES is analogous to that of @c GSUB-FEATURES. diff --git a/FORMATS/IM-tut.txt b/FORMATS/IM-tut.txt index 9a60a42..6e778d6 100644 --- a/FORMATS/IM-tut.txt +++ b/FORMATS/IM-tut.txt @@ -50,7 +50,7 @@ For instance @verbatim (n i) @endverbatim -represents a key sequence of <> and <>. +represents a key sequence of \ and \. If all SYMBOLIC-KEYs are ASCII characters, you can use the short form @verbatim "ni" @@ -104,8 +104,8 @@ Here is a simple example of an input method that works as CapsLock. When this input method is activated, it is in the initial condition of the first state (in this case, the only state [[init]]). In the initial condition, no key is being processed and no action is -suspended. When the input method receives a key event <>, it -searches branches in the current state for a rule that matches <> +suspended. When the input method receives a key event \, it +searches branches in the current state for a rule that matches \ and finds one in the map [[toupper]]. Then it executes MAP-ACTIONs (in this case, just inserting "A" in the preedit buffer). After all MAP-ACTIONs have been executed, the input method shifts to the initial @@ -122,7 +122,7 @@ that event is unhandled and given back to the application program. Turkish users may want to extend the above example for "Ä°" (U+0130: LATIN CAPITAL LETTER I WITH DOT ABOVE). It seems that assigning the -key sequence <> <> for that character is convenient. So, he +key sequence \ \ for that character is convenient. So, he will add this rule in [[toupper]]. @verbatim @@ -135,30 +135,30 @@ However, we already have the following rule: ("i" "I") @endverbatim -What will happen when a key event <> is sent to the input method? +What will happen when a key event \ is sent to the input method? -No problem. When the input method receives <>, it inserts "I" in the +No problem. When the input method receives \, it inserts "I" in the preedit buffer. It knows that there is another rule that may -match the additional key event <>. So, after inserting "I", it +match the additional key event \. So, after inserting "I", it suspends the normal behavior of shifting to the initial condition, and waits for another key. Thus, the user sees "I" with underline, which indicates it is not yet committed. -When the input method receives the next <>, it cancels the effects +When the input method receives the next \, it cancels the effects done by the rule for the previous "i" (in this case, the preedit buffer is cleared), and executes MAP-ACTIONs of the rule for "ii". So, "Ä°" is inserted in the preedit buffer. This time, as there are no other rules that match with an additional key, it shifts to the initial condition of the current state, which leads to commit "Ä°". -Then, what will happen when the next key event is <> instead of <>? +Then, what will happen when the next key event is \ instead of \? No problem, either. -The input method knows that there are no rules that match the <> <> key -sequence. So, when it receives the next <>, it executes the +The input method knows that there are no rules that match the \ \ key +sequence. So, when it receives the next \, it executes the suspended behavior (i.e. shifting to the initial condition), which -leads to commit "I". Then the input method tries to handle <> in +leads to commit "I". Then the input method tries to handle \ in the current state, which leads to commit "A". So far, we have explained MAP-ACTION, but not @@ -230,16 +230,16 @@ method before explaining how it works. (nil (shift init)))) @endverbatim -Let's see what happens when the user types the key sequence <> <> << >>. -Upon <>, "A" is committed and the state shifts to [[non-upcase]]. -So, the next <> is handled in the [[non-upcase]] state. +Let's see what happens when the user types the key sequence \ \ \< \>. +Upon \, "A" is committed and the state shifts to [[non-upcase]]. +So, the next \ is handled in the [[non-upcase]] state. As it matches a rule in the map [[lower]], "b" is inserted in the preedit buffer and it is committed explicitly by the "commit" command in BRANCH-ACTION. After -that, the input method is still in the [[non-upcase]] state. So the next << >> +that, the input method is still in the [[non-upcase]] state. So the next \< \> is also handled in [[non-upcase]]. For this time, no rule in this state matches it. Thus the branch [[(nil (shift init))]] is selected and the -state is shifted to [[init]]. Please note that << >> is not yet +state is shifted to [[init]]. Please note that \< /> is not yet handled because the map [[nil]] does not consume any key event. So, the input method tries to handle it in the [[init]] state. Again no rule matches it. Therefore, that event is given back to the application @@ -248,7 +248,7 @@ program, which usually inserts a space for that. When you type "a quick blown fox" with this input method, you get "A Quick Blown Fox". OK, you find a typo in "blown", which should be "brown". To correct it, you probably move the cursor after "l" and type -<> and <>. However, if the current input method is still +\> and \>. However, if the current input method is still active, a capital "R" is inserted. It is not a sophisticated behavior. @@ -518,7 +518,7 @@ BRANCH-ACTIONs, the character is commited. This new input method always checks the character before the current position, so "A Quick Blown Fox" will be successfully fixed to "A -Quick Brown Fox" by the key sequence <> <>. +Quick Brown Fox" by the key sequence \> \>. */