Re: [jlreq] 落語ネタ：阿Q正伝から1Q84へ (#324)

和文の明朝体とラテン文字の混植におけるフォントの選択等の問題についてまとめてみた．

 1 文字の画線の太さが一様でない（変化している）明朝体の場合，その線の特徴が似ているラテン文字のローマン体を選ぶ．

 2 文字の画線の太さも似たものを選ぶ（和文のブロックの濃度とラテン文字のブロックの濃度をそろえる）．
 
 3 明朝体の仮名とのバランスを考慮し（明朝体の仮名は漢字の明朝体とは画線の設計が異なる，その意味で仮名は明朝体とはいえないかもしれないが，漢字と合う仮名を作製してきた），その線のカーブが似たものを選ぶ．例えば，ボドニーのように直線的な画線のフォントを選択しない（漢字だけだと似ている感じはあるが）．

 4 字面の大きさを考慮し，また，通常は混組に使用されるラテン文字は小文字が多くなるので，字面が和文とラテン文字との大きさのバランスを考慮し，ラテン文字はできるだけ“x-height”の大きなものを選ぶ．もちろん，和文よりラテン文字のサイズを大きくする方法もある（DTPではよく行っている）が，機械的な処理を考えれば，同じサイズでよい．

 5 横組（縦組で文字を横に回転した場合を含む）の場合，仮想ボディの天地左右中央の位置にある和文に対し，短字のラテン文字，あるいは大文字をを並べると和文の下端（縦組では左端）より，字面が上がって（縦組では右に寄って）見える．しかし，この位置を変えるとアッセンダーとデッセンダーがある小文字が行間にはみ出してしまうかもしれない．そこで，和文と欧文の仮想ボディの位置を揃えるしかないということになる．多少は不満が残るがやむをえない．

 6 和文フォントにはプロポーショナルのラテン文字を含んでいる例が多い（以下，付属文字という）．そこで，ラテン文字に，この付属文字を選ぶか，別のラテン文字のフォントを選ぶかが問題になる．和文文字を組み合わせるラテン文字の条件を前述したが，付属文字は，そのことを考慮して設計されていると思われる．その意味では，通常は，この付属書体を選べばよい．もちろん，その付属書体を使用しないで，別のフォントを選ぶことも可能であるが，その選択は，それなりに経験のいることであり，それをデフォルトとする必要はないであろう．

　7　フォントの選択にもよるが，ラテン文字の行送り方向の字面と仮想ボディとの空白（サイドベアリング）は，和文文字より狭いのが一般的である（1字1字の独立性がややある和文文字と主に単語を単位に読んでいくラテン文字との差異による）．そのような和文文字とラテン文字をベタ組で配置すると，和文とラテン文字の字間が詰まった印象を与える．そこで，活字組版時代には，和文とラテン文字の字間として四分アキにしていた．今日では，この和文とラテン文字の字間は，必ずしも四分アキにする必要はないが，なんらかのアキを確保するのが望ましい．（混植のパターンもラテン文字1字の場合，単語の場合，複数の単語の場合，文字種もアラビア数字，小文字，大文字といったように各種のパターンがあり，一律の処理を前提にしたときは，個別ケースでは多少はバランスを欠く配置となるケースも出るが，それはやむを得ないことであろう．）

 8 和文の（ある程度の画線の太い）ゴシック体との混植について，少しだけ補足しておく．和文のゴシック体との混植では，以下の2つの方法がある．
 a ラテン文字のサンセリフと混植する
 b ラテン文字のローマン体で画線の太いボールドと混植する
この場合，aは画線のデザインと画線の太さをそろえているのに対し，bが画線の太さだけをそろえている．和文でもゴシック体の漢字とアンチック体（明朝体風の仮名で画線を太くしたフォント）の仮名を組み合わせる例があり，それなりにバランスをとれているので，bの選択もありえるが，通常は，aの方が望ましいといえよう．（ゴシック体の漢字とアンチック体の仮名の組合せは活字組版時代にも行われていた．ただし，その当時は仮名のゴシック体のデザインに優れたものがなかったので，やむなくアンチック体を選んだことによる．最近は漫画の台詞では積極的にゴシック体の漢字とアンチック体の仮名の組合せが選ばれている．これは漢字と仮名との差異をある程度とることにより，漢字という語句のまとまりをはっきりさせるという効果を考えたものと考えられる．）

-- 
GitHub Notification of comment by KobayashiToshi
Please view or discuss this issue at https://github.com/w3c/jlreq/issues/324#issuecomment-1014975890 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 18 January 2022 00:40:28 UTC