多言語ターミナルエミュレータ mlterm 2.2.0 リリース

kubota 曰く、 "漢字、タイ文字 (結合文字)、アラビア文字 (右→左・字形変化) など、意欲的な多言語サポートが特徴のターミナルエミュレータ、mlterm の新バージョンがリリースされた。

本バージョンではついに libind を使ったインド諸言語サポートが実装され、色モノ系機能についても、フォーカスを失ったときのフェードや、mlterm ウィンドウ内で走る設定プログラムや、テキストブラウザからの設定用 CGI が付属する、などの新機能がある。JIS ←→ Unicode 変換テーブルに CP932 を使うことで Windows 用 TrueType フォントが使いやすくなる、といった、痒いところにもばっちり手が届く (言い換えれば Unicode の尻拭い) 機能もある。

ただし、インド諸言語については、インド国内においても日本がかつてたどってきた「英語プラス一言語」の地域化によく似た状況にあるという印象で、それを「国際化・多言語化」とどううまくすりあわせていくか、というのは今後の課題と言えそうだ。

mlterm は、いま現在、ぼくの知る限り、世界中の最もたくさんの人たち (つまり、たくさんの言語や文字) が使えるターミナルエミュレータだ。こういったソフトウェアが模範となって、より多くのソフトウェアが多言語対応となり、ついにはフリーソフトウェアが「多言語対応」をいちいち謳うことが恥ずかしくなるくらいにまでなってほしいものだ。"

素晴らしい。

新機能だけじゃなくて

[kubota (64)]

2.2.0 の新機能だけじゃなくて、昔からある特筆すべき機能についても宣伝しておきます。

• 多くのエンコーディングに対応。ISO-2022-JP-2 とか Shift_JISX0213 とか GBK とか UHC とかのマイナー系エンコーディングや UTF-8 にも対応しています。
• 現在のロケールに従って、自動的にエンコーディングを選択します。世界中どこの人が使っても設定不要。
• 複数の XIM を切り替えて使用できます。たとえば、kinput2 と Ami [freebsd.org] と XCIN [linux.org.tw] を切り替えて使うことで日中韓混合文書の入力ができます。
• UTF-8 以外のエンコーディングの表示に Unicode フォントを使ったり、逆に、UTF-8 の表示に非 Unicode フォントを使ったりできます。
• Xft/freetype を使ったアンチエイリアス表示ができます。
• Unicode で同一のコードポイントを与えられる文字を同一視することで、より多くのセレクション (カットアンドペースト) を受け入れることができます。(オフにもできます。また、現在のエンコーディングが ISO-2022 準拠な場合には、ISO-2022 エスケープシーケンスを利用して無理やりもとの文字をペーストすることもできます)。

数ある機能のなかから、ぼくが特に重要だと思うのはこれくらいです。他にもいろいろありますので mlterm のウェブページ [sourceforge.net]を参照してください。

termの種類

[Nyan2 (2244)]

mltermですか。
これは聞いたこと無かったです。
お家に帰ったら早速試してみます。

でも、termって本当に種類が多いですよね。
今まで試したものは……
aterm,xterm,rxvt,kterm,gnome-terminal,powerterm,Eterm...

思いつくだけでもこんなに。
あとなにがありましたっけ。

# 日本産の某term、コンパイルが通らなくて諦めた経緯があります。
# あれ、なんて名前だったかなぁ。

結局、gnome-terminal に落ち着いているところが笑えます(笑
mltermはgnome-terminalに取って代われるか!?

Re:termの種類

[kusano (264)]

libzvt の置き換えになるようなものを作ったりできませんかね。 そこまでせんでも freedesktop.org の Standards [freedesktop.org]のうち、Session Management とか Window manager specification あたりに対応していると嬉しいかも。

Yudit

[kubota (64)]

mlterm は、いま現在、ぼくの知る限り、世界中の最もたくさんの人たち (つまり、たくさんの言語や文字) が使えるターミナルエミュレータだ。

じつは、ターミナルエミュレータだけじゃなくてフリーソフトウェア全体に話を広げると、Yudit [yudit.org] のほうがすこし上を行っていたりします。ハングル要素からの合成とかにも対応しているそうですし、アラビア語の字形変化なんかについても、mlterm に先行して 2001/12/14 [linux.org] に実装していました。インド諸語も 2002/1/27 [linux.org] ですし。(hanterm [freebsd.org] もハングル合成をサポートしているみたいなんですが、このページ、面白そうなのに韓国語が分からなくて...)

最新版は漢字の文字認識入力とかもあって面白いのですが、XIM については対応してくれるかどうか分かりません。XIM はロケール依存なのがネックになりそう [linux.org]。

ちなみにこの文字認識入力、書き順が正しく書けていないと認識してくれなくて、たとえば「右」と「左」を入力するのはけっこう大変ですよ。(正しい書き順を覚えていますか? ぼくは覚えていませんでした)

libime Re:Yudit

[tabatee (1637)]

修論執筆中の田畑@Project Hekeです
世界の入力システムを抽象化するライブラリlibime(仮)の プランを温めています。
エンコーディングやアプリケーションの機能をネゴシエーションしてからコンテキストを作成するインターフェイスやいくつかの言語のモジュールを書き出したところです。(修論で滞ってますが)

もうちょっと動くようになれば、mltermは実験用として大いに利用させていただく予定です。

hanterm

[Anonymous Coward]

お礼がおそくなりましたが、タレコミしていただいてありがとうございます
> kubota さん

ハングル(JOHAB)合成ですが、実装したいと思いつつ、根性なしで、
hanterm のソースちゃんと読んでないため、手がつけられていません。

今のところは、全部合成済みハングルに置換して表示してます。

# 英語のドキュメントがどこかに転がってないかなぁ....

JOHAB のフォントを見るかぎりでは、基本的には、規則的にならん
でるようですので、JOHAB のコードポイントをフォントのインデック
スに変換するコードを書くのはそれほど大変ではなさそうな気もしつつ、
今も JOHAB の需要があるのだろうか、と思って、あまりやる気がで
ないのが現状です。

どなたか、やっていただける方いませんか? :)

--- あらき

screen

[tottochan (6219)]

これ、screenを使っていてもShift+Priorなどで
ページアップ(画面のスクロール)ができるのですね。

ktermではこれができなかったので、とてもうれしいです。

# 多言語サポートとは関係ない話ですけど。

ところで

