		     tk4.xjp と tk8.0jp の非互換

						m-hirano@sra.co.jp

  tk8.0 から、Tk のフォントメカニズムが大幅に変更されました。その一つ
として、named font の採用が挙げられます。tk8.0jp では、この named font 
を拡張し、latin フォントと漢字フォントを組み合わせた named font, すな
わちコンパウンドフォントとして、単一のフォントのように扱うことにしまし
た(コンパウンドフォントのアナロジーは PostScript での複合フォントから
拝借しました)。

  したがって、tk4.xjp で各ウィジェットに用意されていた -kanjifont オプ
ションは、tk8.0jp では実装されていません。この実装による利点を以下に挙
げます。

	1. 現状、単一のフォント内に latin 文字、漢字が存在していないの
	   は、Tk のサポートするプラットフォームでは X のみである。
	   Windows, Mac とのスクリプトレベルでの互換を容易にするには、
	   -font オプションのみで漢字、latin 文字を表示できるフォント
	   が指定できる方が便利である。

	2. tk8.0 に元来実装されている、動的なフォント属性の変更の面か
	   ら見ても、漢字、latin 文字それぞれのフォント属性を逐一変更
	   するより、一括して行えた方が便利である。

	3. 各ウィジェットの日本語対応のための変更点が半減する。これは 
	   Tix など、その他の高機能なウィジェットセットを日本語化する
	   時に大変有利。

  反面、tk4.xjp との互換性が全くないという大きな欠点があります。

  また、漢字変換プロトコルとして、kinput2 プロトコルの他に XIM プロト
コルを限定的にサポートしました。

  このドキュメントは、拡張された named font の扱い方、tk4.xjp のスクリ
プトからの移行、漢字変換プロトコルのユーザカスタマイズについて解説する
ものです。特に font コマンドに関して、読者がその使用方法について充分理
解していることを要求しています。

1.	font コマンドの拡張

1.1.	-charset オプション

  tk8.0 オリジナルの font コマンドは、charset が iso8859 のものしか、
文字を表示する為のフォントとみなしませんでした(iso8859 以外はいわゆる
記号フォントとみなす)。また、font create コマンドにも charset をオプショ
ンとして渡す仕掛けがないため、X の環境でファミリ名を "fixed" とした場
合には、k14 等の漢字フォントを指しているのか a14 等の latin フォントを
指しているのか区別できません。そこで、font コマンドのオプションに 
-charset を追加しました。

  漢字フォントで named font を生成したい場合、常に -charset
jisx0208.1983 を付けます。例えば、

	font create @kanji -family fixed -charset jisx0208.1983 -size 13

  とすれば、X の環境ならば k14 を実体とする @kanji という名前の named
font が生成できます。-charset オプションを指定しなかった場合はオリジナ
ル tk8.0 と同様に動きます。


1.2.	-compound オプション

1.2.1.	コンパウンドフォントの生成

  font create コマンドに -compound オプションを指定することで、コンパ
ウンドフォントを生成します。コンパウンドフォントは常に named font とし
て生成されます。

	・漢字を k14 で、latin文字を a14 で表示するためのコンパウンド
	  フォントを SmallFont という名前で作成する

		font create SmallFont -compound { a14 k14 }

  -compound オプションへの引数には、

	{latinフォント 漢字フォント}

  のリストを指定します(順不動)。このリストに指定されたフォントの対は、
生成されるコンパウンドフォントの「ディセンダントフォント」と呼ばれます。
ディセンダントフォントとしてコンパウンドフォントを指定するとエラーにな
ります。ディセンダントフォントになり得るのは、

	・コンパウンドフォントでない named font.
	・ネイティブフォント

  です。

  生成されたコンパウンドフォントは、通常のフォント同様、tk で -font オ
プションが使える場面なら何時でも使用できます。

  font create コマンドのオプションとして使用する場合の -compound オプ
ションは、必ず

	font create ?name? -commpound {list}

  の順序で使われなければなりません。

	font create -compound {a14 k14} -size 15

  もしくは

	font create fooFont -compound {a14 k14} -size 15 

  は正しいですが、

	font create -size 15 -compound {a14 k14} 

  や、

	font create fooFont -size 15 -compound {a14 k14} 

  は間違いです。エラーにはなりませんが、機能しません。


1.2.2.	コンパウンドフォントの属性取得

  -compound オプションは、属性参照モードで使用する場合にのみ、font
configure, font cget コマンドへのオプションとしても使えます。

  今、@normal という named font が、

	font create @normal -famiy times -slant italic \
		-weight bold -size 15

  によって、また、@comp というコンパウンドフォントが、

	font create @comp -compound { @normal kanji16 }

  のように生成されているとします。

  ここで、

	font conf @normal

  を実行すると、

	-family times -size 15 -weight bold -slant italic -underline 0 \
	-overstrike 0 -charset {} -pointadjust 0 -compound {}

  が返って来ます。

	font conf @comp

  を実行すると、

	-family times:fixed -size 15 -weight normal -slant roman \
	-underline 0 -overstrike 0 -charset iso8859:jisx0208.1983 \
	-pointadjust 1.000000 -compound {{@normal} {kanji16}}

  が返って来ます。-pointadjust オプションは、ディセンダントフォントの
