- From: Kobayashi Toshi <binn@k.email.ne.jp>
- Date: Mon, 07 Jul 2025 12:44:51 +0900
- To: Taro Yamamoto <tyamamot@adobe.com>, Yasuo Kida <kida@mac.com>, JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Cc: 浦山毅 <urara2116@gmail.com>
木田 様 山本 様 みなさま 山本さん,Natさん,コメント,ありがとうございます. 小林 敏 です. Taro Yamamoto さんwrote >> A案 ボディ……現在書いているドキュメントで採用されている言い方.つまり,ボディとは,文字を正立させた場合の文字の左右の大きさ(幅)と上下の大きさ(高さ) > >ボディという考え方は、和文フォントのように横組みだけでなく縦組みでも用いることができる、プロポーショナルでないフォントに含まれる、主要なグリフ集合(例えば漢字や仮名グリフ)に当てはまるものです。なぜなら、それらのグリフの字幅(字送り量)は横組みでも縦組みでも等幅だからです(これは長体・平体フォントについてもいえるでしょう)。ただし、それらの場合でも、そのフォント中に含まれる欧文のグリフは、多くの場合、和文グリフのボディの範囲内には収まらないので、それらの欧文グリフについては、横組み時の字幅しか存在しない、ということになると思います。つまりボディは存在しません。 ボディが実際に存在するか,それともしないかは,ここでは問題にしていません.あくまで,説明のための用語です.だから,文字を配置していく際に文字の占める領域について,幅と高さといっても同じことです.ただ,縦組と横組があるので,幅だ,高さだというよりは,ボディ(つまり矩形)だ,という方が説明が簡単だからです. 少なくとも,横組でも縦組でも,文字を並べていく場合に,それぞれの文字は,必ずなんらかの領域を占め,行の調整処理がない場合,原則として,それぞれの領域を密着させて配列していきます.そして,そのことを説明するためにボディといっているにすぎません.あくまで説明の便宜のためです. というのは,このドキュメントは,基本的に写植モデルでなく,活字モデルで説明しているからです.この2つは,説明が異なるだけで,基本的には同じことをどう説明するかということで,写植モデルより,活字モデルの方が直観的で分かりやすいからです. 文字サイズが異なる場合や,約物の連続時のアキを説明する際には,写植モデルは,かなりやっかいです. いずれにしろ23日に,これは議論しましょう. >> B案 左右の幅…字幅(これは現在書いているドキュメントでも使っている) > 上下の高さ…文字の高さ > >和文フォントに含まれている欧文グリフであれ、そうでない純粋な欧文フォントのグリフであれ、字幅は存在しますが、上下の高さは、欧文グリフを包含する最小の矩形(BBOX)の上辺と下辺との間の距離をグリフの高さと考えることは可能です。そして、この寸法には通常descenderからascenderまでの距離を計測して決めることになります。ただし、字幅とは異なり、この寸法はサイドベアリングを含みません。 実際にどのような値になるかは,後の問題で,ここでは,ドキュメントで,どのよう用語で,どう説明するかが問題です.この問題は,“問題2”で問題にしましょう. > サイドベアリングという語は、文字を側面(side)から保持する(bearing)活字ボディのマージンを意味しているため、伝統的には天地方向には使いません。しかし、漢字や仮名のようなグリフの場合には、天地のマージンのこともサイドベアリングと便宜上呼んでいる場合もなくはありません。ただ、それは欧文のグリフにはあてはまりません。 それでは,上下については,サイドベアリングという用語は,使わない方よいということですね. 問題2 文字の幅と高さ,特に“高さ”とは何か? ボディの高さ,または文字の高さの説明は,どう考えたらよいか? A案:それぞれのフォントの文字が持っているボディの高さ(文字の高さ)による. と言って,それ以上は何もいわない. B案:それぞれのフォントの各文字が持っているボディの高さ(文字の高さ)による. 例えば,以下は,次のようになるという説明を加える. 以下,B案とした場合 >日本語フォントの中に入っているプロポーショナルの欧文グリフには当てはまりませんが、欧文フォントの'OS/2'テーブルのsTypoAscenderとsTypoDescender(およ’現状では、和文フォントに含まれる正立の全角欧文については、縦組みで天地方向で和文の全角の中心にくるように'VORG'テーブル内の情報を使って位置を調整している和文フォントもありますが、プロポーショナルの欧文グリフについては、そのような縦組みのための調整は行われていないと思います。また、アプリケーションもプロポーショナルの欧文グリフを縦組みで正立させて組むことは、とりあえず数字や大文字だけの短い略号であれば、(単純に全角の中心で90度回転して)和文の全角に収めただけでも、組めないわけではない、という以上の視覚的な調整はしていないように思います。(Nat might correct me if I make any errors about this.) B案:それぞれのフォントの持っているボディの高さ(文字の高さ)による. 例1 日本語フォントの付属するプロポーショナルなラテン文字およびアラビア数字 この文字の高さは,どう説明できますか? >座標空間内でのベースラインの標準的な配置を定義し、仮想ボディの位置の上端と下端を定め、その仮想ボディをポイントサイズの高さとして宣言する必要がありました。 ということは,日本語フォントに付属するプロポーショナルなラテン文字では,ボディの高さ(文字の高さ)は,定義されており,各文字は,その値を持っているということか? 例2 日本語フォントの付属する全角のラテン文字およびアラビア数字 この文字の高さは,どう説明できますか? なお,フォントによっては,ラテン文字のグリフをボディの天地中央に配置しているものもある.(これは縦組の字形ということか,横組でもそうなるのか?) 例3 ラテン文字を主にしたフォント(別の言い方はできないか?) > hhea’テーブルのAscenderとDescender)には上記の意味でのascenderとdescenderの情報が含まれています。 > 欧文グリフを包含する最小の矩形(BBOX)の上辺と下辺との間の距離をグリフの高さと考えることは可能です。そして、この寸法には通常descenderからascenderまでの距離を計測して決める ↓ 欧文グリフを包含する最小の矩形(BBOX)の上辺と下辺との間の距離をグリフの高さ.通常descenderからascenderまでの距離である.この場合,和文文字のボディの高さ(文字の高さ)と同じとなるかどうかはフォントによる.(といってよいか?)
Received on Monday, 7 July 2025 03:48:11 UTC