[Anonymous Coward]

いつも疑問なんですが、結合文字みたいなものをターミナルで使う場合って、
文字ピッチの問題をどうやって解決すればいいんでしょうか。
たとえば、英語端末では歴史的に固定ピッチフォントでないと困りますし、
日本語端末だと歴史的に漢字は ANK の倍の幅をもってないといろいろ困ったことになったりしますけど、
エスニックな文字ではその辺はどうなってるんでしょう？

前から多言語な端末作りたかったんですが、この辺で悩んでいつも作る気が失せてたんですよねぇ。
そういう制約を無視すれば、レイアウトエンジンのノウハウはあるので作るのは時間の問題なんですが、
こういう部分でポリシーフリーなメカニズムを提供する方法がどうしても思い浮かばず諦めています。

# えてして多言語化とはそういうものだから難しいんですよね。

Mule

[kubota (64)]

Mule は、昔から Devanagari (インドの主要な文字のひとつ) をサポートしています。それは固定幅カラムな実装なので、もしこれが普及していれば話は早かったのに、と思うのですが、なぜか、インド人自身に使われている話を聞きません。

じつは、台湾においても Mule は普及していない [srad.jp]という話を聞いたことがあります。そのために、Mule が XFree86 上の他のソフトウェアと Big5 な文字列をコピーアンドペーストでやりとりすることができないという問題も最近まで発見されませんでした。

Mule はすばらしいソフトウェアだとは思いますが、ある言語をサポートしても、そのネイティヴスピーカーによって使われなければ、ネイティヴスピーカーが出してきた、ネイティヴスピーカーにとってより使いやすいであろう技術体系のほうが生き残ることになり、最初のソフトウェアは風変わりな非標準的なソフトウェアという立場に立たされてしまうことになります。ネイティヴスピーカーにとってはそのほうがむしろいいのでしょうが、これからは、各国や各言語の要求や必要と、国際化の流れとのすりあわせをいかにするか、ということが大切になっていくと思っています。

ぼくは XFree86 i18n ML [xfree86.org] に参加してすでに 1 年以上になりますが、いろんな国や言語の人たちからのメールがやってきます。そういう人たちとのつながりを大切にすることで、いい技術なのに普及しない (じつは日本人だけが「いい技術」と思い込んでるだけなのかもしれない)、ということを避けるようにできればと思っています。

文字幅

[kubota (64)]

アルファベットの発音記号や、タイの母音の場合は、文字を合成しても文字幅そのものは変化しません。ですので、固定幅で十分対応できます。

問題はインドで、どうやらカラム幅を変えないとどうにもならないようです。それと、CJK における倍幅文字との整合性が、うまくいきません。

つまり、CJK における倍幅文字は、カラムの幅が倍になるのではなく、1 文字が 2 カラムを占有するという考え方です。したがって、カーソルが倍幅文字を横切るとき、2 カラム移動させることが必要です。ところが、インドの場合には、カラム幅そのものが可変 (整数倍にさえならない) という考え方です。

これがなかなかの難問で、それはそういうもんだから統一的な処理など最初から諦めろ、というのもひとつの解ですが、それがいやだとなったとき、CJK における倍幅文字の考え方をいまさら変えることなど考えられないですし、かといってインド人に「おまえたちがこちらに合わせろ」と言うこともできないですし。

Re:文字幅

[ntakahas (6453)]

つまり、CJK における倍幅文字は、カラムの幅が倍になるのではなく、1 文字が 2 カラムを占有するという考え方です。したがって、カーソルが倍幅文字を横切るとき、2 カラム移動させることが必要です。ところが、インドの場合には、カラム幅そのものが可変 (整数倍にさえならない) という考え方です。

この考え方をそのまま押し進め、「幅nピクセルのASCII文字はnカラム、幅2nピクセルの倍幅文字は2nカラムを占有する」と考えるのではだめなんでしょうか。そう考えれば文字幅が何ピクセルでも平気のような気がしますけど。

Re: ところで

[Dubhead (1033)]

mltermってプロポーショナルフォント対応なんですね。素晴らしい。

> 英語端末では歴史的に固定ピッチフォントでないと困りますし、

しばらく9termを使った経験からいうと、端末がプロポーショナルフォントでもあんまり困らないと思います。困るのはせいぜい、アスキーアートを見る時くらいじゃないでしょうか。

Re: ところで

[fgd (2415)]

個人的な経験では、ls -l で、とりあえず困ったな。

Re: ところで

[Dubhead (1033)]

おっと、そいつを忘れてました。あと ls -C も派手に崩れる。

Re: ところで

[nasb (3002)]

従来の文字ベースの桁揃えを忘れて、よりメタなタブベース(または項目ベース)の位置調節メソッドに移行する時期にきたのかも。

# で、タブの定義は? :-)

Re: ところで

[Jadawin (2174)]

いやいや、そんな所でとまっていては、TABLEタグだらけのウェブページと同じことになりかねん。すべてのコマンドがXMLを吐いて、コマンドごとにXSLTとCSS2で出力形式を指定できるようにせねば。
　
繁雑にはなるけど、パーズは楽になる、、、はず、、。
　
＃XMLの適用って、どんなデータまで妥当？

Re: ところで

[kusano (264)]

それって xmlterm [xmlterm.com] っぽいですな

Re: ところで

[Jadawin (2174)]

うーむ。本当にあったとは。
もしかして、端末がウェブを覗いて、直接flashやmp3を再生したりするんだろうか？
さらのその拡張でSVGtermとかもあったりするんだろうか？SMILtermなんてのもできるんだろうなぁ
　
＃世の中、恐いのぉ。わし、もう爺や。

スペースの次はタブ

[nasb (3002)]

世の中XMLワッショイだけれども、さすがに人間が書くものじゃない。たとえ ば JavaML [washington.edu] なんてものもあるけど、そのソースを手で こう [washington.edu]書くなんて気が狂うでしょ。

なんだかんだ言って、初めてスクリーンエディタができた頃からごく最近まで、 アルファベットと数字だけ使えればよかった時代は幸運だったし幸福だったと 思う。全ての文字が同じ大きさだったおかげで、印字内容とレイアウトという 異なる概念がでそのまんま具現できたから。そのおかげでテキストエディタっ てのは最初の時代から今まで使えるずっと便利なWYSWYG環境だったわけで。

