[MD:3665] w32-list-fonts and XLFD.

[MIYASHITA Hisashi(宮下 尚:HIMI) <himi@xxxxxxxxxxx>]

Keiichi Suzuki <keiichi@xxxxxxxxx> writes:

> Patch でもつくって開発側に文句^H^Hお願いするというのが正しい姿か
> な? まだ，数は少なそうだから早いうちに芽を摘んでおけば，その後は
> そのコードを参照して... ということで，良い方向に向かうのではない
> かと。

たぁ...。確かに。

> ;; だれかやらない? ^^;;

是非。

なお、本来なら、(set-face-attribute)で、familyを指定するのが正しい方法です。
set-face-fontは、可搬性のあるEmacs Lisp プログラムは使うべきではありません。

> himi> でも、symbolといっても、encodingが違う可能性が高いし、ある
> himi> 意味では仕方ないのかもしれないけどねぇ。でも、本来は、
> himi> charsetを定義して、表示するべきものだと思うんだが。こうい
> himi> う発想は、いわゆるI18N/M17Nの考え方に触れていない人々には、
> himi> なじんでないということは言えそうだけど。ぶちぶち。
>
> charset って現状もう作れないんじゃなかったっけ?

作れないことは無いと思います。とくにdimension 1なら、まだ、
結構あまってるしbitmapのエリアも開いたし。

もう一つは、mule-unicodeにmapしちゃうって手もある。symbolの
文字(記号?)のかなりの分はUnicodeに対応が取れるから。

> himi> おっと、こっちは直してなかったけど、単にfontsetのlist部分
> himi> が問題になっているだけだよね。多分、Meadowでは、もう、
> himi> fontsetの必要は無いと思うけど、一応、互換性の為にfontset
> himi> nameのlistupもするようにしときますか。 かえって混乱の種だっ
> himi> たりして。^^;;;
>
> Font ととして list up するのではなくて， fontset として list up
> した方が感覚的に合うような気がするのだけれど，そんなことはない?

いいえ。うーむ、こういう疑問が出てくるということは、FRについての
説明が足りなかったかなぁ。

Emacs 20では、fontsetは、charsetと、fontとの対応をとっていました。
UNIXでの、Emacs 21も、まあ、そうであるといえば、そうなんですが、
Meadowでは、fontsetは、charsetと、FRの対応を取ることになっています。
FRは、char or charsetで、LFを選択することが出来るので、事実上fontsetは
屋上屋を重ねているだけの無意味な存在になってしまいました。^^;;;

>>> それと Emacs の x-list-fonts って， X で使える font は全部と
>>> れますね。この辺もどうしましょ。
>
> himi> これはどういうことが問題になるでしょうか?
>
> NTEmacs:
>
> 1. Elisp package が system の font 名(XLFD "-SYMBOL-")と内容を知っ
>    ている。
> 2. x-list-fonts (System にある font 群)のなかから，都合の良いも
>    のを探して使う。
>
> Meadow:
>
> 1. Elisp package が system の font 名(w32での名前 "Symbol")と内
>    容を知っている。
> 2. x-list-fonts (Meadow に登録されているもののみ)の中から，都合
>    の良いものを探すが，フツー symbol 何てものを登録する人はいな
>    いので見つからない。

無理に互換を取ろうとするなら、"symbol"という名前のFRで登録するのが
正しいやり方じゃないかなと思いますし、最初の設計からFRはそれを
意図していました。

XLFDなんてやり方でfontを指定してしまった時点で、ある種の依存性が
発生することは避けられません。それがいやなら、face attributeを
指定するべきだと思いますし、

> Meadow でやろうとすると...
>
> 2. w32-enum-logfont の中から，都合の良いものを探す。
>
> ようにしないとうまく行かないと思う。想定できる状態できれい(作者
> の思惑どおり)に表示しようとすると，これができないと辛いんじゃな
> いかな?

w32-enum-logfontが返却するものはLFなんで、あんまり意味が
ないんじゃないかと思います。LF loader以外には。

> 辛いところではあるけれど，いろいろな font を使えるようになるとい
> うことは，現実として，それを駆使したプログラムが出てくることは避
> けがたいと思います。

しかし、ある意味でどんな環境でも動作するprogramを目指すならば、font選択に
XLFDなんぞを使うべきではありませんし、どうしても使うというのなら、ある種の
抽象化層を置いて、実際のfontとの対応はユーザー側がcustomize出来るように
しないといけないのは変わりがないと思います。

> XLFD を捨てるという道を選んだ以上，それらのプログラムに対応する
> ためには，何らかの変更が必要になるでしょう。しかし，それらに一つ
> 一つ対応するのはかなりの労力になると思います。また，労力だけでは
> なく「Meadow じゃ動かないんだ。NTEmacs を使おう。」ということに
> なるのは悲しいものがあります。

そういうプログラムと互換性を取る為に、あらかじめFRを定義しておくのは
悪くないと思いますし、Meadow側での対応はそのぐらいが限界じゃないかなと
考えています。

> 以前，冗談で言いましたが， LF layer (Elisp loader で良いと思いま
> す)で， (不毛な作業にはなりそうだけれど)XLFD に対応するのが現実
> 的なのではないかと思いますが，どうでしょうか?

あんまり賛成できません。技術的に十分可能ですし、もちろん反対はしませんが、
優先度は低そうです。

どうせ、XLFDのような手段でフォントを指定する手段を選んでしまった時点で、
まるで可搬性の無いフォント選択手段を、そのprogramが採用したという
ことですし、そういったprogramを助長すると、結局は、X/Windows/Macなど
いろんなplatformでの動作が阻害されてしまうでしょう。それに、
そんなプログラムがこれから増えていくとは思えませんし。

また、個人的な予想だけど、NTEmacsに対応したfont選択のEmacs Lisp programなんて
これから作られるとは思えません。NTEmacsで、まともにfontを選択できないという苦情は
大量に聞くし、確かにあれじゃあ、制御不能に近いと思う。 X上のEmacsとて、かなり
厄介な挙動をするし。その上で、XLFDなんてemulateした日にゃあもう...。

## どうしてそういうことになってしまったかというと、XLFDと、Windowsのlogfontの
## 設計思想がまるで異なっているのにもかかわらず、対応を取ろうとしてしまった
## ためなんですけどね。

で、やっぱり、face-attributeでfaceのfontを可搬性のあるような形で指定するような
programに移っていくことになるでしょう。そうなったらしめたもので、圭一さんの
LF loaderの利点が、非常に生きてきます。^^ やはり、利用者環境に依存する部分は
Emacs Lisp library からは追い出すべきでしょう。それを知っているのはsystem側、
すなわちMeadow 本体側と、利用者独自の設定ということになるのですから。

from himi