ポイントサイズ比率を表します(分母が漢字フォントのポイントサイズ)。

  font configure コマンドを使って、通常の named font をコンパウンドフォ
ントにしたり、コンパウンドフォントのディセンダントフォントを変更するこ
とは出来ません。


1.3.	-copy オプション

  ネイティブフォント名を利用して named font を生成する際に font create 
コマンドのオプションとして使用します。

  コンパウンドフォントでない named font を作る時、tk8.0 の仕様では 
-family オプションを指定して font create コマンドを呼ぶしか手段がありま
せんでした。

  わざわざ k14 の named font を作るのに

	font create @kanji -family fixed -charset jisx0208.1983 -size 13

  と書くのは繁雑なので、

	font create @kanji -copy k14

  と横着をするために用意したオプションです。


1.4.	failsafe コマンド

  ここまでの説明で、

	label .l -font \
	    -adobe-courier-bold-o-normal--14-140-75-75-m-90-iso8859-1

  のような、スクリプト中にコンパウンドフォント以外のフォントがエンベデッ
ドに指定されている場合などに、tk8.0jp ではまともに日本語が表示できない
んじゃないか？ とお気づきになられた方がいらっしゃると思います。で、最
初の実装では、その通りでした ^^;

  これでは tk4.xjp とあまりに互換性がないし、特に海外から持って来た Tk 
スクリプトを簡単に使用することができなくなります。

  と、このような御指摘をうけ、もしウィジェットに指定されたフォントで日
本語表示が出来ないと判った場合に使用されるフェイルセーフのためのフォン
トを指定する機能を用意しました。それがこの failsafe コマンドです。

  例えば、

	font failsafe k14

  をスクリプトの最初で実行しておけば、各ウィジェットで日本語表示が正常
に行えるフォントが指定されてなかった場合のみ、日本語の表示は k14 フォ
ントで行われます。

  faisafe コマンドの引数にはネイティブフォントのみが指定できます。
また、Latin フォントも指定でき、

	font failsafe 8x16
	label .l -font kanji16 -text \
		"これも正しく表示されます。This also works."

  のようなスクリプトがあっても問題ありません。

	font failsafe ""

  を実行すると、フェイルセーフフォントが NULL になり、フェイルセーフ機
能が効かなくなります。

  現状 UNIX 版では tkUnixInit.c のなかで、k14 をフェイルセーフフォント
として指定してあります。


1.5.	コンパウンドフォントの属性の動的変更

  前述のように、コンパウンドフォントは named font の一種です。通常の 
named font 同様、動的に属性を変更できます。変更できる属性は、アンダー
ライン、オーバーストライク、サイズ、ポイントサイズ比率の 4 つです。

  Tcl/Tk 8.0.5jp1.5fix1 より、コンパウンドフォントの属性の動的変更によ
り、ディセンダントフォントが影響を受けることは無くなりました。


1.5.1.	サイズの変更

	font conf @comp -size 23

  のようにして、コンパウンドフォントの大きさを変更した場合、@comp を参
照している全てのウィジェットが影響を受けます。前述のように、@comp のディ
センダントフォントは実際にサイズ変更されません。

＃ Tcl/Tk 8.0.5jp1.5 までは、ディセンダントフォントも実際にサイズが変
＃ 更されました。なぜこのような仕様だったかというと、named font がそも
＃ そも「名前参照」なオブジェクトであるため、named font を参照している 
＃ named font であるコンパウンドフォントもそれに従うべきだと考えたから
＃ です。が、あまりに実用的でないため、また、アンダーライン、オーバー
＃ ストライクの変更はディセンダントフォントに影響しない、という仕様と
＃ 相反するので、この仕様は廃止しました。Tcl/Tk 8.0.5jp1.5 までの仕
＃ 様を利用して、「故意に、ディセンダントフォント自身の大きさをコンパ
＃ ウンドフォントの大きさを変える事で行っている」ようなスクリプトは、
＃ 期待された動きをしないことになります。逆に、これまで、このドキュメ
＃ ントでは勧めていなかった、「ネイティブフォントを直接ディセンダント
＃ フォントに指定してコンパウンドフォントを作る」という手法には、何の
＃ 問題も無くなりました。


1.5.2.	ポイントサイズ比率の変更

	font conf -pointadjust 0.5

  のようにして、漢字ディセンダフォントに対する ascii ディセンダフォン
トのポイントサイズ比率を変更できます。もし、@comp のディセンダントフォ
ントが

	{a14 k14}

  であった場合に上記の 0.5 を指定すると、@comp を使用している全ウィジェッ
トで ascii 文字を表示する場合にはファミリが fixed でポイントサイズが 7
(k14 のポイントサイズは 13. 0.5 を掛けて四捨五入すると 7) のフォントが
使われる事になります。当然 1.0 以上の値も指定できます。

  ディセンダフォントのサイズが変更された場合に、コンパウンドフォントの
ポイントサイズ比率が変更される事はありません。ただし、実際の表示は、変
更されたサイズで行われます。要するに、コンパウンドフォントのポイントサ
イズ比率は、そのコンパウンドフォントの生成された時の比率、もしくは
-pointadjust オプションで指定された値を常に保つということです。

  もし、ディセンダントフォントのサイズを変更し、なおかつ、コンパウンド