しかし、世界は広くてキャラクタベースではどうにも表示できない 文字もある。既にマシン性能の方はピクセルベースでも十分なんだけど、かと いって文字を表示するのに「えっと、この文字はこのエンコーディングで、このフォ ントを使っていてるから、このウィンドウシステムだと横148 ピクセル食うか ら、次の項目までは152ピクセル進めて…」なんていちいちやりたくない。 「あ～あ、スペースで位置合わせていた頃は幸せだったな～」と。

さすがに、ピクセル数えて…なんてことする必要はほとんど無いし、XMLを使って 記述量を絞ったままそれなりにレンダリングさせるのでいいんだけど、でも、 最初に挙げたように、XMLですら手書きはしたくないんですよ。テキストエディ タでスペースバーを叩いてレイアウト決めてたのに比べればどれだけ大変か。

で、ここでやっと本題なんですが、実は可変ピクセル文字環境でも、 TSV (tab-separated values)のようにタブで項目を区切ってやって、cursesみたいな感じ(エスケープシーケンスみたいなもっと低レベルなものでいいかも)で自動的なテキストレイアウタを作って統一してやれば、古式ゆかしい「スペース文字でレイ アウト」という流儀にちょっと毛が生えたぐらいの手間で同じぐらいの気軽さ で世界中うまく行くんじゃないかなあ。

…と、最近のEmacsでプロポーショナルフォントを使ってソースを書いてて思ったのでした。結構気持ちいいですよ。

Re:スペースの次はタブ

[Jadawin (2174)]

＞世の中XMLワッショイだけれども、さすがに人間が書くものじゃない。
＞たとえ ば JavaML [washington.edu] なんてものもあるけど、そのソースを手で
＞こう [washington.edu]書くなんて気が狂うでしょ。
　
それぐらいは、書けんことはないですよぉ。それって、別にテキストじゃなくてプログラムローダーを書いているわけですから。
　
＞テキストエディ タでスペースバーを叩いてレイアウト決めてたのに比べればどれだけ大変か。
　
それは同意。でも、「レイアウトなんて情報交換には無駄無駄。押し着せのレイアウトで十分」というふうには、割り切れんもんなのでしょうか？こういった所を覗いている人ですら。
　
＃皮肉じゃなく、純粋に疑問っす。
　
簡単なレイアウタに関して言えば、CGIプログラムがHTMLを吐くためのフレームワークが色々ありますよね？あれと似たような仕組みで、emacsマクロができたら手で入力するんでも不可能ではないかもしれないとか思ったりして。
　
＃「タイトルページ中で、上上下下右左右左ABだ！」

Re:スペースの次はタブ

[nasb (3002)]

でも、「レイアウトなんて情報交換には無駄無駄。押し着せのレイアウトで十分」というふうには、割り切れんもんなのでしょうか？

見落としているかもしれませんが、レイアウトというのは貴重な情報源です。適切なレイアウトはデータを整理し、人間の理解を助けます。そもそも、人間が表現を行うときには、本質的にデータとレイアウトの両方を含んでいます。ただ、そのままではmachine readabilityが低いので、ここ数年来、データとレイアウトを分離する必要性が認知され実践されてきました。

しかし、分離したときに、人間の自然な表現に含まれていたはずのレイアウトはどこに行くのでしょう? その情報は落とされて無視されるか、人力でタグ付けなどのエンコーディングを行うか、という理不尽な扱いを受けることになります。それは対人間インタフェースとして望ましいものではありません。

人間の意図をきちんと汲み取ってくれるようなインテリジェントなインタフェースがそのうちできればいいのでしょうが、でも現状あるシンプルな技術だけでもそれなりの実現がありそう、という話です。

Re:スペースの次はタブ

[Jadawin (2174)]

＃だんだんDeepな議論になる予感。
　
これ↓以前のところは同意。
　
＞しかし、分離したときに、人間の自然な表現に含まれていたはずのレイアウトは
＞どこに行くのでしょう?
　
さて、このあたりからちょっと立場が違うようです。さっきの乱暴な聞き方じゃなくて、もう少しブレークダウンします。文書はどこまでオリジナルに忠実であるべきだと思いますか？

• 内容が伝わる
• フォントの種別、サイズ
• 図表の位置
• 改ページ位置
• 改行位置
• 欧文のハイフネーション形式

＃たぶん全部というのかなぁ？
　
もしこれらすべてというのであれば、同じレンダリングエンジン、同じフォントフォントセットを要求していることになります。でも、それってどこか一社が独占している状態か、それらが完全にオープンソースで公開されている状態かのどちらかでしか、実現しそうにもないです。細かいところは各社各様で、しかも自社の財産だから妥協しないという状況が続いてるようですから。
　
個人的には、文書環境において標準化が一番重要なフェーズにいるんじゃないかと考えています。そのような意味から、とりあえずはレイアウトの細かい所は積極的に忘れたいと思っています。
　
＞その情報は落とされて無視されるか、人力でタグ付けなど
＞のエンコーディングを行うか、という理不尽な扱いを受けることになります。
＞それは対人間インタフェースとして望ましいものではありません。
　
でも、それはすべて人間の思い通りにさせ、それを人間の手間で実現するからですよね？それだと結局グラフィックツールになってしまうんじゃないでしょうか？
　
＃昔の毛筆手書きを真面目に再現しようとするとそんな話になりますよね。
＃漢字と平仮名で、また文頭や名詞などでも文字の大きさは違うでしょう。続け字の話もあります。
　
でも、そのような文書の表示は携帯電話じゃ、メモリ、画面サイズ、CPUパワーのどれを取って見ても厳しいですよね？しかも、すべての人がそれなりのレイアウトセンスを必要としますよね？いちいちすべてに体裁情報をつけるのは大変ですよね？
　
そしてその現実的な落とし所が、内容と体裁の分離なのではないでしょうか？スタイルシートをカスタマイズしたり、個別の段落や行に違うスタイルを適用することは(論理的には)可能ですから、そのあたりで手を打ってもらえませんか？このようなことを天秤にかけた結果だと考えれば、100%の自由がないことも理不尽とまでは言えないと思いませんか？
　
＃「半紙に筆でできることが、なんでコンピュータだと難しいんだよ！」と言われたら、
＃どうしよう。どんな道具でも自由にならない分特定の能力を拡大できるのだと思うけど。

Re:スペースの次はタブ

[nasb (3002)]

立場というか、議論の対象が違うようです。

