[debian-devel:14407] Re: groff Japanese support breaks PS output for latin2

[Nozomi Ytow <nozomi@xxxxxxxxxxxxxxxxxx>]

> とりあえず返事をこちらに転送します。
> It
> doesn't extend the structures by making it 32bit-aware but adds new
> variables instead.

32 bits aware ということは UCS4 を考えているのかな? 中国がらみ?
しかし実際にはまず UCS2 だろう、better defined だから。
で、UCS を考えるならグリフと文字コードは分離して当然だから
レイヤが増える分変数も増えるでしょう。
(ICU ...いや IUC か?...に使えるコードはないのかな)


>   . Glyph classes.  We'll need that for defining CJK metrics and kerns
>     in a compact way.

これも考えようによっては大変そうだけれど、妥当な方針でしょうね。

>   . Subfonts.  [I don't mean the splitting of a large font into
>     entities with, say, 256 glyphs each.]  Using a single Unicode font
>     is nonsense.  Instead, groff should provide a means to group fonts
>     into Unicode blocks.  If a new font is registered, it sets some
>     flags to indicate which block is covered.  A mechanism to provide
>     a fallback font is neeed also.  It could also be used for the
>     other way round:  Registering a huge font as many subfonts makes
>     the loading much faster.

これは Xft あたりからコード引っ張れないの? > 佐野さん


>   . Interaction between fonts to implement effects like kinsoku shori
>     (i.e., less space between a CJK and non-CJK character than between
>     two non-CJK characters).  It's not completely clear to me how to
>     achieve that in a simple way.

なんかこれは禁則の説明が間違ってないかい?


> Glyph class や subfont の話は、Unicode での問題として挙げられている
> ものにある程度対応できる枠組として考えられているんでしょうか。

対応できる、というよりは対応するのに必要、という事でしょう。

>  (このへんは (某師匠には叱られそうだけど) いまだによくわかってない)

がんばってください。


> > エンコーディングまわりに関しては、なかなか進まないけど UTF-8 
> > 計画がありますが、言語/用字系ごとに個別のタイプセットのルールが
> > 必要 (つまり言語ごとの個別の処理が必要) ということはエンコーディングを
> > なににするか、ということとは独立した問題ですので、このへんは
> > 日本語パッチからエッセンスを汲み取ってほしいところです。

> 言語に関する処理は環境変数を見るようにする、という話が、私の出した
> 要望に対する返事に書かれてましたね。

Languge tagging ではダメなのかな、もちろん roff で better tagging を
定義しても良いけれど。

まあいずれにせよすぐできる話ではない気がします。

--
のぞみ