なんでやねんDTP・新館

はてなダイアリーから移行しました…

「文字組みアキ量設定」で区切り約物の後ろに全角分のアキを挿入

先日、知人のtwitter上でのある報告が気になって検証してみました。

それは、「文字組みアキ量設定」をカスタマイズして、区切り約物「!?‼⁉⁈⁇」と後続の両仮名や漢字の間に全角アキ挿入を実現したいのだけれど、「‼⁉⁈⁇」があるとその行全体の字間がツマリ気味になるという報告…

まずは、以下のようなテキストを用意しました。

(ちょっとミスして、上の作例は既に適用してありますが…)「文字組みアキ量設定」そのものは、前の文字クラス=「区切り約物」と後の文字クラス=「平仮名/カタカナ/上記以外の和字」間の「最適値」と「最小値」を「100%」とすれば済みそうですのでごく簡単ですね(作例はデフォルトで用意されている「行末受け約物全角/半角」を元にカスタマイズ)。

で、「‼⁉⁈⁇」の部分には正規表現スタイル」でOpenType機能の「任意の合字」を適用すると…

報告にあったように、画像の通り字間がツマってしまっています(きっとバグでしょうね)。

この原因が「‼⁉⁈⁇」に適用した「任意の合字」にありそうなことは容易に推測できますね。
それではと、「任意の合字」を解除して既存の合字として用意されている U+203C, 2047, 2048, 2049 などを直接打ち込むと…

うーん、ヨコに寝てしまいますね…

なので「縦中横」を適用してみると…

うーーんん、正立しましたが今度は「アキ」がなくなってしまいました…

が、しかーし、「縦中横」ではなく「文字回転=90°」を適用すると…

ということで、なんとか解決しました。

ただし、「!?」は「行頭禁則文字」に登録されていますが、「‼⁉⁈⁇」は登録されていないので、これらを追加登録することも忘れてはなりません。

※区切り約物「!?‼⁉⁈⁇」は(StdやProなどの)文字セットによっては範囲外となっているモノがありますのでご注意ください。

合成フォントに躓きました…

この記事は、DTP Advent Calendar 2018の12日目の記事です(最後に残った1枠でございました…)。

いま現在進行中の案件でタテ組みの「合成フォント」を組んだ際にちょっと躓いたので、経緯を纏めておきます(アプリケーションはInDesign CS6です)。

デザイナーさんからのフォーマットは「合成フォント」と書いてはあるものの、「正規表現スタイル」で指定してありました。
段落スタイルの内容は【[\d\l\u\l\ \”\@]+?】に文字サイズを110%拡大した欧文フォントを充てるというモノで、文字揃えは(タテ組みですから)「仮想ボディの中央」で、「1行取り」とされていました。
「1行取り」とする理由は、欧文部分を「110%」にしてありますから、グリッドに収まらずに2行取りとかになってしまうからですね。
※これは(110%とする)文字スタイルの「文字の比率を基準に行の高さを調整」のチェックを外せば特に問題ないでしょう(合成フォントではこの問題は起きないのはご存じの通り)。

この正規表現スタイルを利用して合成フォント風の表現を実現する方法は知ってはいるのですが、ベースラインを弄る場合には文字サイズ毎に文字スタイルを作成する必要があるため私は使うことに二の足を踏んでいました。

また、この支給された正規表現スタイルではピリオドやコンマあるいは一重引用符や閉じ側の二重引用符やダーシ類に欧文書体は適用されませんね。

なので、とりあえず合成フォントを組むことにしました(あらかじめ仮名書体を使うことや、U+02D9を使って文字を作る必要があるということが判っていたこともありますが…)。

  • 2種の引用符とU+2014は「特例文字」で設定しました
  • 「¨」U+00A8は合成フォントの分類では全角記号となっています。

まず第一の躓きは、合成フォントを作成する際にベースラインを弄らなかったこと。
合成フォントで適用できる範囲外のラテン1補助やラテン文字の拡張AおよびBなどの(一部の)文字が出現すると「文字スタイルを適用」…としたのですが、当然ベースラインが微妙に異なりますね(これは判っていたことなのですが…)。