machine-machine interfaceはどんな形式でも構いません。統一されるのはよ いことなのでXMLでOKです。

しかし、私は最初から今までhuman-machine interfaceの話をしています。 human-machine interfaceはend pointなので、どんな形式に変換してもよいし、 その際には人間のニーズにとって、より直感的で便利な形式を採るのがよいで しょう。

具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。プログラムのソースもhuman-machine interfaceの一つ ですよね。

文書はどこまでオリジナルに忠実であるべきだと思いますか？

• 内容が伝わる
• フォントの種別、サイズ
• 図表の位置
• 改ページ位置
• 改行位置
• 欧文のハイフネーション形式

私の答えは「ニーズに応じて」です。そこはたぶん一緒の意見だと思うのですが。

Re:スペースの次はタブ

[Jadawin (2174)]

ようやく、おっしゃることが脳味噌に浸透してきました。
　
＞具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に
＞表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。
＞プログラムのソースもhuman-machine interfaceの一つ ですよね。
　
それが論点の中心であれば、私の意見は「XML吐くだけならフレームワークというか、ライブラリと言うか、それを補助するものを使えばいいんじゃないかなぁ？」です。でもnasbさんの本論は「そのような所でも表現の余地を残したい」でしたっけ。そうすると、、、やっぱり意味付けに基づいた単純な自動化だけでは無理です。
　
共通のスタイルシートで80%ぐらいはうまくいくのでしょうから、残りの問題のでる所をそのパラグラフ固有のスタイルシートを用意することである程度解決できそうです。
　
＃結局は、スタイルシートは面倒だという話？それはそれで、納得できる意見です。
　
ただ、タブ区切り方式で綺麗に並ぶのは、表とかプログラムテキストだけですよね。しかも、エスケープシーケンスやcursesを仮定すると、パイプでつないで後処理というのはXML以上に面倒になりそうな気がします。このあたりは、どうお考えですか？

Re:スペースの次はタブ

[Jadawin (2174)]

おっと、言い忘れてた。だいぶ長くなってきたので、飽きたらほっといて下さい。
　
＃ストカ臭い？

Re:スペースの次はタブ

[nasb (3002)]

私は終始「人間と機械の間」のインタフェースの話をしています。JavaMLの話 を引き合いに出したのは、単に「XML直書き」はユーザインタフェースとして 良くない、という意見を示すためです。

＃結局は、スタイルシートは面倒だという話？それはそれで、納得できる意見です。

アプリケーション(=ユーザがやりたいこと)を定義した時には、適切なユーザ インタフェースを選びますよね。面倒でないというのは良いUIの要件ですから、 タグを打つのよりも楽な方法があればそれを採るわけです。もちろん、XML直書き の方が幸せな人がいれば、それでもいいわけです。

別の例では、イラストを描きたいと思ったら、ドローイングソフトを持ってき て、マウスやタブレットで入力するわけです。そのソフトの内部でSVGを使ってい ようとUIには関係ないです。

ただ、タブ区切り方式で綺麗に並ぶのは、表とかプログラムテキストだけです よね。しかも、エスケープシーケンスやcursesを仮定すると、パイプでつない で後処理というのはXML以上に面倒になりそうな気がします。このあたりは、 どうお考えですか？

面倒だということは、適切なUIでないということなので、UIを変えるだけでしょ う。

Re:スペースの次はタブ

[Jadawin (2174)]

なんか微妙にすれ違っていますね。
　
＞私は終始「人間と機械の間」のインタフェースの話をしています。
　
私もそうです。ただ、私の場合はそもそも人間(この場合はnasbさん)の要求がどこにあるかを明らかにしない限りは、インタフェースの設計は無理だと思っています。また、基本にある技術を仮定せずには、何ができるかを判断できません。それで、XMLを仮定してnasbさんの場合だと、どの程度が妥当かを聞いている訳です。要するに、技術で実現できることを念頭において、何ができることを期待するかやどの程度まで労力を払ってもよいかを、nasbさんの一例でよいから知りたいと思った訳です。
　
さて、最初の話題に立ち返って私の頭の中を整理すると、

1. アジア圏の言語サポートを考えると、カラムという考え方はそのままでは通用せず、幅は可変でなければならない。
2. nasbさん: タブ区切りはどうか？
3. 私: いっそのことXMLはどうか？
4. nasbさん: XMLを手で記述するのは大変だ。
5. 私: 入力支援のフレームワークはどうだろうか？
6. 私: ただし、入力支援を使うと100%の自由は失われる。なにがnasbさん的には許容できて、何が許容できないのか？
7. nasbさん: 許容の範囲は場合や人によりけり。
8. 私: 話を変えてnasbさんのタブ区切りだと、どの程度できるか？いくつか問題がありそうだが？
9. nasbさん: それぞれが、問題と面倒がないものを選べばよいのでは？

こんな感じだったと思います。
　
＃違ってたら言って下さい。
　
で、すれ違っていると思う理由は、私はこの場合にnasbさんの許容範囲がどこにあるかを聞きたいと思っているのに、nasbさんが一般の話ととらえて、「人によりけり、場合によりけり」と答えているように思えることです。
　
ここで確認したいのですが、nasbさんはまだこの話題続けたいですか？どうも、問題のとらえ方が私とnasbさんでは違うようなので、このまま話を進めても同じことを違う言い回しでなんども繰り返すはめにおちいりそうです。
　
見直してみると私の方にも舌足らずなところが、幾つかあります。一番大きいのは、「私はXMLを手で書ける」と言いましたが、「すべてのユーザにXMLを手で書く事を強制したい」と思ってません。だからこそ、直書きではなくて入力支援のフレームワークを使うのだろうと仮定しました。それを前提に「表現の余地」を残すのであれば、XMLの枠組みではスタイルシートを記述するようになるのですが、これは許容範囲なのかなぁと聞いてみたわけです。最初は冗談半分の記事から始まってたので、私の話がわかりにくかったのでしょう。その点はご容赦下さい。
　
私のまとめが許せん位に違っている場合、まだまだ話を続けたい場合にはこの記事にコメントして下さい。

Re:スペースの次はタブ

[nasb (3002)]

「人間と機械の間」のインタフェースの話に、基本技術としてXMLが出てくる のが変だと思うのですが。XMLは「機械と機械の間」のインタフェースですよ ね。

XMLの使用をユーザに意識させるのは良いインタフェースでは無い、というの はよろしいでしょうか?

