なんでやねんDTP・新館

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

各種記号とコード、文字クラス

ちょっと時間が出来ましたので、以前から作成して利用していた自分用の覚え書きメモを改訂したので、ついでと言ってはなんですけど、ここに公開しておきます。
(画像だけで、テキストは特にありません…悪しからず…)
※キー配列などはMac USキーボードでのものです*1


画像はクリックしていただくと別窓に拡大表示されます


元ファイルのデータを左右A4サイズまで拡大しpdf化したモノ(天地位置はテキトーです)
 → ハイフンなどのマッピング.pdf 直

*1:キーボードに依存するかどうかはわかりませんが、唯一「一般的はハイフン: Pの右上」という表記が気になりますので、念のため…

合成の括弧類に関して…

(「アンカー付きオブジェクト」の続きは少し後回しにして、少しだけ関連のあることを先に……)

全角以上の括弧類を作成するための(合成用の)括弧類はU+239B〜U+23B1に集中しています(画像は ATOKの文字パレット)。

これをそれぞれダブルクリックして InDesign上に直接入力してみました(小塚明朝 Pr6N-R:横組み)。

間にある縦棒(U+239Cなど)は繋ぎ用と思われますが、少し問題があるので削除し、

1文字ずつ改行を挿入して並べたのが以下です(行間アキは「0」)。

これを「縦組み」に変更してみると……

  • 縦横変換されます


ここまでは「小塚明朝 Pr6N-R」でしたが、全選択して「小塚ゴシック Pro-H」としてみますと……


  • 最後のU+23B0とU+23B1はCIDコードが16312と16313なので、Adobe-Japan1-5(Pt5)以上のフォントでないと実装されていません…なのでこの部分は変化はありません(小塚明朝 Pr6N-Rのママ)

さらに、全選択して「A-OTF A1明朝 Std」としてみますと……

  • 何の変化もありません(強いて言えば、改行マークだけは変更されています)

しかし、少なくともU+23A7〜U+23ADはCID8174〜8180の辺りにあり、Stdでも実装されているはずなのに何故なのでしょう。

ここで、字形パネルの書体を「A-OTF A1明朝 Std」としてCIDコード順にソートし、CID8174〜8180あたりを表示して確認してみますと……


  • 上:A-OTF A1明朝 Std、下:小塚明朝 Pro-B

「A-OTF A1明朝 Std」にCID8174の字形そのものはあってもユニコード)U+23ABに紐付けされていないことがわかります。つまり、U+23ABは「A-OTF A1明朝 Std」では表示できないと判断され書体が変更されないということです。(どうしても必要であれば、字形パネルをダブルクリックすれば入力は可能です…但し、タテに続けるには「縦組み」で、ヨコに続けるには「横組み」で…自動での縦横変換もできません)。


字形パネルの活用

もう少しツッコんで……今までは(主に)ユニコードでの直接入力でしたが、字形パネルから目的の字形をダブルクリックして入力する場合を考えてみます。
以下が、和文用の始めブレース(U+FF5B:CID680)を選択した状態での、「選択された文字の異体字を表示」とした字形パネルの状態です*1


  • 左から、小塚明朝 Pr6N-R、小塚明朝 Pro-R、A-OTF A1明朝 Std

同じ文字でも、フォントの種類によって異体字への紐付けが異なるのがわかりますね(例示した書体以外にも違うパターンがあることは確認しています)。
異体字が豊富に紐付けされている場合には、以下のように目的の字形をダブルクリックして置換できるのですが……

  • 右の例のように、縦組みで横長のモノを作成する際は、ダブルクリックする字形が判り難いかも知れませんが、縦長のモノと同じ字形をダブルクリックすると自動的に変換されます(反転した文字を選択した状態での字形パネルです)

そうでない場合は、ユニコードで入力するか、字形パネルを「すべての字形を表示」として、ユニコード順(Proの場合)やCID順(Stdの場合)でソートして目的の字形を探すしかありません。

つまり、字形パネルから目的の字形をダブルクリックして入力する際には、フォントの種類によっては、その字形に到達するまでの手間が変わってしまうということになるでしょう。
(誤解を承知で言ってしまうと……明朝系、ゴシック系、丸ゴシック系程度の括りで使用フォントを考えてもいいように思います)

冒頭で「少し問題がある」とした繫ぎ用の文字について

ほんの一例として以下の作例を用意しました。


  • 上から、小塚明朝 Pr6N-R、小塚ゴシック Pr6N-R