合成フォントは欧文ベースライン揃えの状態から文字サイズを110%としているのに対し、正規表現スタイルで適用した場合は「文字揃え=仮想ボディの中央」の設定に応じて文字の位置が決まります。なので当然の結果ですね。

  • 下はすべて合成フォント
  • 「¨」U+00A8の左右のアキが異なることにも注目してくださいね(上が正常)

まあ、文字スタイルでベースラインを弄ってもいいのですが、それでは本末転倒ですし、括弧内の文字サイズは小さくしたり、後注部分などを含め数種類の文字サイズが出現するため文字スタイルがそれだけ必要になります(ただし、今回の場合はベースラインを弄る必要はなかったのですが…)。
なので、これを解消するために合成フォントの「特例文字」で
ラテン1補助の一部やラテン文字拡張A [\x{0100}-\x{017F}]、ラテン文字拡張B [\x{0180}-\x{024F}]、ギリシャ文字 [\x{03840370}-\x{03FF}]*1などなどを追加し(合成フォントの半角欧文との重複は特に問題なしと理解)、ついでにベースラインを、(「文字揃え=仮想ボディの中央」で110%拡大した場合の位置に揃うように)1.8%上へ移動しました。

これで大丈夫と思いましたが、さらに落とし穴がありました。
画像をご覧いただくと、引用符にはアキ量設定の半角アキが適用されているようなのが判りますね(ギリシャ文字の一部などにも不自然なアキが発生しています)。引用符として使う場合は欧文スペースとセットで使うことが多いでしょうから気づかないのですが、アポストロフィとして使う場合にはアキを削除する必要が出てきますね。
さらに、合成フォントを組んでもギリシャ文字部分はタテ組みでは正立してしまう文字種が多いようです。

結局、合成フォントを組む場合は、少なくとも「引用符」と「ギリシャ文字」は正規表現スタイルで欧文フォントを適用する方がいいということになりました。

結論としては、ベースラインを特に弄る必要がない、あるいは(ベースラインを弄るとしても)使用する文字サイズのバリエーションが少ないのであれば、正規表現スタイルで合成フォント風の表現を実現するのが一番ラクだろうということに……。

ということで…「今更なにを」的なことになってしまいました。

但し、そのように正規表現スタイルで文字サイズを大きくした欧文は、正立させるとその文字サイズの字送り量になってしまいますので、正立させる部分があるなら「合成フォント」を組む方がラクですね。(この部分、20190820追記)

※合成フォントとギリシャ文字の件については、中嶋かをりさんが先日言及されていましたね。→「InDesign上でのギリシャ文字のおかしなふるまい

 

*1:ギリシャ文字拡張 [\x{1F00}-\x{1FFF}]

プラスのトラッキングのかかった文字列とルビ

前回の記事で言及したように、ラッキングをかけた文字列を親文字としてルビを振ると親文字とルビにズレが発生します。
この原因はラッキング量を含めて親文字の幅とされ、その幅に対してルビが配置される所為だと考えられます。
InDesignでは「字送り」と表現するようですが、私的にはあまり馴染まない…というか嫌いですので「トラッキング」という用語を使用させていただきます。

今回はそのような際に、ルビ位置を補正する方法を解説してみようと思います。
※基本的には「1-2-1ルールの中付きルビ」としますJIS 1-2-1ルール

  • 全体的に組版単位はQ(H)で進めていきますが、各自読み替えていただければ…
  • 今回の記事ではプラスのトラッキングの際の挙動について解説しますが、マイナスのトラッキングでもズレは発生します。ただ、それを補正する際の考え方が少々異なりますので別の機会に…

理解し易いように、大小2種類のトラッキングを施した文字列を左右に並べて、双方を比較しながら見ていくことにしましょう。

●モノルビの場合