その上で、実装の簡便さの利得が、ユーザが受ける苦労の程度を上回るならば ユーザにXMLの使用を意識させるのも妥当だと思いますよ。

それを前提に「表現の余地」を残すのであれば、XMLの枠組みではスタイルシー トを記述するようになるのですが、これは許容範囲なのかなぁと聞いてみたわ けです。

スタイルシートがなぜ必要なのか判らないのですが、ひょっとしてXHTML(また はレイアウトを仕様に含めないその他のXMLの実装)を仮定していたのでしょう か?

Re:スペースの次はタブ

[Jadawin (2174)]

うーむ。
　
＞ 「人間と機械の間」のインタフェースの話に、基本技術として
＞XMLが出てくる のが変だと思うのですが。XMLは「機械と機械の
＞間」のインタフェースですよ ね。
　
このあたりが、立場の違いの一つですね。エンドユーザ向けかと言われれば、「もちろん違います」とこたえるのですが。
　
アセンブラも、PostScriptも、HTMLも、人とマシンをつなぐための言語ですよ。技術者しか使いませんが。テキストで符号化するものは、たいていそうだと言ってかまわないのじゃないでしょうか。もちろん、XMLだって同じだと考えています。
　
したがって、nasbさんがXMLを「人間と機械のインタフェースではない」と判断させた理由にはちょっと興味があります。
　
＃「面倒臭い」と「難しい」は、エンドユーザ向けにはふさわしくないことしか示していません。
　
＞XMLの使用をユーザに意識させるのは良いインタフェースでは無い、
＞というの はよろしいでしょうか?
＞その上で、実装の簡便さの利得が、ユーザが受ける苦労の程度
＞を上回るならば ユーザにXMLの使用を意識させるのも妥当だと
＞思いますよ。
　
最初の言明だけだと100%の賛成はできませんが、後の文も含めれば同意できます。
　
＞スタイルシートがなぜ必要なのか判らないのですが、ひょっとしてXHTML
＞(また はレイアウトを仕様に含めないその他のXMLの実装)を仮定していたのでしょう か?
　
うーむ。私がなにやら勝手に色々仮定しすぎていたのかな？以下、私の認識です。

1. XHTMLは、HTMLからレイアウトに直接関連する要素を取り除きXML化したものです。したがって、これまでXMLの話をしていたので少なくとも、XHTMLぐらいは前提になっていると思っていました。
2. レイアウトを仕様に含めたタグセットには、「可能な限りの表現の自由」はありません。したがって、「表現の余地」をおっしゃっている以上、少なくともCSS程度のスタイルシートを前提にしていると思っていました。
   (ちなみに私は、以前Operaの話題であったパラグラフ先頭のJIS X 0208の空白が削除される件は、スタイルシートで対応するのが筋だと考えてます。そんなところで独自性を主張しても、「日本語対応って面倒クセェ」と思われるだけで、あまりメリットがなさそうです。)
3. 今までは特に話題に上げてはいませんでしたが、DTDにしろ他のスキーマにしろ、タグセット自体の定義も「可能な限りの表現の自由」には必要だと思っています。
4. ユーザインタフェースは本質的には多層です。技術者向けの低レベルのインタフェースは使いにくいですが、可能なすべての機能を利用可能にします。エンドユーザ向けの高レベルインタフェースは、エンドユーザに簡便に使えることを目的として、その機能すべてを利用可能にしてはいないことがほとんどです。言語によっては、言語に依存する部分を吸収する仕組みも必要でしょう。

ということで、もし「スタイルシートいらない」＆「標準のタグセットがあればいい」であれば、私が考えている「可能な限りの表現の自由」を求めているわけではないので、対立しているように見えた話題には決着がつきます。
　
他には、特にnasbさんと対立しているという意識は無いのですが、こんな話題ならまだ続けたいような気も。

1. タブ区切りだとどの程度までできるんだろう？
2. 局面によってUIが変わることはどの程度許容可能なのだろう？
3. プログラムに埋め込むUIは、どのような形式がよいのか？
4. 最初に戻って、アジア系の可変カラムをサポートした環境では、妥当なレベルの機能とそれに対するインタフェースってどんなものだろう。

Re:スペースの次はタブ

[nasb (3002)]

このあたりが、立場の違いの一つですね。エンドユーザ向けかと言われれば、 「もちろん違います」とこたえるのですが。

私はここ用いられている意味での「エンドユーザ」とアセンブラやPostScript を記述する「プログラマ」を、区別する必要は無いと思っています。両者とも、ユーザイ ンタフェースのこちら側であり、目的や環境が異なるだけです。そしてその目 的や環境に応じて、直感性や、機能性などのさまざまなパラメータの中から何 を重視するかを選んで、ユーザインタフェースが決まるわけですから。

したがって、nasbさんがXMLを「人間と機械のインタフェースではない」と判 断させた理由にはちょっと興味があります。

端的に言えば、「機械と機械」が主で「人間と機械」が従(というかおまけ)だ ということです。アセンブラは間違いなく「人間と機械」ですね。PostScript はまあ、あれはプログラミング言語ですが、「機械と機械」が主だと思います。 どこで線を引くかが曖昧だと思われるなら、100%純粋にユーザインタフェース として設計されているか、と考えてください。

その観点でいうと、たとえば「XHTMLを直書きさせる」というのは、XHTMLとい う「機械と機械」のインタフェースをほぼそのまま「人間と機械」に写像した、 と言えます。適当な入力支援を使う場合も同様に、それはXHTMLを若干加工を 加えて新たなユーザインタフェースの一つに写像したものです。

さて、Jadawinさんは

レイアウトは不要。「人間と機械」の間は直書き、またはな んらかの入力支援を用い、「機械と機械」の間はXHTMLのようなレイアウトを 含まないXMLの実装を用いる。

という話をしていて、私は

レイアウト表現は落とさない。「人間と機械」の間はTSV(のよ うなもの)、「機械と機械」の間はとくに拘らない。 (当然、XMLを使うならレイアウトを含むXMLの実装になるだろう。)

という話をしている、というのが私の認識ですが、私は二人の間で何かが対立しているという気がしないのです。

ということで、もし「スタイルシートいらない」＆「標準のタグセットがあれ ばいい」であれば、私が考えている「可能な限りの表現の自由」を求めている わけではないので、対立しているように見えた話題には決着がつきます。

