JLReq-d 編集会議 2025-1-22

JLReq-d 編集会議 2025-1-22

https://github.com/w3c/jlreq-d/discussions/78



出席者
敏先生 @KobayashiToshi, 山口さん @yamahige, 山本さん @taroyamamoto-451, 木田 @kidayasuo 

ノート
前回作った「9.x 箇条書き」のドラフトを、その後の議論 <https://github.com/w3c/jlreq-d/discussions/74#discussioncomment-11556780>をベースにアップデートした。下に示す。チェックイン済み <https://github.com/w3c/jlreq-d/blob/gh-pages/drafts/4.%20Basic%20Architecture.md>
「2.4フォント：欧文書体の合わせ方」について議論した。和文に欧文を合わせる場合にどのようにすれば良いのか、について意見を交換した。なかなか良い議論になった。メモを下に示す。
次回3/11火曜日9時から。「2.4フォント：欧文書体の合わせ方」の今日のメモをもとに、ミーティングまでに木田が荒ドラフト。それをベースにドラフトを作る。


------------------
### 9.x 箇条書き <https://github.com/w3c/jlreq-d/blob/gh-pages/drafts/4.%20Basic%20Architecture.md#9x-%E7%AE%87%E6%9D%A1%E6%9B%B8%E3%81%8D>

箇条書きはラベルと本体で構成される。ラベルにはビュレットのような同一の記号を繰り返し用いる場合と、順序を表す文字を用いる場合とがある。箇条書きは階層的に用いられる場合もある。

同一の記号はビュレット、中点、米印、アステリスク、ダッシュ類、矢印、などが使われる。

順序を表す文字には次のような例がある。
• アラビア数字（1, 2, 3 など）
• ローマ字（A, B, C など）
• ローマ数字（I, II, III など）
• 漢数字（一、二、三 など）
• 日本語のひらがな、カタカナ（あ、い、う や ア、イ、ウ など）
• 丸中数字①などの囲みつき文字
また、これらの文字を括弧類などで囲む場合や、末尾にピリオドなどの文字を加える場合がある。また、階層構造を示すために、複数の順序を表す文字をピリオドなどの文字で区切る場合がある。

ラベルの位置と本体の位置を決める方法には、本体の位置を固定的に決める方法と、ラベルの末尾から本体までの間隔で決める方法とがある。また、本体の二行目以降のインデントを設定できる必要がある。

また、ラベルの配置は、左揃えと右揃えがある。特に、ラベルの長さが一つの箇条書きの中で変化する場合（例必要）に右揃え、左揃えを選択できることが重要になる。

順序を表す文字を括弧類で囲む場合、括弧類に含まれる空白を取り除く場合と保存する場合がある（約物の空白の処理参照）。本体の先頭および後続行の先頭は行頭として扱い、これらは5章で述べた括弧類の処理に従う。

#### 縦組みの箇条書き
縦組におけるラベルには横書きにない処理が必要となる。

アラビア数字、ローマ字、ローマ数字など通常縦書きで横倒しにされる文字であっても、ラベルに使う場合は縦中横にし、左右中央にする。これらの文字を括弧類などで囲む場合、アラビア数字、ローマ字、ローマ数字だけを縦中横にする方法と、括弧類を含めて縦中横にする方法とがある（図示）。

> 横倒しにされる文字は必ず縦中横。

順序を表す文字の末尾にピリオドなどの文字を用いる場合、ピリオドなどの文字は縦中横にしない（図示）。この場合一般的にはピリオドではなく、読点が使われる。

> サイドノート：全角数字、半角（プロポーショナルではなくて半角）のグリフを組み合わせて使うことを書く。注意：半角グリフとプロポーショナルグリフを混同してはならない。デザインが違う場合がある。フォント依存。OpenTypeフィーチャーに半角、三分などがある。ここでは書かない。全角に収めたい場合には半角2桁は便利。他のところで書く。第8章。



—————————————
欧文書体との合わせ方 <https://github.com/w3c/jlreq-d/discussions/78>

日本語コンテキストであって特に意図のない場合は、日本語フォントに含まれる英字を使うのが賢明である。そのフォントの和字と使われることを念頭に、上下位置、サイズ、ウェイト、などを揃えてデザインされているからである。