このようにトラッキング量を含めた幅に1-2-1ルールでルビが配置されているのが見てとれます。→ この場合の1-2-1ルール
これを補正するには…

図中に示した通り、「揃え」を「中付き」にして、トラッキング量をQ(H)数に換算して、その半分をシフトしてやればいいのが判りますね。
 左:32Qで+250の場合 → 32×250/1000×1/2=4(H) → 参照
 右:32Qで+500の場合 → 32×500/1000×1/2=8(H) → 参照

つまり、(本来の)親文字をオーバーする幅=文字サイズ×(プラスのトラッキング量/1000)、そして シフト量=親文字をオーバーする幅×1/2……ということになります。

●グループルビの場合

この場合もトラッキング量を含めた幅に1-2-1ルールでルビが配置されています。→ この場合の1-2-1ルール

シフト量などの基本的な考え方はモノルビの場合と同様に考えればいいのですが、グループルビの場合は、「1-2-1ルール」準拠とするなら、ルビ文字間にも適切なアキが必要になりますので、単なる中付きでは困りますね。なので…

ご覧のように、例示はしてみましたが、トラッキング量や親文字数とルビ文字数の関係などによって最適解は異なってきますので、試行錯誤して(ベタ組みの場合の配置を参考に)最適解を探し、場合によっては適当な体裁で妥協することも必要でしょう。
作例の場合は、「(ルビ)揃え=均等アキ」でいいですかね? いや+500の場合はルビ間がアキ過ぎかも知れません。また+250の場合は中付きでルビ文字間に欧文スペースふたつでもいいでしょうし、+500もその方がいいかもしれません。なにしろ様々な要素によって最適解は異なってくるということをご理解いただければ…。*1

なお、これらは、「段落(文字)スタイル」などに設定してさえおけば、特に手間でもないでしょう。

*1:普段はトラッキングによるアケ組みはほとんどしないので、今日の今日まで、グループルビ中に欧文(半角)スペースが有効だということに気付いていませんでした…のです…w…

「字取り」の設定方法

組版の現場において「字取り」という用語があります。「一定の文字サイズで一定の字数分の組み幅に文字を均等に配置すること」をいいます。
その「字取り」を実現するには様々な方法があり、使う場面やアプリケーションによっても最適解は一つではありません。

少し挙動が異なる部分がありますので、InDesignを中心に解説していきますが、Illustratorについては、補足的に有効かどうかを記すようにします。

まずはもっとも簡単に思える、フレームサイズを一定にして揃える場合から…

●「両端揃え」
Illustraror上での挙動は異なりますので末尾に補足します

以下のように人名などを5字取りで揃える場合、フレームサイズを5字分(目的の揃え幅)としてあれば、1字分として開けたい部分には全角スペースを挿入しておき、行揃えとして「両端揃え」*1を適用すればすんなりと解決すると考えがちですが、実際はそうではありません

画像(下)に示したような結果になります。見ると判ると思いますが、和字間隔(全角スペース)の部分の送りが和字部分のそれよりも狭くなっており、求める結果とは異なります。

その原因は「文字組みアキ量設定」にあります。デフォルトで用意されている「文字組アキ量設定」の画面は以下に掲げるような内容ですが、14種類のすべてが同様の設定になっています。

和字間隔(全角スペース)と両仮名(ひらがな/カタカナ)や漢字(上記以外の和字)の関係を見ると、和字間隔が「前」か「後」かで最大値が異なります(100%と0%)。
つまり行長調整の必要が生じた場合には、(前)和字間隔:(後)和字の場合には最大で文字サイズの100%までアキを割り振りますが、(前)和字:(後)和字間隔の部分にはアキを割り振らないという設定です。

一方、和字同士の場合の最大値は上に掲げた通り100%…これでは並びにズレが発生するのは当然ですね。
因みに +DESIGNING さんのサイトで公開されている拙作の最新版*2では当該箇所は共に100%と変更してありますので、当然のことズレは発生しません(下の画像参照)。