フォントのポイントサイズ比率も変更したい場合、スクリプト内でディセンダ
ントフォントのサイズを変更後、実際のサイズを font actual コマンド等で
取得し、漢字フォントのサイズで ascii フォントのサイズを割算したものを、
コンパウンドフォントのポイントサイズ比率とすれば良いでしょう。


1.5.3.	アンダーライン、オーバーストライク

  コンパウンドフォントのアンダーライン、オーバーストライクの属性を変化
させてもディセンダントフォントには影響しません。


1.6.	各ウィジェットのデフォルトフォント

  tk8.0jp の実装では各ウィジェットのデフォルトフォントは全てコンパウン
ドフォントになっています。デフォルトフォントには以下のものがあります。

	Mincho:Helvetica-12
	Mincho:Helvetica-Bold-12
	Mincho:Courier-12

  これらのフォントの属性を変化させると、Tk アプリケーション全体に影響
します。この事をうまく使えば、これらのデフォルトのコンパウンドフォント
の再定義を行う事で Tk アプリケーション全体のフォントを容易に変更出来ま
す。


1.7.	移行作業

  tk4.xjp スクリプトからの移行は、基本的に、全ての -kanjifont オプショ
ンを削除し、-font オプションで指定しているフォントを適切に定義したコン
パウンドフォントで置き換える、もしくはただ単に -kanjifont オプションを
削除するだけで問題ありません。

  text, entry 以外のウィジェットに、bind コマンドで直接 kinput2 とのセッ
ションを定義しているようなアプリケーションは、tk8.0jp の 
$tk_library/kinput.tcl を参照して修正して下さい。

海外の Tk スクリプトの日本語化に関しては、1.4. で述べた font failsafe 
コマンドをスクリプトの先頭に入れておくことで、少なくとも tk4.xjp で当
該スクリプトを全く変更しないで実行させた場合と同等の日本語表示が行われ
ます。


1.8.	サンプル

  以下に簡単なサンプルを挙げます。

---------------------------------------------------------------------
	# 16ドットの courier と kanji16 をコンパウンドフォントにする。
	font create @ascii -copy \
		-adobe-courier-medium-r-normal--16-*-*-*-*-*-iso8859-1
	font create @kanji -copy kanji16
	font create @cFont -compound {@ascii @kanji}

	# @cFont を使った label を作る。
	pack [ label .l -text "123. テスト。321." -font @cFont ]
	
	# @cFont の大きさを 23 ポイントにし、アンダーラインを付ける。
	font conf @cFont -size 23 -underline 1
---------------------------------------------------------------------


1.9.	X リソースデータベースの扱い

  -kanjifont オプションが各ウィジェットから無くなったので、tk4.xjp で
使用できた、

	tkapp*kanjifont:	k14

  のような X リソースデータベースの記述は tk8.0jp では参照されません。
そのかわり、tkDefineFont, tkDefaultFont のリソースが使用出来ます。

  tkDefineFont リソースは X リソースデータベース内でコンパウンドフォン
トを定義するためのリソースです。

	*tkDefineFont:	small {a14 k14}, medium {8x16 kanji16}

  のように定義すると、全ての tk8.0jp アプリケーションの起動時に、
small, medium のコンパウンドフォントが生成されます。

  tkDefaultFont リソースは tk8.0jp アプリケーションで使用されるフォン
トを指定するためのリソースです。

	*tkDefaultFont:	small

  のように定義すると、全ての tk8.0jp アプリケーションの各ウィジェット
の default font が small になります。
  tkDefaultFont で指定したフォントがコンパウンドフォントでない場合には、
1.4. で述べたフェイルセーフフォントの機構が働くことになります。


  tkDefineFont, tkDefaultFont とも、クラス指定、ウィジェットインスタン
ス名指定には意味がありません。

	*tkDefineFont
	tkapp*tkDefineFont
	*tkDefaultFont
	tkapp*tkDefaultFont

  の形式でしか指定できないということです。


2.	XIM プロトコルへの対応

2.1	漢字変換プロトコルの指定

  環境変数、および X リソースデータベースのカスタマイズにより、漢字変
換プロトコルを kinput2, XIM の二つのうちから一つだけ選択出来るようにし
ました。同時に使うことは禁止してあります。

  環境変数 TK_KCPROTO を kinput2 にすると、kinput2 プロトコルが使われ
ます。xim にすると XIM プロトコルが使用されます。

  環境変数 TK_KCPROTO が設定されてない場合、X リソースデータベースから、
tkKanjiConversionProtocol リソースを検索します。
tkKanjiConversionProtocol リソースは、

	*tkKanjiConversionProtocol:		xim
	tkApp*tkKanjiConversionProtocol:	kinput2

  の形で使用でき、前者は Tk8.0jp で書かれたスクリプトの default、後者
は tkApp という任意のアプリケーションで使用されます。指定する値は、
TK_KCPROTO と同様です。

  もし、TK_KCPROTO も tkKanjiConversionProtocol も両方指定されない場合、
環境変数 XMODIFIERS が設定されていれば XIM プロトコルが使われます。
XMODFIERS も指定されていない場合、下位互換のために kinput2 プロトコル
が選択されます。

  以下に、任意の Tk スクリプト tkApp で使われる漢字変換プロトコルの選