この例を見る限りでは、左から3・4番目のSQUARE BRACKETとゴシックの1・2番目(パーレン)以外はとても使えたものではないでしょう(画像をクリックすると別窓に拡大表示されます)。
フォントによって異なることは十分に考えられますから、(これらの繫ぎを)使う場合は拡大しての目視確認を心掛ける必要があると言えます。

作例末尾のU+23B0とU+23B1について

これらは、(先に記したように)CIDコードでは16312と16313にマッピングされていますので、Adobe-Japan1-5(Pt5)以上でないと表示できませんが……

ATOKの文字パレットの文字情報をみると、U+23B0は “UPPER LEFT OR LOWER RIGHT CURLY BRACKET SECTION”、U+23B1は “UPPER RIGHT OR LOWER LEFT CURLY BRACKET SECTION” となっています。
「左の上か右の下」、「右の上か左の下」ということは、上下を入れ替えることで「始め」「終わり」を切り替えることができるということだろうと推測できます。
ところが、(少し検証したところ)これらが上下の区別なく繫がるのはモリサワ純正の書体だけ……という残念な結果になりました*2

明朝系の様々な書体での組み見本を以下に掲げておきますので、ご参考に……


  • 本来は、上下を入れ替えることで括弧の向きが変わる……という実装を期待
任意の長さにする

最後に、ブレース(別名:CURLY BRACKET)を例に、任意の長さにする場合の、Illustratorでの作業例を掲げておきます(InDesignでも手順は同様ですね)。


  • ポイントテキストで「横組み・行間アキなし」で入力(これを縦組みに変更すると横方向に延びるブレースに置換されますが、アウトライン化してから回転しても同じ)
  • 最後は数値入力で移動してもいいし、矢印キーを数回叩いて移動しても…お好みで…

*1:欧文用のブレース(U+007BとU+007D)の場合は欧文イタリック字形が追加されたりしますが、大差はありません

*2:2字分丁度なので、意外と使い勝手はいいかも? なのですが…

「アンカー付きオブジェクト」の「カスタム」設定_その1

ここ最近、InDesign「アンカー付きオブジェクト」の「カスタム」設定と挙動の関係について、理解があまり行き渡っていないのではないか? と思わせる書き込みを目にする機会が多いように感じます。
そこで、私なりに解説を試みてみることにしました。
※2〜3回に分けて連載することになるでしょう

まず、以下のような作例を準備しました。

X基準:「テキストフレーム」

オプションの最初の項目の「ノド元を基準」は後回しにして……
次の項目「アンカー付きオブジェクト/基準点」の部分では、アンカー付きオブジェクトそのものの何処を基準として配置するのか? ということを設定します。

  • この場合、アンカー付きオブジェクトの右/下を基準とする


次の「アンカー付き位置/基準点」「X基準(字送り方向)」と連動しており、併せて及び「Y基準(行送り方向)」を設定することでと連動しており、アンカー付きオブジェクトを配置する位置を指定します(オフセットの設定方法や考え方は他の機能と同様です)。*1
共に選択肢がいくつか用意されています。

最初に掲げた作例のそれぞれは以下のようになっています。

  • アンカー付きオブジェクト/基準点:左/上
  • アンカー付き位置 X基準:「テキストフレームの左端」、Y基準:「(仮想)ボディの上」


  • アンカー付きオブジェクト/基準点:左/中
  • アンカー付き位置 X基準:「テキストフレームの左端」、Y基準:「(仮想)ボディの中央」


  • アンカー付きオブジェクト/基準点:左/下
  • アンカー付き位置 X基準:「テキストフレームの左端」、Y基準:「(仮想)ボディの下」


つまり、X基準(横組み字送り方向:横方向)はすべて「テキストフレームの左端」、Y基準(横組み行送り方向:縦方向)は「(仮想)ボディベース」の上・中央・下としてあり、それぞれ「アンカー付きオブジェクト/基準点」と同じように設定してあるということで、(見ていただくと判りますが)「アンカー付き位置のX基準とY基準の交点」に「アンカー付きオブジェクトの基準点」が位置しています。

ここで、「アンカー付き位置」Xの基準点を少し変更し、上から(テキストフレームの)左端(ママ)・中央・右端としてみました。

さらに、「アンカー付きオブジェクト/基準点」も上から左/上・中/中・右/下と変更してみました。

  • 以降はこの状態からX基準を変更して挙動を観察します


このように、(最初のうちは)それぞれの基準点を同様の位置に(ある程度)合わせるとその挙動が理解し易いでしょうし、その後の数値的なコントロール(計算)もし易いハズです。