「標準のタグセット」を「適切な仕様を与えた新たなXMLの実装」と読み取っ ていいとすると、「そういう実装を使っても構わない」と思っています。

1. タブ区切りだとどの程度までできるんだろう？

これは私自身深く考えていたわけではありません。しかし、Jadawinさんが既 に書かれていたようなことができれば十分と思います。というのは、(この話 がもともとターミナルエミュレータのトピックだったように)ターミナルエミュ レータに出力させるような古典的な(しかしまだ需要はある)プログラムを記述 するための便法が、私の想定する「ユーザの目的」だからです。

# カラムを揃えるポリシやそのアルゴリズムを考えるのは楽しそうですが。

Re:スペースの次はタブ

[Jadawin (2174)]

うーん。もうちょっと感が。
　
＞私はここ用いられている意味での「エンドユーザ」とアセンブラやPostScript を記述する
＞「プログラマ」を、区別する必要は無いと思っています。
　
えと、nasbさんがこのように思いたいというのは認識しました。私の考えは、ユーザによって(nasbさん言うところの)「目的や環境」が異なり、本当にそれぞれの利便を追求すると一つのインタフェースになるとは思いにくいってやつです。
　
＞その観点でいうと、たとえば「XHTMLを直書きさせる」というのは、XHTMLとい
＞う「機械と機械」のインタフェースをほぼそのまま「人間と機械」に写像した、
＞ と言えます。適当な入力支援を使う場合も同様に、それはXHTMLを若干加工を
＞加えて新たなユーザインタフェースの一つに写像したものです。
　
これは論理的には間違っていませんが、ちょっと抽象論に寄りすぎて、現実には違うものを無理に一緒にしている感があります。同じ論理を展開すると、ユーザがキーボードを叩いて、文章を入力できるという意味では、ユーザインタフェースとして、かな漢字変換がT-コードやJIS16進入力と同じだと主張できてしまいます。ユーザインタフェースを語る文脈では、あまりにも乱暴な論理展開ではないでしょうか？
　
＞レイアウトは不要。「人間と機械」の間は直書き、またはな んらかの入力支援を用い、
＞「機械と機械」の間はXHTMLのようなレイアウトを 含まないXMLの実装を用いる。
　
これは明らかに私の主張を誤解されています。レイアウトを不要という人間が、自らスタイルシートの話題を出したりはしません。そもそもスタイルシートがどのようなものかご存知ですか？
　
＞レイアウト表現は落とさない。「人間と機械」の間はTSV(のよ うなもの)、
＞「機械と機械」の間はとくに拘らない。 (当然、XMLを使うならレイアウトを含むXMLの実装になるだろう。)
　
これもXMLとスタイルシートに関する誤解から来ている言葉のように思えます。スタイルシートを利用するとHTMLと同程度にサボりたい人はサボれるし、いじりたい人にはいくらでもいじれるようになります。どうです？nasbさんの要求にあっているとは思いませんか？
　
＞という話をしている、というのが私の認識ですが、私は二人の間で何かが対立しているという気がしないのです。
　
こちらの立場は対立というよりは、「nasbさんがXMLをけぎらいしているらしいのをなんとか変えたい」に変わってます。
　
＞ターミナルエミュ レータに出力させるような古典的な(しかしまだ需要はある)プログラムを記述
＞するための便法が、私の想定する「ユーザの目的」だからです。
　
このような条件であれば、nasbさんのおっしゃっていることのだいたいには同意できます。ただ、TSVの方式は明らかにベストではありません。複雑な文字の組合せのあるタイ語やアラビア語では比較的すぐに限界にぶちあたるだろうと思います。
　
＃それらを考えないなら、今まで通りでよい分けですし。
　
ですから、もし本当にすべての言語をサポートするつもりなのであれば、一見は手間がかかるだけのように見えても、XML+スタイルシートの形式が最終的には一番の近道ではなかろうかと思っているわけです。
　
＃ちなみに、XML+スタイルシートが唯一の解であるとも、それが最も簡単な解であるとも、
＃主張はしません。とりあえず、XMLの自由度の高さを生かせばかなりの場面で対応できるだろう。
＃それより条件が絞れるかどうかは、それらの言語を生まれながらに話す人々の判断にまかせたい
＃てな感じでしょうか。

Re:スペースの次はタブ

[nasb (3002)]

うーん。もうちょっと感が。

はるかに遠ざかってしまった気がします。(;_;)

私の考えは、ユーザによって(nasbさん言うところの)「目的や環境」が異なり、 本当にそれぞれの利便を追求すると一つのインタフェースになるとは思いにく いってやつです。

私の考えは、ユーザによって「目的や環境」が異なるので、それぞれに応じて 適切なインタフェースを選べばよい、です。で、両者に違いがあるのですか?

これは論理的には間違っていませんが、ちょっと抽象論に寄りすぎて、現実に は違うものを無理に一緒にしている感があります。同じ論理を展開すると、ユー ザがキーボードを叩いて、文章を入力できるという意味では、ユーザインタ フェースとして、かな漢字変換がT-コードやJIS16進入力と同じだと主張でき てしまいます。ユーザインタフェースを語る文脈では、あまりにも乱暴な論理 展開ではないでしょうか？

誤解しています。「人間と機械」のインタフェース(またはユーザインタフェー ス)というレイヤの話をしているのです。単一のインタフェースの話している のではありません。

例示も、「機械と機械」のインタフェースというレイヤのものを、「人間と機 械」のインタフェースというレイヤに持ってくるときに、写像の方法が何通り もあるよ、という話です。

＞レイアウトは不要。「人間と機械」の間は直書き、またはな んらかの入力支援を用い、
＞「機械と機械」の間はXHTMLのようなレイアウトを 含まないXMLの実装を用いる。

これは明らかに私の主張を誤解されています。レイアウトを不要という人間が、 自らスタイルシートの話題を出したりはしません。

誤解とは思えません。ここでは(これまでも)ユーザインタフェースの話をして います。ユーザインタフェースがレイアウトを機械に伝達するかどうか？の話 です。レイアウト情報を用いないXMLの実装を用いて「スタイルシートに任せ る」と言った時点で、ユーザの表現したレイアウト情報が落ちるんです。

後で出た「拘りたいならスタイルシートを別に書き起こせばいい」という話は 別の話です。それは、そもそも、「レイアウト情報を含むXML実装」と(「機械 と機械」の)インタフェース的に等価です。そして、私の言っていることに包 含されます。