択のされ方を、環境変数、X リソースデータベースの強さ順でまとめておきま
す。

	o まず環境変数 TK_KCPROTO が参照される。
	o 次に tkApp*tkKanjiConversionProtocol が参照される。
	o 次に *tkKanjiConversionProtocol が参照される。
	o 次に環境変数 XMODIFIERS の設定の有無が check され、設定され
	  ていると XIM が使われる。
	o 上記全てに該当しない場合、kinput2 プロトコルが使用される。

2.2.	各ウィジェット毎の変換スタイルの指定

  XIM プロトコルでは、変換サーバがサポートする、様々な変換スタイルを指
定できます。

  Tk8.0jp では、現状、変換スタイルとして、

	PreeditCallbacks StatusCallbacks
		…その場変換(on the spot)で、変換中の文字の描画からス
		  テータス領域の表示/非表示まで、全て Tk が行う。Tk が
		  何でも行うので、最も自由度の高い制御が行える :)。現
		  状、一番かっこいいスタイル :) 制御は全て Tk のスクリ
		  プトレベルで行うので、ユーザが制御スクリプト(コール
		  バックハンドラ)を記述する事で、漢字入力のフルカスタ
		  マイズが可能。ただし、XIM に関する Xlib レベルの知識
		  が若干必要 :)

	PreeditPosition StatusArea
		…その場変換(over the spot)で、変換用編集領域、ステー
		  タス領域ともに Tk が管理する。Tk8.0jp が kinput2 プ
		  ロトコルでセッションを張る時より、若干かっこいいこと
		  ができる :) 現状では、違いはあまり無い ^^;

	PreeditPosition StatusNothing
		…その場変換(over the spot)で、変換用編集領域は Tk が、
		  ステータス領域は変換サーバが管理する。Tk8.0jp が 
		  kinput2 プロトコルでセッションを張る時とほぼ互換。

	PreeditArea StatusArea
		…変換用編集領域、ステータス領域ともに Tk が管理する
		  (off the spot)。現状の実装では、ウィジェットの最下段
		  に変換用編集領域として 1 行分のエリアを確保し、その
		  行の一番左にステータス領域が表示されている。もう少し
		  頑張れば、疑似的にその場変換風にできる ^^;

	PreeditNothing StatusNothing
		…いわゆる root 変換。変換サーバが root ウインドウに変
		  換用ウィンドウを用意してくれる。Tk は文字列のやりと
		  り以外一切変換サーバと話さない。

  の 5 種類をサポートしています(これは kinput2 がサポートしている変換
スタイルほぼ全てです)。

  変換スタイルを指定するには、tkPreferredImStyle リソースを X リソース
データベースに指定します。例えば、Text ウィジェットの変換スタイルを指
定したい場合、

	*tkPreferredImStyle(Text): {PreeditPosition StatusArea} \
		{PreeditPosition StatusNothing}

などとしておきます。もし変換サーバが

	{PreeditPosition StatusArea} {PreeditPosition StatusNothing}

  の両方をサポートしていれば、tkPrefferdImStyle で先に指定された 
{PreeditPosition StatusArea} が使用されます。もし変換サーバが 

	{PreeditPosition StatusNothing}

  しかサポートしていない場合、{PreeditPosition StatusNothing} が使用さ
れることになります。tkPreferredImStyle で指定したスタイルを全く変換サー
バがサポートしていなかった場合、変換は全く行えません。

  tkPreferredImStyle の () の中には、スタイルを指定したい Tk のウィジェッ
トクラスを指定します。もし Entry ウィジェットの変換スタイルを指定する
のであれば、

	*tkPreferredImStyle(Entry): {PreeditPosition StatusNothing} \
		{PreeditNothing StatusNothing}

  のように指定すれば OK です。ウィジェットインスタンス指定は現状できま
せん。

  tkKanjiConversionProtocol リソースと同様に、tkPreferredImStyle リソー
スは任意の Tk スクリプト tkApp 毎に指定することももちろん可能です。

	tkApp*tkPreferredImStyle(Entry): {PreeditPosition StatusNothing} \
		{PreeditNothing StatusNothing}

  のように書くと、tkApp の Entry ウィジェットの変換スタイルが指定でき
ます。

2.3.	imconfigure コマンドについて

  XIM プロトコルに対応するために、Tk8.0 に新たに imconfigure コマンド
を追加しました。imconfigure コマンドについて少し説明しておきます。

Syntax:
	imconfigure path ?option args? ?option args? ...

option には、

	-status
	-supportedStyle
	-style
	-spot
	-preeditArea
	-statusArea
	-preferredStatusArea
	-font
	-foreground
	-backgrpund
	-callback

  が指定できます。option が全く指定されて無い場合、path の現在の状態を
全て返します。例えば、

-status started -supportedStyle { \
{PreeditPosition StatusArea} {PreeditPosition StatusNothing} \
{PreeditArea StatusArea} {PreeditCallbacks StatusCallbacks} \
{PreeditCallbacks StatusNothing} {PreeditNothing StatusNothing}} \
-style {PreeditCallbacks StatusCallbacks} -spot {} -preeditArea {} \
-statusArea {} -preferredStatusArea {} -font {} -foreground {} \
-background {} -callback tkTextIMCallbackProc 

  のような文字列が返って来ます。