この作例の場合、X基準は「テキストフレーム」をベースにしていますから、例えば、現状の(アンカー付きオブジェクトを挿入した段落の)2字分のインデントを「0」としても、

また、「左揃え」から「右揃え」に変更したとしても、「アンカー付きオブジェクト」の位置は動きません

では、三つ前の状態からX基準をその他の選択肢に変更して挙動を観察してみましょう。

X基準:「アンカーマーカー」

  • アンカーマーカー挿入位置を基準に…
X基準:「列枠」

  • 段組みの場合はマーカーのある段(列)を基準に…
X基準:「ページマージン」

  • 現状は「テキストフレーム」基準の例と同じですが、これはテキストフレームの位置/サイズが「マージン/段組」での設定値と一致しているから

試しに、「マージン/段組」からマージン設定を変更してみると……それに応じてアンカー付きオブジェクトの位置も変わるのが確認できます。

  • ページマージンを 14mm → 10mmに変更した結果

「ページマージン」という用語から「余白部分」に配置されるかと勘違いしそうですね。どちらかというと「版面(はんづら)」とした方が適切なように思います。

X基準:「ページ枠」

  • これはネーミング通りページ(ドキュメントサイズ)が基準に…

最後に「ページ枠」を例に、最初にスルーした「ノド元を基準」のチェック OFF/ON の違いを例示しておきます。

「ノド元を基準」のチェック OFF(デフォルト)


「ノド元を基準」のチェック ON


例えば、最初のアンカー付きオブジェクトの設定画面で「ノド元を基準」のチェックを ON にすると、設定画面は以下のように変化します。

  • それぞれの基準点は見開きページではノド元を中心に左右対称の位置に設定されます
  • 「ノド元を基準」の ON/OFF はオブジェクト毎に設定する必要があります


長くなるので、続きは後日……今回は主に「X方向(字送り方向)」について観察しましたが、次回は「Y方向(行送り方向)」に重点をおいて考えてみることにします(ちとややこしいことになるハズです)*2……
※完結するまでに(何かの都合で)少し改稿するかも知れませんが、ご容赦ください。

*1:X・Yの選択肢に依ってそのチェック可能なポイントは変わります

*2:簡単に済ませました…

「表と段落のアキ」と行送りの基準位置

以前から気になっていた InDesignの「表の属性/表の設定/表と段落のアキ」と「行送りの基準位置」の関係について、簡単に検証してみました(OS X 10.10.5, CS6)。

私は主にフレームグリッドで作業しており、その際には表や図版は「アンカー付きオブジェクト」として配置することが多く、今まで気になりながらも放置していた結果、本日やっと…

プレーンテキストフレーム内の表組みに対して「表と段落のアキ」は前・後とも「2mm」と設定し、行送りの基準位置をそれぞれ変更した4パターンを作成。
さらに「行送り値」を様々に変更して4パターン……計16パターン作成し、観察してみることにしました。


すべて(改行マークも含めて)12級の状態で、各プレーンテキストフレームに対して「オブジェクト/オブジェクトサイズの調整/フレームを内容に合わせる」を実行…その結果を最終行に記入してあります(計算しやすいように、表の前後には1行だけの状態にしました)






  • 「行送りの基準位置」=「仮想ボディの下」の場合は偶然の一致(行送り値=文字サイズ)


結論からいってしまうと……
行送り値に関わらず、(常に)フレームサイズが正しい(表と段落のアキが設定した通りになるのは「行送りの基準位置」=「仮想ボディの上」だけであるということになります(0.1mmは表の罫幅がプラスされた結果ですね)。
但し、表と前の段落とのアキは「行送りの基準位置」の選択に関わらず設定通り確保されています

観察して気付いた点を挙げれば……
の状態のフレームサイズを元にのフレームサイズを考えた場合、「仮想ボディの上」以外は「行送り値の差」がフレームサイズに反映されている
を比較すると…表の後の段落の「行送りの基準位置」=「仮想ボディの下」の場合は、行送り値が文字サイズと同等であれば設定通りのアキが確保される*1
※他の設定の場合も追究すれば解るでしょうが、あまり有意義とは思えないので…これぐらいで…

行送りの基準位置が「仮想ボディの上」以外の場合は、その増減によって前の行(段落)とのアキが増減することを考えれば当然なのかも知れません……ということでしょうか……よくわかりませんが、ご留意ください。

*1:さらに蛇足として付け加えるならば、「行送りの基準位置」=「仮想ボディの下」vs「欧文ベースライン」のフレームサイズの差は欧文ベースライン位置に拠るということ…