スタイルシートを利用するとHTMLと同程度にサボりたい人はサボれるし、いじ りたい人にはいくらでもいじれるようになります。

スタイルシート(どのスタイルシートを指しているのかは知りませんが)のよう にレイアウトを表現する能力を持ったインタフェースが、レイアウトを伝達す る目的に使えるのは言うまでも無く自明ですが。

こちらの立場は対立というよりは、「nasbさんがXMLをけぎらいしているらし いのをなんとか変えたい」に変わってます。

私はXMLは嫌いでもなんでもなくて、XMLとは関係ない話に関して「XMLは関係 無い」と言っているだけなのですが、その点が伝わるとこの長話も終わるのか なあ、という気がしてきました。

ただ、TSVの方式は明らかにベストではありません。複雑な文字の組合せのあ るタイ語やアラビア語では比較的すぐに限界にぶちあたるだろうと思います。

＃それらを考えないなら、今まで通りでよい分けですし。

複雑な組み合わせが起こる文字種でも、そんなに簡単に限界に到達する気はし ません。そもそもの発端が「それらのことを考えましょ」という話ですし。

ですから、もし本当にすべての言語をサポートするつもりなのであれば、一見 は手間がかかるだけのように見えても、XML+スタイルシートの形式が最終的に は一番の近道ではなかろうかと思っているわけです。

「機械と機械」のインタフェースにそれを用いるのには反対はしませんけれど (というか、そこは話の本質でないのでどうでもいい)、その先の「人間と 機械」のインタフェースには何を選んでもいいでしょう。
それこそ、「ユーザによって『目的や環境』が異なるので、それぞれに応じて適 切なユーザインタフェースを選べばよい」です。

Re:スペースの次はタブ

[Jadawin (2174)]

ふーむ。また少し理解したような気が。
　
たぶん、一番の違いは、次の所にあるんだろうと言う気がします。

• nasbさん： ユーザインタフェースは下層の機能を意識する必要はない。
• 私: ユーザインタフェースは下層の提供する機能を前提に設計されるべきだ。

＃単にnasbさんは物事を簡単にとらえたいから、細部を省いた言明を好み、
＃私は複雑なものは複雑なままとらえるのを好むんで、徹底的に条件をつける、
＃という違いに思えてきました。まぁ、それでも分からん所もあるんですが。
　
下層がどのような機能を持つかを気にしないでよいのは、アプリケーションのレベルから見て下層が100%等価なものの場合だけです。
　
＃出力ファイルを保存するディレクトリを変えたところで、操作には影響しません。
　
前にnasbさんが上げたグラフィックツールの保存形式の例だって、JPEGを選択すると圧縮率がどうだとか、別途設定ダイアログがありますよね？すべてが全く同じユーザインタフェースにはなりませんよね？これは、下層の機能によってユーザインタフェースが変わる例ではありませんか？
　
＞レイアウト情報を用いないXMLの実装を用いて「スタイルシートに任せ る」と言った時点で、
＞ユーザの表現したレイアウト情報が落ちるんです。
　
あのー、すんません。このあたりは、徹底的に理解できんです。
　
既存のスタイルシートに任せるかどうかは、ユーザが選択するのではないですか？ユーザが選択する以上は、それがユーザの意図したレイアウト情報になるはずですが。そうで無ければ、そのユーザは何らかの方法でスタイルシートを書けばよいのではないですか？なぜスタイルシートを書くことが、ユーザインタフェースの一部にはなりえないんですか？
　
それに、スタイルシートを使えば落ちてしまうようなレイアウト情報って何があるのでしょう？テキストの中に含めた空白の数とかを問題にしたいのでしょうか？今話している文脈では、カラム幅は不定という前提がありますから、空白は入っているか否かしか問題にはできないはずで、レイアウト情報を持っているとは言えませんが。
　
また、私はスタイルシートを用いるとは言っていますが、XMLの入力と同様に入力補助手段を用意するのでしょうから、その場合ユーザインタフェースの上からはシームレスに見えるでしょう。
　
＃おお。そうか、これを指してnasbさんは「レイアウト情報を含むXML実装」と呼びたいのですね。
＃でも、この言葉ではHTML4.0をそのままXML化したようなものを思い浮かべてしまいます。
＃nasbさんの言いたいことであれば、もっと抽象的な言い方をすべきだったのではないでしょうか？
＃実装なんて言葉が出ると、私なんかものすごく具体的な事柄を期待してしまうのですが。
＃また、そのように理解した上でもスタイルシートに関しておっしゃることは理解できないままです。
　
＞複雑な組み合わせが起こる文字種でも、そんなに簡単に限界に到達する気はし
＞ません。そもそもの発端が「それらのことを考えましょ」という話ですし。　
　
本当ですか？少なくとも、漢字の各パーツ(へんやつくりより小さいレベルのもの)を組み合わせて、任意の漢字をつくり出すのと同程度に大変なものになるはずです。そりゃ不可能では無いにしろ、最初に言っていたタブで区切る程度の簡単な形式とはかけ離れたものになりませんか？共通点は、タブで区切られているというだけで、グループ化を可能とする記号列とか、ネストを可能にする記号列とか、特定の部分の参照の方式とかを追加していくのですよね。

Re:スペースの次はタブ

[nasb (3002)]

既存のスタイルシートに任せるかどうかは、ユーザが選択するのではないですか？ユーザが選択する以上は、それがユーザの意図したレイアウト情報になるはずですが。そうで無ければ、そのユーザは何らかの方法でスタイルシートを書けばよいのではないですか？

「任せる」のではなく、ユーザインタフェースの中で「選べる」のなら、レイ アウト情報を読み取れるユーザインタフェースなので、私が嫌がったものとは 別物でしょう。私は後者には不満は述べてませんよ。

なぜスタイルシートを書くことが、ユーザインタフェースの一部にはなりえな いんですか？

私はそんなことは言ってませんよ。

＃おお。そうか、これを指してnasbさんは「レイアウト情報を含むXML実装」と呼びたいのですね。
＃でも、この言葉ではHTML4.0をそのままXML化したようなものを思い浮かべてしまいます。
＃nasbさんの言いたいことであれば、もっと抽象的な言い方をすべきだったのではないでしょうか？

ここの文章の意味は、私には判りませんでしたが、それはさておき、私が「レ イアウト情報を含むXML実装」と言ったものは、一例としてまさに「HTML4.0を そのままXML化したようなもの」でいいです。