o -status (引数なし:情報取得のみ)

  変換サーバとセッションを張る為のコンテキスト(AKA XIC. See also X11
documents)が生成されているか否かを返します。コンテキストを生成するには、-
style オプション(およびそのスタイルの初期化に必ず必要なその他のオプショ
ン)を指定して imconfigure コマンドを呼び出します。もし、コンテキストが
生成されていなかった場合、"never" が返ります。コンテキストが生成されて
いたら "started" が返ります。

o -supportedStyle (引数なし:情報取得のみ)

  変換サーバがサポートする変換スタイルのリストを返します。当然書換えら
れません。

o -style {style}

  {style} に変換スタイルを指定します。指定できるのは、-supportedStyle 
オプションで返って来たリストのうちの一つです。{style} に何も指定しない
場合、現在の変換スタイルを返します。-status オプションが "never" を返
す状態では、-style オプションは {} を返します。
  もし、-status オプションが "started" を返す状態で -style オプション
に違う値を指定して imconfigure コマンドを呼び出した場合、現在のコンテ
キストは破壊され、新しいコンテキストが再生成されます。変換スタイルを動
的に変えたい場合にのみ、このような使い方をすべきです。

o -spot {x y}

  変換用編集領域内での編集位置を {x y} にそれぞれ X 座標、Y 座標で指定
します(変換用編集領域の x, y を原点とする)。-style オプションで指定し
た変換スタイルに、PreeditArea, PreeditPosition のどちらかが指定されて
ないと無意味、もしくは imconfigure コマンドが失敗します。{x y} を指定
しない場合、現在の編集位置が返ります。

o -preeditArea {x y w h}

  変換用編集領域のジオメトリを {x y w h} にそれぞれ X 座標、Y 座標、幅、
高さを指定します(path で指定したウィジェットの x, y を原点とする)。-
style オプションで指定した変換スタイルに PreeditArea, PreeditPosition 
のどちらかが指定されてないと無意味、もしくは imconfigure コマンドが失
敗します。{x y w h} を指定しない場合、現在の変換用編集領域のジオメトリ
が返ります。

o -statusArea {x y w h}

  ステータス領域のジオメトリを {x y w h} にそれぞれ X 座標、Y 座標、幅、
高さを指定します(path で指定したウィジェットの x, y を原点とする。-
style オプションで指定した変換スタイルに StatusArea が指定されてないと
無意味、もしくは imconfigure コマンドが失敗します。{x y w h} を指定し
ない場合、現在のステータス領域のジオメトリが返ります。


o -preferredStatusArea (引数なし:情報取得のみ)

  変換サーバが推薦する、ステータス領域のジオメトリを返します。-style 
オプションで指定した変換スタイルに StatusArea が指定されてないと無意味、
もしくは imconfigure コマンドが失敗します。

o -font font

  変換用編集領域、ステータス領域での文字の表示に使用されるフォントを 
font に指定します。font を指定しない場合、現在のフォントが返ります。

o -foreground color

  変換用編集領域、ステータス領域の foreground color を color に指定し
ます。color を指定しない場合、現在の foreground color が戻ります。

o -background color

  変換用編集領域、ステータス領域の background color を color に指定し
ます。color を指定しない場合、現在の background color が戻ります。

o -callback handler

  on the spot スタイルを使用する場合のコールバックハンドラを指定します。
handler を指定しない場合、現在のコールバックハンドラが戻ります。
  handler は実際に実行される時に、4 つの引数が追加されて呼ばれます。


2.3.1	imconfigure コマンドの使用例

  $tk_library/xim.tcl を参照してください。tkConfigIm プロシジャが肝で
す。

  また、on the spot モードでの -callback オプションで指定するコールバッ
クハンドラの詳細のドキュメントも用意されていません ^^; 現在の default 
である、$tk_library/xim.tcl 内の tkTextIMCallbackProc プロシジャを参考
にして下さい。また、tkImPriv(debug) という変数を 1 にすると、
tkTextIMCallbackProc プロシジャが呼ばれた時に、その引数が標準エラー出
力に表示されるようになります。各引数は基本的に、
XIMPreeditCallbacks|XIMStatusCallbacks を使用した場合に使用される、
XIMCallback のコールバック引数を文字列に直して渡しているだけです。とい
うわけで、自分でコールバックハンドラを書きたい人は、X11 のドキュメント
の、13.5.7.4 〜 13.5.7.7 を参照して下さい _o_ ^^;


2.4.	XIM 使用上の制限

2.4.1.	変換文字列長は 1024 バイトである

  現在の最新版と思われる X11R6.3, XFree86 3.3.3.1 でも、
XmbLookupString() にバグがあり、変換サーバとの通信において、可変長バッ
ファが使えません。Tk8.0jp に、XmbLookupString() のみを fix したものを
同梱することも考えましたが、各バージョンの Xlib と整合をとるのがめんど
くさくなったので ^^; 止めてます(XFree86 3.3.[12] ではとりあえず可変長
バッファが使えるようにしたものはある)。
  で、現状、実用上困らない範囲として、固定長バッファをスタック内に 
1024 バイト確保しています(SIJS, EUC で喋ると 512 文字)。変換結果がこれ
より長くなると、1024 バイト以降は捨てられます。

2.4.2.	R5 ベースの Xlib で動くか？

  動くはずです。ただ、私としては、XFree86 なり X11R6.3 なり X11R6.4 な
りをお使いになることを奨めます :)

  現状、SunOS 5.x i386 の xlib (/usr/openwin/lib/libX11.*) で動く事を
