[MD:2878]FR layerのC実装がなんとかできた。

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

わーい、やっとまともにフォントが選べるようになった。しかし、自分で言うのもなんだけど、
このFR、想像以上に柔軟で、便利だということが、使っているうちにわかってきました。

あとは、圭一さんが、High level font selection API以上の機能を持ったelispを書いて
くれればいいのね。^^

もうすぐcommitしますが、Meadow font systemのwhite paperの書きかけが
あるので、読んどいてください。

Meadow Font system 

(A) 基本指針

Meadowでは、font systemは、以下の3階層に分かれる。

+----------------------------------------+
| Font Request Layer     (FR)            | 
+----------------------------------------+
| Logical Font Layer     (LF)            | 
+----------------------------------------+==============
| Physical Font Layer    (PF)            | Invisible
+----------------------------------------+

(1) ... Font Request Layer

Fontの要求を指示したlayer。実際には要求とは異なるphysical fontが
割り振られる可能性もあるような情報も含まれる。
faceは、その情報からrealizeするfontを選択するのでfaceもFont Request Layerの
一部となる。 これは、font nameから引き出される。

(2) ... Logical Font Layer

 Deviceによる相違はあるものの、Physcal Fontと完全に対応することができる
font情報を取り扱うlayer。

(3) ... Physical Font Layer

 実際の(physical)fontを取り扱うlayer。Deviceによっても異なるため、一意的に
指定することは不可能なfontの実体。必然的に、完全に不可視。

--------------------------------------------------------------------------------

(B) 具体的実装

(B.1) 概要

font nameはstring。これは単なる識別のために用意され、faceからFR dataを引き出すための
keyとして、用いられる。

fontname ---> FR()

FR()は、face dataから、実際のFDを生成するためのfunctionである。

FR(<face data>) ---> FD

faceはrealizationのとき、このFRを用い、LFを割り当てる。

FD ---> LF

faceは表示されるとき、LFから、PFに変換される。

LF ---> PF

(B.2) llogfont

llogfontは、LFのlisp表現であるが、LFに直に対応するとは限らない。
FR layerに、LFの具体的な表現を与えたいときに用いる。形式は、

(w32-logfont <NAME> <WIDTH> <HEIGHT> <WEIGHT> <ITALIC-P> <STRIKEOUT-P>
             <CHARSET> <QUALITY> <OUTPRECISION> <PITCH&FAMILY>)
(bdf-font <file-name>)

であり、これは、Meadow 1.xと同じである。

(B.3) FRの具体的構造

FRは、w32-add-font-internalで追加される(C levelでは)。
構造は、単に、font name(FR name)と、alistだけである。

alistのkeyは、現状で、

  strict-spec

  function

の2つが決まっている。

'strict-spec のvalueは、以下の構造を持つ。
((<SPEC VECTOR> <llogfont> [<option-alist>])
 (<SPEC VECTOR> <llogfont> [<option-alist>])
  ...)

<SPEC VECTOR>は、将来的に変化すると思われるが、現状で、

[<char or char-table> <avgwidth> <height> <family> <weight> <slant>]

が許される。各elementは<char or char-table>を除いて、
'any、nilもしくは、face attributeに対応した値が入る。

<char or char-table>は、charもしくは、char-tableを持つ。
なお、charは、generic charも許される。

faceおよび表示したい文字の情報をこの<SPEC VECTOR>と照合し、照合した場合には、
<llogfont>の内容を選択する。このとき、option-alistが存在すれば、その情報を
表示の際に利用する。'anyは、faceのattributeが何であってもmatchする。nilの
時は、faceのattributeが、'unspecifiedでなくてはmatchしない。faceのattributeが
'unspecifiedの時は、どのようなSPECであってもmatchすることに注意。

なお、<SPEC VECTOR>において、<family>のkeyには、正規表現を指定する。

option-alistのkeyは、現状で、

  encoding-type
  encoder
  relative-compose
  default-ascent

が、有効である。

'function のvalueは、Lispの関数で、この関数は、

(lambda (char face-attrs frame))

という引数を取らなくてはならない。この関数は、nilか、<llogfont>か、 
(<llogfont> <option-alist>)のいずれかを返却しなくてはならない。

nilの場合には、有効なfontが見つからなかったことを示す。

charは、表示したい文字。 face-attrsは、現状で、

  :width
  :height
  :family
  :weight
  :slant

というkeyを持つproperty listである。将来増える可能性が高いので注意されたい。

FRのMeadowでの位置づけを簡単に言うと、「font nameに対応付けられ、
『具体的なフォントの選び方』を選択するもの」と呼べる。

(B.4) fontsetについて。

Emacsが持つfontset systemは、char or charsetから、font nameを引き出すsystemとして
とらえられる。この観点からは、face realizationは、以下のようなstepになる。

char -> font name -> FR       ---> LF ---> PF
                    + face-data

しかし、Meadowの設計的観点からは、charも、単にFR layerに入るのが自然な設計になるため、

face ---> font name ---> FR      ---> LF ---> PF
                        + char
                        + face-data

というstepをとるべきであるため、これを採用する。したがって、Lisp layerから見える
fontsetは、ほとんど飾りという位置づけになるだろう。

(C.1) 実装

choose_face_font@xxxxxxxxxx(xfaces.cにあるものは無効にする)が、
char->font name変換をつかさどる。

font name -> FR + face_dataは、load_face_font@xxxxxxxxから呼び出される
mw32_load_face_font@xxxxxxxxxxが担当する。

LF->PFは、LFの持つ各methodが直に行う。つまり、まるで見えない。

(C.2) LFのmethod

LFは、現状、4つのmethodを持つ。

  OUTPUTPROC textout;
  METRICPROC glyph_metric;
  LAYOUTPROC set_layout;
  FREEPROC free;

textout methodは、text出力用
glyph_metric methodは、個々のglyphの出力を行う。
set_layout methodは、string layoutの決定を行う。
freeは、LFの破棄に用いられる。free methodは、適切にPFを
開放しなければならない。

(D) 現状からの互換性の確保。

w32-add-font .etcは、FRを操作する。

w32-change-font-logfontは、FRのstrict-specを操作する。

faceの情報はFR layerに属する。

FR+FD -> LFの変換は、Lispで拡張可能だと良い。

基本的に、propertyはFR->LF変換に置き換えられてしまう。従って、
基本的にpropertyは廃止。

(E) 推測されるoverhead。

Not yet

ちなみに、FDは不要(というより作れない)ということになりました。

from himi
なんか、ここまでくるとかなり実用的になってきたから、なんだか開発する気力がかなり
うせてきた。^^;;; 今、特にBDFのLF methodがほしいな。
でも、まあ、のちのちのことを考えると、ちゃんとsynch. eventのことを考えないと。