Re: ところで

[D.Matsu (3636)]

他にも ps とか…

Re: ところで

[kubota (64)]

curses ベースなソフトウェアは全部だめでしょう。

Re: ところで

[Anonymous Coward]

sl [linet.gr.jp]以外には、どのようなソフトがcursesを使っているのでしょう？

Re: ところで

[G7 (3009)]

あと、プログラミングのときに困るぞ、っていう意見は
寝言として切りすてるべきなんでしょうか?(^^;

かつて、はじめてHypertalk(Hypercardの)のコーディング風景を
見せてもらったとき、プロポーショナルだったんで吃驚した記憶が。

同じ人がTurboPascal(for Mac ver1 (^^))では等幅フォントでやってたんで、
見ていて色々複雑な気分(?)になりました。

実際、どっちが良いんだろうなあ…
とりあえず俺はこの問題についてはOldTypeだな。等幅のほうが落ちつく。

#それどころか最近はIEのフォントも等幅系にしてるし

Re: ところで

[Dubhead (1033)]

> あと、プログラミングのときに困るぞ、っていう意見は
> 寝言として切りすてるべきなんでしょうか?(^^;

少数派として切り捨てられるかもしれませんね。
エディタなら別窓でgvimなりEmacsなり立ち上げる人が多いと思うので。

ちなみにXEmacsでプロポーショナルフォント使っても別に困りません。
困るのはメイル書くときに１行の文字数を気にする時くらい。
あと人によっては、矩形のcut&pasteする時に不便かも。

Re: ところで

[G7 (3009)]

>少数派として切り捨てられるかもしれませんね。

えー??

ページ上でどうコードが並ぶかというのは重要だと私は経験から知った。可変幅のフォントで表示されたLispコードを私はほとんどまともに読めないし、私の友人達はそれは他の言語でも同様だと言う。 [dreamhost.com]

というハッカーの声が有るようなのですが(^^;;;

もし俺の見立て(笑)が正しければ、少数派ではあっても重要なハッカー諸氏が
等幅画面を愛するのかも。

>エディタなら別窓でgvimなりEmacsなり立ち上げる人が多いと思うので。

コマンドラインの世界でエディタを別窓にしちゃうと、
どうもノリが合わないんですけども…

>あと人によっては、矩形のcut&pasteする時に不便かも。

人によるというより、(vimみたいな)その機能があるエディタか否かによるのでは?

というか、エディタとコマンドライン編集(^^;以外の世界では
あまり生活してないような気がするんですけど…。

あすきーあーと

[Anonymous Coward]

コラム幅可変に対応したのは、ISCII のため、ということもあ
りますが、最近ですと、2ch などで、コラム幅可変でないとう
まく表示できないアスキーアートがたくさんありますので、そ
ちらでの需要を想定していたりもします:)

多くのコンソ

Re: ところで

[Anonymous Coward]

アスキーアートと言えば ttytv [www.nmn.jp] すごいです。

せくしょん

[Anonymous Coward]

なんで「プログラミング」？
「UNIX」とか「X」とかあるのにー。

Re:せくしょん

[kubota (64)]

そういやそうですね。「UNIX」はちょっと違いそうな気分ですが、「X」のほうがよかったかもしれません。あまり深く考えないでください。ほんとうは「国際化」とかがあったらいいなと思うのですが。

「プログラミング」なのは、まだまだ枯れてなくて... という気持ちの表れかもしれません... いや、枯れるひまがないくらい開発スピードが速いんです (ほんとに。ChangeLog ファイルを見たら、ほぼ毎日のように何らかの変更が入っていますし、ML もそれに応じて活発です。メンバーがまだあまりいないので、流量全体としては大したことはありませんが)。

開発スピード

[Anonymous Coward]

単に暇人なだけですが^_^;

とりあえず手元では、縦表示対応が大分モノになりつつあり
ます。今日中には commit できるかな。

とりあえず
http://www.geocities.co.jp/SiliconValley-Cupertino/6461/tate.png
↑こんなん

モンゴル対応の縦表示対応もしたいんですけど、どういう形で
対応することが望まれているのかわからないので手がだせない
状況です。

コンソールアプリケーションでどこまでやってもらえると仮定
できるのかわからないのですし、今の実装では、全体を縦にする
ことしかできませんので、部分的に縦表示しろ、ということに
なると難しいですしね。

その辺について、詳しいかたに、コメントをいただけるとうれ
しく。

-- あらき@作者

Re:開発スピード

[nobichan (4085)]

すげー、後は表示の向きによって向きの変わる字の回転を何とかすれば
使い物になりそう？！(もしかしてアプリの方の仕事か？)

> モンゴル対応の縦表示対応もしたいんですけど、どういう形で
> 対応することが望まれているのかわからないので手がだせない
> 状況です。
全然詳しくないのですが、何年か前、モンゴルで体制が変わってモンゴル文字が
復権した頃に、モンゴル文字を使った新聞を入力するのに
Mac(?)のようなマシンの前で、横書きで入力しているのを見たことがあります。
フォントも横倒しになっていました。モンゴル文字は、縦書きで左から
右に流れる(日本語と逆)なので、遠目にはあたかもアラビア系の文字を入力しているような
雰囲気でした。
ためにならないコメントでごめんなさい。

# ところで、X用のモンゴル文字のフォントってあるんですか。商用だとあるのかな。

縦表示

[Anonymous Coward]

> 後は表示の向きによって向きの変わる字の回転を何とかすれば
> 使い物になりそう？！(もしかしてアプリの方の仕事か？)

とりあえず、CVS にほりこみましたので、興味がおありでしたらお試しください:)

文字の回転処理についてですが、この場合は、端末側の仕事です。
が、

1.
手元でフォントの Bitmap を管理しないと、文字の回転処理は不可能。

2.
回転できるとしても、どの文字をどれだけ回転(移動)するか、というデ
ータベースを管理するのは大変(JISX0208 に限定すれば、それほどでも
ないでしょうけれど)

ということで、素直に縦表示用のフォントを使う、という解をとりたい
とおもっています。

とはいえ、X で使える縦フォントがどの程度あるのかわからないのですが....

--- あらき

exterm

[Anonymous Coward]

その昔、extermなるものがXのcontributeにあったような気が。
アレはどうなっちゃったのでしょうか?