確認しています。ただし、SunOS 5.x 付属の XIM プロトコルベースの変換サー
バである htt との通信は、SunOS 5.x 付属の X サーバが、tk が 
XSetICValues() を発行した時点で落ちるため、未確認です。htt を SunOS
5.x 付属の X サーバ以外で動かすことが容易であれば、テストも可能なので
すが、これがなかなか成功してくれないので困っています。

2.4.3.	on the spot モードの実現のための dirty hack について

  on the spot スタイルの制御を Tcl のスクリプトレベルで実現するために、
ちょっと危ない hack をしています(Display 構造体のメンバを参照している)。
このため、動かない、core を吐く環境があるかも知れません。その場合、素
直に諦めるか、自分で Display.im_filters のオフセットを探して下さい _o_

  と、このような理由で、on the spot モードはデフォルトでは使えないよう
にしてあります。3.1 で説明してある、configure の --enable-onTheSpot を
付けて configure をかけた場合のみ可能になります。


3.	その他

3.1.	configure の変更

  XIM プロトコルに対応するためには、X の設定を正確に知る必要があります。
特に -DX_LOCALE, -DX_WCHAR の有無が大変重要になります。そこで、
configure スクリプトで imake 環境を check して、imake で使用される C 
プリプロセッサオプションを参照するように変更しました。これに伴い、これ
までの Makefile.in を直接編集することでコンパイル環境を変更する方式か
ら configure に --enable-*/--disable-* オプションを指定する方式に変更
しました。使用可能なオプションは、configure --help で表示されます。以
下に日本語関係のオプションを挙げておきます。

	--enable-kanji		日本語化機能を使用可能にする(デフォルト)。

	--enable-kinput2 	kinput2 プロトコルを使用可能にする(デフォ
				ルト)。
	
	--enable-ximImprove	まともな XIM プロトコルサポートを使用可能
				にする(デフォルト)。

	--enable-xlfdCheck	間違った XLFD 名のチェック機能を有効にする
				(デフォルト)。3.3 参照。

	--enable-xlibHack	XFree86 3.3.2 を使っている場合にのみ指定で
				きます。指定すると、XListFonts(),
				XLoadQueryFont() を Tk の独自ルーチンに置
				き換える事で、

				・ListFonts protocol の発行をなるべく
				抑制する。Tk の立ち上がり時にその X サー
				バで使用可能なフォント全てを調べ、以降
				まずそのリストを検索することで代用。も
				し見つからなかった場合(Scalable font 
				等)にのみ実際に ListFonts を発行する。

				・同じ名前(正式 XLFD 名、アリアス全て
				を含む)を持つフォントは 1 度しか 
				LoadFont されなくなる。

				・XCreateFontSet() が上記 2 つの独自ルー
				チンを参照するようになる。

	--enable-onTheSpot	XIM の on the spot スタイルのサポートを可
				能にします。デフォルトでは可能になりま
				せん。


  --disable-kanji を指定した場合の tk8.0jp の動作は保証しません :)。

3.2.	kinput2 プロトコルでの変換開始キーの指定

  これまでやろうやろうと思っていて全然やってなかったのですが ^^;, XIM 
プロトコルで変換スタイルを指定できるようにしたついでに、kinput2 プロト
コル使用時の変換開始キー、各ウィジェットの変換スタイルを X リソースデー
タベースで指定できるようにしました。

3.2.1	変換開始キーの指定

  tkKinputStartKeys リソースを、例えば以下のように指定します。

	*tkKinputStartKeys:	Control-backslash \
				<Control-Kanji>

  キーシーケンスは Tk の bind コマンドに使用されるものです。<> で括ら
れていない場合、自動的に <> で括られます。くどいですが、任意の Tk スク
リプト tkApp 毎に変換開始キーを指定するころも可能です。

3.2.2	各ウィジェットの変換スタイル

  tkKinputStyle リソースで指定します。

	*tkKinputStyle(Text):	over
	*tkKinputStyle(Entry):	root

  のように、() の中には Tk のウィジェットクラス(Text, Entry)を指定しま
す。値は over, root のどちらかで、over がその場変換、root が root 変換
を示します。