合わせる場合にはこうするよ：


#### 山本さん
1. 様式的にあっている。スタイル的にあっている。本来合わないもの。近似的なものでしかない。考え方による。例えば：現代的な明朝体。カウンタースペースが大きい（字面が」大きい）コントラストが大きい。欧文においても同様なテイストを持っている。bodoni。
2. 大きさと太さとカウンタースペースを合わせることが重要
 1. 大きさ：ボディの制約から解放されてしまっているので、同じポイントサイズでも大きいものから小さいものまで。日本語書体よりもばらつきが大きい。小さすぎることが多い。拡大して組み合わせることが必要なことが多い。書体のサイズを変更できない場合には、大きなものを持ってくるのに苦労する。
  1. 特に一般的な指針はない。あったら苦労しない。バランスの問題。いろんな問題が相互に依存しているので。
	2. 太さ：sans-serifの場合は置いておいて、明朝体と合わせるのに、serifを持ってきた場合には、純粋なローマン体はステムの縦線が太い傾向がある。拡大するとさらに差が大きくなって太くなる傾向がある。細いローマン体は少ない。非常に苦労するわけだ。
	4. だから、悪いことは言わないから**従属欧文を使っておけ！**
	5. どうしてもやりたい場合には、上記のことを考えて選んでくるという問題に直面するんだよ。グッドラック
	6. ベースラインの問題。和文の全角と欧文のベースラインの位置関係が固定的だった。便宜的、恣意的にに-120のいちに全角の下辺が来るようになっている。が、これは別に最適な値というわけではなく、便宜的に決めたものである。
 7. だから従属欧文を使えって
 8. 理想的にはユーザーやデザイナーがベースラインの位置を設定できるようにすべき。インデザインでは：欧文書体の中のベーステーブルの中に ideographic mboxと言う属性があって和文のボディがどこに来るべきかという情報がある。その情報を見て、cap heightが全角の中心になるように位置調整をする。が、欧文書体の中のベーステーブルの中に ideographic mboxを持っているフォントは多くない。（かつ正しくない？）。その場合には-120を使う。
	9. もう一つ視覚的に重要なのはカウンタースペース。現代的で懐の大きな和文の中に古風なカウンタースペースの狭いギャラモンドなどを合わせると違和感が出る場合がある。
	10. 大文字 (cap height) と小文字 (x height) の差が小さい方が合わせやすい。オールドスタイルは小文字が小さい傾向。transitional大きめに。times new romanのような新聞書体、差が少ない。新聞の粗悪な紙に耐える。sans-serifは歴史的に見出しように作られているので、x height大きい。60%。和文書体も字面の大きい小さいがある。ディセンダとアセンダは決定要因ではなくて、x heightと cap height と全体の大きさのバランスが重要。

#### 敏先生
1. 大きさ：大文字だけ、小文字だけの場合には良いけれど、小文字中心の場合には小文字と和文とのバランスを考える必要がある。（記号的に大文字中心の場合には大文字と和文とのバランスを考える。（個別的な対応の問題）。
2. 太郎さん：大文字の中心を和文のボディの中心に合わせる。
3. 曲線の性質：漢字とひらがなのカーブの調子が全然違う。bodoniのような現代的なローマンはひらがなに合いにくい。（太郎さん：様式のマッチングについて一般的なことは何も言えない）
4. ウェイト：和文よりはラテンを若干太めにしたほうがバランスが良い。（太郎さんも同じ意見。ただし、最近の書体は違う傾向和文のにできるだけ近づける方向。欧文が和文に対してあまり目立たないような調整）
5. 字幅：コンデンスは合わないよ。カウンタースペースにも関わる。げんのかく：ウェイトごとに字幅も調整している。

#### 山口さん
- 同じカッコなのに、和文用と欧文用を区別しなければならない現状について。
- 木田：現状のUnicodeではユーザーが意識して「正しい」括弧文字コードを使い分ける必要があるが、いつか未来には、「括弧」と言えばシステムがよろしく適切な括弧のグリフを出してくれる世界が来るといいと思う。jlreq-dでの話題ではないかもしれないが、心に置き続ければ良いのではないか。