これ以後の部分は、文字にアキなどを設定しますので、フレームサイズに関係なく文中でも有効です。但し、適用する範囲には注意が必要です。

●文字前・後のアキ量
Illustratorにも有効です

追加が必要なアキ量を計算して字間数で割り「文字前・後のアキ量」を適用するのもひとつの方法です。

  • 作例では行(文字列)頭から「文字後のアキ量」を適用しましたが、行(文字列)末から適用する場合は「文字前のアキ量」を適用します
  • 例えば、2字分を3箇所に割り振るなら2/3となりますが、「2/3」という選択肢はありません…なので、そのような場合はアキの必要な部分の文字の前後に「三分アキ」を挿入すれば「1/3+1/3=2/3」となります(臨機応変に考えましょう)

●トラッキングと字取り
Illustratorには「字取り」の機能はありませんが、トラッキングは有効です

ラッキングは、先のアキ量をトラッキングに換算して適用すればいいだけです。
また、InDesignのフレームグリッド内ではそのフレームグリッドに設定されている文字サイズを基準にした「字取り」が可能です。*3

  • ラッキング値の計算方法は、1字分=1emとし、n/1000em単位で設定します。例えば2字分を字間5箇所に割り振るなら、2000/5ですから「400」を設定します。
  • 上のトラッキング例の場合は1/1000emの誤差が発生していることになりますが、データを見ない限り気付かれることはほとんどないでしょう

但し、ラッキングを適用した文字を親文字としてルビを振るのはNGです。以下の通り親文字の範囲が不正になります。

他の方法では「ルビ」に関しては特に問題はありません。

以上の段落パネルおよび文字パネルでの設定場所は下の画像の通りです。

Illustratorの両端揃えの場合

さて、Illustratorのエリア内文字での「両端揃え」の場合ですが…残念ながら以下の通りです。

ご覧の通り、左右とも同じように文字を並べてはあるのですが、行揃えを「両端揃え」とした結果が異なります。左のフレームに入力してあるのはU+25A1の普通の四角です*4

左のようになれば特に問題はありませんが、普通の文字を入力した場合は右のようにしかなりません。

和字間隔(全角スペース)とそれに隣接する(記号ではない)一般的な仮名や漢字との間には行長調整のアキが割り振られないように設定されているのだと考えられます。
が、ご存じのようにIllustratorの「文字組みアキ量設定」は弄れる範囲がごく限られています。つまり(全角スペースを和字1字分同等としたい場合はお手上げです。

Illustratorでは、字取り処理をする目的で揃えるべき幅にテキストエリアの幅を設定し、「両端揃え」を適用して目的の結果を得るということは不可能だと覚えておいた方がいいでしょうね(但し、全角スペースがなければ大丈夫でしょう*5素直に他の方法を採りましょう

*1:「行頭行末揃え」「左右揃え」とも…

*2:右のリンクからダウンロード可能です。(旧版というのはVol.34およびVol.38連動のモノ…最新版はVol.42に合わせて公開したモノ…簡単な見分け方は、旧版は「ベタ用_A」とか「ツメ用_D」と「用」がついていますが、新版は「用」は付けておらず「ベタ_A」「ツメ_D」となっています

*3:こちらは作例を見る限り「文字組アキ量設定」の影響はないと考えられます。また、プレーンテキストフレームでも「字取り」は可能ですが、13Q基準となってしまいますので「出来ない」と考えておいた方が無難でしょう(裏技的に13Q以外に設定することもできますが、ここでは措いておきます…)。

*4:蛇足ですが丸U+25CBや電話マークU+260Eでも同様でした

*5:もう少しツッコんで言ってしまえば、「文字組みアキ量設定」の影響でこうなっているのですから、「文字組み=なし」としてしまえば、スンナリと揃ってしまいます。「なし」はあまり推奨したくないのですが、このような場合はそのようになる原因を理解して使うにはいいかもしれません使うなら特に問題ないでしょうね。尚、InDesignの場合も同様です。