3.3.	X-TT 拡張された X サーバへの対応

  X-TT サーバ(X TrueType server。
http://cclub.cc.tut.ac.jp/~Ego/unix/xtt.html参照)の xtt05-fix1 を使用
している場合(未確認ですが、これより古いバージョンにも多分該当します)、
XListFonts() して XGetAtomName() することで得られる XLFD のフォーマッ
トが間違っており、TrueType フォントを tk8.0 上で named font として使用
できませんでした(ネイティブフォントとして failsafe フォントなどに使用
することは可能)。

# xtt06 がリリースされました。が、まだ確かめてません ^^;

  たかが XLFD の間違いくらいで使えないのは大変悲しいし、同じようにかな
り厳しく XLFD のパーズを行っていると思われる Netscape では問題無く使え
ているのが比較対象にされてシャクなので ^^;、日本語化には基本的に無関係
な XLFD のパーズルーチンに手を入れました。ただし、X-TT サーバが対応し
た場合、および X-TT でない X サーバを使っている場合には単なる冗長な 
XLFD チェックルーチンにしかなりませんが、現状これをデフォルトにしてあ
ります。これを止めたい場合、--disabel-xlfdCheck を指定して configure 
を実行すれば良いです。

  tk4.xjp との非互換というわけではありませんが、tk4.xjp では問題無く 
X-TT サーバ上で TrueType が使えるのでここに記しました。


3.4	canvas ウィジェットでの PostScript 出力時のフォント指定

  canvas ウィジェットの postscript コマンドを使用する際、-fontmap オプ
ションを指定することで canvas ウィジェット内で使用されているフォント名
と PostScript で使用するフォント名を対応付けることが出来ます。

  tk8.0jp では -fontmap オプションに渡す配列のフォーマットが拡張されて
おり、tk8.0 で

	set fontMap(myFont) {PSFont pointSize}

  と書くところを、

	set fontMap(myFont) {{PSFont PSKanjiFont} pointSize}

  のように書く事で、canvas ウィジェット内で myFont というフォントで描
画された文字列を PostScript 出力する時には、ascii 文字は PSFont、漢字
は PSKanjiFont で出力する、という指定が可能になっています。pointSize 
には PostScript でのポイント数を指定します。もし myFont が 12 ポイント
であれば、pointSize にも 12 を指定するのが良いでしょう。

  -fontmap オプションを指定する場合、通常後者のフォーマットで構成され
た配列を渡す事をお推めします。

  tk8.0jp で前者の指定をした場合、myFont の形式に依存して PostScript 
フォントが決定されます。以下に一応それをまとめます。

	o myFont が ascii フォントだった場合、ascii 文字の出力に 
	  PSFont が使用され、漢字の出力は常に Ryumin-Light-EUC-H が使
	  用される。

	o myFont が漢字フォントだった場合、ascii 文字の出力には常に 
	  Courier が使用され、漢字の出力に PSFont が使用される。もし 
	  PSFont が ascii 文字分のグリフしか持たないフォントであった場
	  合、漢字が含まれた文字列は正常に印刷されない。

	o myFont がコンパウンドフォントであった場合、常にエラーとなる。

  -fontmap オプションを指定しない場合、canvas ウィジェット内で myFont 
というフォントで描画された文字列を PostScript 出力する時には、ウィンド
ウへの描画同様、myFont の形式とファイルセーフフォントの指定に応じて 
PostScript フォントが決定されます。つまり、canvas ウィジェット内で正常
に ascii 文字と漢字が表示出来ているなら、少なくとも文字化けしないで印
刷できるということです。

  -fontmap オプションを指定しない場合、現状、UNIX 版では、漢字フォント
は常に Ryumin-Light-EUC-H を使用します。

  tk8.0jp は PostScript を常に EUC で出力します。したがって、漢字を表
示するための日本語フォントは、常に EUC フォントを選択する必要がありま
す。

  -fontmap オプションの使用例をあげておきます。この例は、canvas ウィジェッ
ト内の text を Helvetica-Bold と GothicBBB-Medium-EUC-H を使用して 
PostScript に落とします。

canvas .c
pack .c
set t [.c create text 100 100 -text "Helvetica とゴシックＢＢＢ"]
set f [.c itemcget $t -font]
set fontMap($f) {{Helvetica-Bold GothicBBB-Medium-EUC-H} 12}
set ps [.c postscript -fontmap fontMap]


3.5.	selection, clipboard コマンドでの target Atom と type Atom

3.5.1.	selection の取得

  Tcl/Tk 8.0.4jp1.3 までは、tk4.xjp 同様、Tk が他のクライアントに 
SelectionRequest を送る場合(早い話が Cut & Paste することで、Tk 的には、
selection get コマンドを使用)、デフォルトの target Atom (selection get 
コマンドの -type のオプションに指定する文字列)に COMPOUND_TEXT を使用
していました。また、COMPOUND_TEXT でのセレクション取得に失敗しても、
target Atom の設定を変えて再要求することをしませんでした。このため、
target Atom として STRING しか処理できないクライアントからは Cut &
Paste で Tk 側に値をもらって来る事が簡単に出来ませんでした(自分で Text 
ウィジェットのキーバインドを変え、失敗したら STRING Atom で再要求、等
する必要があった)。

  Tcl/Tk 8.0.4jp1.4a から、この仕様を変え、デフォルトで、

	a. 最初は TEXT で要求。
	b. a. が失敗したら COMPOUND_TEXT で要求。
	c. b. も失敗したら STRING で要求。
	d. 失敗。

  のようにしました。当然ですが、selection get コマンドの -type オプショ
ンは今まで通り使用できます。

3.5.2.	clipboard append コマンドによる selection の設定

  3.5.1. の逆に、clipboard append コマンドでクリップボードに値を設定す
る場合も、Tcl/Tk 8.0.4jp1.4a から以前の仕様と変えました。以前の 
clipboard append コマンドのデフォルト(-format, -type オプションを指定
しない場合)では、target Atom (-type オプションの値)として 
COMPOUND_TEXT, type Atom (-format オプションの値)として COMPOUND_TEXT 
を使用していました。この場合、COMPOUND_TEXT で要求してくれるクライアン
ト以外にはクリップボードの内容を渡せませんでした(当然 -format, -type 
オプションを使用すれば可能である)。

  Tcl/Tk 8.0.4jp1.4a からは、デフォルトで、

	a. 足したい内容に漢字が含まれる場合

		i. 	target:TEXT		type:COMPOUND_TEXT
		ii. 	target:COMPOUND_TEXT	type:COMPOUND_TEXT
		iii.	target:STRING		type:STRING

	b. 足したい内容が全部 ascii 文字の場合

		i.	target:TEXT		type:STRING
		ii.	target:STRING		type:STRING

  のように、複数タイプの要求に答えられるようにしました。a.iii. の場合、
クリップボード内の漢字コードは Tcl の internalCode になっています。し
たがって、a. の場合に STRING target で要求された時は、要求したクライア
ントも internalCode の漢字コードを知っていなければ文字化けすることにな
ります。

  ちなみに、entry, text ウィジェット等の、最初から文字列しか扱わないと
判っているウィジェットの Cut & Paste では、これと同様な機能が以前から、
そのウィジェット自身の機能として実現されていました(要するに、selection 
コマンドや clipboard コマンドを使って selection handler 等をスクリプト
レベルで実装しなくても良い、ということ)。それを意味的に clipboard コマ
ンドのデフォルトにも適用したわけです。


4.	Text ウィジェットでの禁則処理

  tk4.xjp での禁則処理は、フォント毎にハードコーディングされた禁則文字
テーブルを用いて禁則処理を行っていました。また、tk8.0.4jp 1.4 までの 
tk8.0jp は、禁則処理を完全に無視してました ^^; (フォント毎に禁則文字テー
ブルを作ってはいたけど、誰も参照してなかった ^^;)

  tk8.0.5jp 1.5 より、日本語禁則処理のための kinsoku コマンドを導入し
ました。kinsoku コマンドを用いる事で、自由に行頭禁則文字、行末禁則文字
を指定できます。

4.1.	kinsoku コマンドの仕様

  kinsoku コマンドは、以下の書式で用います。

	kinsoku show|add|delete begin|end|both ?文字 文字 ...?

  kinsoku show コマンドは、現在の禁則文字データベースを表示するのに用
います。2 番目の引数には begin(行頭禁則), end(行末禁則), both(行頭行末
禁則) のいずれかを指定します。

  kinsoku add コマンドは、禁則文字データベースへの禁則文字の登録に使用
します。2 番目の引数には begin, end, both のいずれかを指定します。登
録する禁則文字は、ただ単に空白で区切って 1 個以上指定します。リストで
はありません。

  kinsoku delete コマンドは、禁則文字データベースから指定した禁則文字
を取り除くのに使用します。くどいですが 2 番目の引数には begin, end,
both のいずれかを指定します。取り除く禁則文字は、ただ単に空白で区切っ
て 1 個以上指定します。リストではありません。指定した禁則文字が、禁則
文字データベースにない場合、単に無視されます。

  例 1: '.', ',' を行頭禁則文字に設定。

	kinsoku add begin "." ","

  例 2: '＠' を行頭行末禁則文字に設定。

	kinsoku add both "＠"

		both の指定は、

			kinsoku add end ...
			kinsoku add begin ...

		を発行したのと等価。


  kinsoku コマンドで制御する禁則文字は、Text ウィジェットの、-wrap オ
プションが word の時にのみ作用します。また、禁則文字データベースは、プ
ロセスに一つです。Text ウィジェットの属性ではありません。

  また、禁則処理が働くのは、指定した禁則文字の「前後に」漢字キャラクタ
が存在する場合のみです。例えば、'.' が禁則文字データベースにあっても、


	a.aaaaa.dddd.ccccc

  のような文字列は英語として扱われ、日本語禁則処理の対象にはなりません。
そもそも英文には禁則文字の概念は必要なく、word wrap で片付くからです。
上記文字列は空白が全く含まれてないので、英文としては 1 単語として扱わ
れ、'.' が日本語禁則文字であっても処理の対象と見なさないからです。

  詰めによる禁則は行いません ^^; 全部次の行への追い出しです ^^;

  デフォルトの禁則文字の設定は、$tk_library/kinsoku.tcl で行われていま
す。現状以下の通りです。

行頭禁則:

	"!" ")" "," "." "?" "]" "、" "。" "？" "！" "）" "〕" "］"
	"」" "』" "】"

行末禁則:

	"(" "[" "（" "〔" "［" "「" "『" "【"


4.2.	$tk_library/kinsoku.tcl の編集時の注意

  通常、$tk_library/kinsoku.tcl を編集しなおさず、各スクリプト内で 
kinsoku コマンドを用いて禁則文字データベースを変更して欲しいのですが、
「どーしてもデフォルトの設定を変えたい」という方は、以下に注意して変更
してください。

  $tk_library/kinsoku.tcl は、JIS コードで書かれています。これは、立ち
上げ時に、どんな internal code でもコードの自動判別を成功させるためで
す。EUC や SJIS で書くと、コードの自動判別を誤る可能性があるので、故意
にこうしています。Windows など、ほぼ間違い無く SJIS が使われる環境では
SJIS で書いても良いかも知れませんが、UNIX のように個人の設定で立ち上げ
時の internal code が違うことが当り前の環境では、JIS で記述するように
してください。
