Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

文字サイズなどが異なる括弧等が連続した場合の処理 #39

Open
KobayashiToshi opened this issue Nov 14, 2023 · 1 comment

Comments

@KobayashiToshi
Copy link
Contributor

文字サイズなどが異なる括弧等が連続した場合の処理としては,複数の処理方法が考えられるが,どう考えたらよいだろうか?

@KobayashiToshi
Copy link
Contributor Author

KobayashiToshi commented Nov 14, 2023

文字サイズなどが異なる括弧等が連続した場合の処理

JLReqでは括弧等が連続する場合の処理については,括弧での補足説明を挿入する場合,本文より小さい文字サイズの使用を暗黙の前提として解説している.最近は,書籍等でも本文の文字サイズよりは大きなサイズの使用した例がある.ここでは,大きな文字サイズも含めた方法を解説する.

問題は,約物が連続して字間を空ける場合,基準にするアキは,前の文字サイズか,後ろの文字サイズか,それとも,平均かという問題である.これまでの書籍や雑誌において「……」(……)とあった場合,後ろの括弧の文字サイズを小さくするのが一般的であった.これを前提にし前記の例では,“」”と“(”の字間は,前の文字,つまり“」”の文字サイズの二分アキと規定している(字幅は二分が前提).

注 活字組版では,行中に,その段落で使用している文字サイズより大きなサイズにすることは,かなり面倒であり,一般に挿入される異なるサイズの文字は,一般に小さくしていたことの反映している.

最近では,行中の,その段落で使用している文字サイズより大きなサイズの文字を挿入することも簡単にできる.どんな場合でも適用できる方法を考える必要がある.以下,その考え方を示しておく.なお,約物の前後のアキを含めて,その字幅が全角(文字サイズ)でない場合も含めた処理方法とした.

約物が連続し,字間の調整を必要とするケースは,大きく分けると,以下の3つがある.
A 句読点や括弧類(以下,句読点と括弧類を併せて括弧類等という)が連続する場合
B 中点類と括弧類等が連続する場合
C 和字間隔(全角スペース,U+3000)と括弧類等が連続する場合

BとCは,原則として,中点類や和字間隔(全角スペース,U+3000)の前後に配置される括弧類等の後ろ又は前にあるアキを削除して配置すればよいので,文字サイズ等の差異があっても問題とはならない.なお,プロポーショナルの中点類で見た目のアキがない場合も,同様に,その前後に配置される括弧類等の後ろ又は前にあるアキを削除すればよい.

問題はAである.ただし,Aは以下の4つのケース(実例が考えられるのは3つ)があるが,問題はaのケースだけである.(なお,句読点は“終わり”に含める.)
a 終わりの括弧類等の後ろに,始めの括弧類等が連続
b 始めの括弧類等と,始めの括弧類等が連続
c 終わりの括弧類等と,終わりの括弧類等が連続
d 始めの括弧類等の後ろに,終わりの括弧類等が連続

dは,実例はほとんどない(あれば2つの括弧類等の字間をベタにすればよい).bとcは,前又は後ろの括弧類等の見た目のアキを削除すればよいので,文字サイズ等の差異があっても問題とはならない.

以上のB, C及びAのaは,見た目のアキとアキが連続するので,見た目における規定のアキより大きくなってしまう.そこで,調整が必要になる.

これに対し,Aのb及びcは,理由が異なる.句読点の前,括弧類の内側は,それに連続する文字との接続の関係が強い.そこで句読点の前,括弧類の内側には見た目の見た目のアキを入れることは,特別の場合(ルビのはみ出しが多い等)を除き避けたい.行の調整処理の空ける調整でも,調整の優先順位でできるだけ後にしている.Aのb及びcでは,前又は後ろに配置する括弧そのものが見た目のアキを持っているので,句読点の前,括弧類の内側は空けないという原則を実現するために調整が必要になる.

以下では,aに限り,その処理を考えてみる.aの場合は,前又は後ろの括弧類等との間に見た目のアキを確保する必要があり,文字サイズ等の差異があった場合,その見た目のアキの大きさが問題になる.

注 aの見た目のアキを詰めない処理(見た目では全角アキとなる)は,bやcの処理を行わない(見た目では二分アキとなる)と比べると,いくぶんバランスの悪さは低いと考えられる.ベタと見た目のアキのある場合の差異は誰でもが気がつくが,アキの大きさは,注意しないと気がつかないこともある.例えば,早川書房の書籍では,bやcの調整は行っている(ベタにする)が,aの調整は行わないで,見た目の全角アキを許容している.(このことからいえば,aの調整したアキの量は,ある意味,許容範囲があるので,厳密に決めなくてもよいのかもしれない.)

文字サイズ等が異なる場合のaの調整では,前後に配置する括弧類等の後ろ及び前にある括弧類等の見た目のアキ(一般に二分くらい)を削除,その間の見た目のアキを決める必要がある.この見た目のアキを決める基準としては,以下のような方法が考えられる.(なお,プロポーショナルの括弧類等で,見た目のアキがない括弧類等を含む場合は,字間の調整は行わない.両方ともに見た目のアキがない場合はベタとなり,片方に見た目のアキがない場合は,見た目のアキのある括弧類のアキをそのまま維持する.)

1 前に配置する括弧類等の文字サイズを基準とした見た目の二分アキ,又は,前に配置する括弧類等の文字の後ろの見た目のアキが二分でない場合,そのアキ(例えば三分)とする.つまり前に配置する括弧類等の見た目のアキを基準にし,後ろの配置する括弧類等の見た目のアキを削除する.(この方式は,前述したようにJIS X 4051で規定している方法である.)

注 この考え方を逆に,後ろに配置する括弧類等の文字サイズを基準とした見た目の二分アキ,又は,後ろに配置する括弧類等の見た目のアキが二分でない場合,そのアキ(例えば三分)とする,という方法も組合せからは考えられる.しかし,実例もなく,その理由もないと考えらえるので,ここには採用しなかった.

2 見た目のアキを,その段落の文字サイズの二分とする.前後に配置する括弧類等の文字の後ろにある見た目のアキが小さい場合(例えば三分)も同様とする.

3 前に配置する括弧類等の文字の後ろの見た目のアキの1/2,及び後ろに配置する括弧類等の文字の後ろの見た目のアキ1/2とする.例えば,括弧類等の文字の前後の見た目のアキが二分で,前が10ポイント,後ろが12ポイントの場合は,見た目のアキは5.5ポイント(5.5ポイント詰める).文字サイズは両方とも12ポイントであるが,片方の文字の見た目のアキが三分の場合は,6/2+4/2=5の計算から5ポイントとなるように詰める(5ポイント詰める).両方の文字の平均をとるという方法である.

4 文字サイズの大きい方又は見た目のアキの大きい方を基準とする.例えば,前後のアキが二分で,前が10ポイント,後ろが12ポイントの場合は,見た目のアキは6ポイント(5ポイント詰める).文字サイズは両方とも12ポイントであるが,片方の文字のアキが三分の場合は,見た目のアキの大きい方を基準にして,見た目のアキは6ポイント(4ポイント詰める).両方の文字の見た目のアキが三分の場合は,4ポイント(6ポイント詰める).

5 文字サイズの小さい方又は見た目のアキの小さい方を基準とする.

注 注記番号で,“……である」(1)”とあった場合,注記番号の文字サイズは小さくする.この場合,前に配置する大きな文字サイズの“」”を基準とすると,注番号と前の“」”の字間は空き過ぎに見える.こうした場合に5は適用できる考え方である.しかし,このような注記番号と前の括弧が連続する場合の字間はベタにした方が望ましく,この方式を採用しなくてもよいことになる.

前述したように,aのケースのアキは,ある意味で,許容範囲があるので,1–5のいずれでもよいと考えてもよいが,3又は4が,ある種の合理性を持っていると思われる.見た目では,優先的な(つまり大きな文字サイズ)の文字のアキが確保される,ということを考えれば4ということになろう.また,1は,読んでいく順序で最初に出てくるので,それを優先するという考え方もできる(始めと終わりのアキが均一にならないという問題も出るが,見た目のアキの大きさにもよるが,それほど気にはならないであろう).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant