前 9 - 20 P ｜ 
もくじ I ｜ 次 9 - 22 N 
「SSA入門 中級編」の初稿は2004年、今は2009年3月。5年の歳月が流れた。
中級編に続くものとして、 一般向けの系統だったASS入門を日本語で書くつもりだが、なかなか実現しないでいる。
ASSの限界、何ができて何ができないのか、ということは、誰にも分からない。 テキストベースのスクリプトで組み込みコマンドも限られているので、 高価なレタッチソフトにあるような、ある種の特殊効果をまねるのは不可能に近いだろう。 逆に、普通のレタッチソフトの考え方では困難なことが、ASSのアプローチだと「自然に」（といってもかなり強引だったりするが）実現できる場合もある。 t-r, t-clipのような、開発者自身予想しなかったであろう技法が発見され、普及する。 汚く、制限も多いが、しばしばそれを強引に回避する抜け道がどこかに存在する奥深さと強力さも併せ持つ。 精妙で混沌。
言語一般の特性だろう。 例えば「JavaScriptで何ができるのか」「日本語で何ができるのか」と問われても、「あなたしだい」としか言いようがない。
中級編の末尾でも「ヒント」として雑多な話題について補足したし、 単発のメモや速報もかなり公開したが、 それらはあちこちに散らばっていて、分かりにくい。 現在の視点から、歴史的覚え書きも交えながら、再整理してみたい。
どの項目もとりあえずメモ程度。 入門でなく、先端的な内容が多いが、 一般向けに役立ちそうな題材については、時間がとれたらちゃんとした解説記事を別に書く。 執筆時点（2009年3月）から見て、新しい内容が上に来るように並べる。 2008年以前の事柄は次回以降に。
\t(0,0) は避けるべき（VSFilterでは何も起きない） (2009-03-19)一般のDialogueにせよカラオケのDialogueにせよ、フェイドを組み込みの \fad でなく複数個の \t の組み合わせで表現することがしばしばある。 文字表面・輪郭・影の透過を別々にコントロールするためだ。 例えばフェイドアウトでは、影や輪郭が文字表面より時間的・速度的に速やかに消えるようにすることで濁りを防げることが多い。
この方法を使った場合、tの時間引数が字幕の持続時間より長くならないように注意が要る。 例えば持続時間5000ミリ秒の字幕があって、 3000ミリ秒から5000ミリ秒まで2000ミリ秒かけてフェイドアウトしているとする。 ところがシーンチェンジやクチパク関係などの調整で、フェイドを書いた後で字幕の持続時間が4900ミリ秒に縮まったとする。 このときフェイドを放置すると、5000ミリ秒で字幕が視覚的に完全消滅するはずなのに、 4900ミリ秒で字幕自体が終わってしまう。 フェイドアウトしきらないうちに字幕が終わるので滑らかな消失にならない。 \fad(0,2000) ならエンドタイムからの相対時間なので自動調整されるが、\tのフェイドは先頭からの相対時間なので、同じ感覚では使えない。 原理的には \fade のフェイドにも同じ問題がある。
逆に字幕の持続時間が1フレーム以上残っているうちに1a～4a全部フェイドアウト完了してしまうことは（意味的には少し変かもしれないが）視覚効果的には問題ない。
あまりないかもしれないが、t-rカラオケで表面色変化は必要ない場合（例えば、t-rカラオケをメインのカラオケの下のレイヤーに配置してアクティブトークンの「スポットライト」に使う場合）、 Kカラオケから変換するものの、最終的にはKを取り除いてもカラオケとして成立する。 r-lessの場合など、使い方によっては、t-clip同様、Kを使わないカラオケ効果ともなる。 「K-less t-r karaoke」とでもいうべきもの。 もちろんKを除去せず単にプライマリーとセカンダリーの色・アルファを同一にするのでも同じ意味になる。
\t(0,0) は避けるべき（VSFilterでは何も起きない）
例えば {\t(300,300,\1c&H00ff00)} なら300ミリ秒後に一瞬にして表面色が緑になり、
{\t(1,1,\1c&H00ff00)} なら1ミリ秒後に（＝普通のケースでは実質的には最初から）表面色が緑になる。
論理的には、{\t(0,0,\1c&H00ff00)} なら0ミリ秒後、つまり完全に最初から緑になるはずだが、
現在の VSFilter ではこの場合、style modifiers は無視され何も起こらない。
次の例、参照。
Dialogue: 0,0:00:00.00,0:00:10.00,Style1,,0000,0000,0100,,{\t(300,300,\1c&H00ff00)}Does this become green? (300,300)
Dialogue: 0,0:00:00.00,0:00:10.00,Style1,,0000,0000,0200,,{\t(0,0,\1c&H00ff00)}Does this become green? (0,0)
Dialogue: 0,0:00:00.00,0:00:10.00,Style1,,0000,0000,0300,,{\t(0,1,\1c&H00ff00)}Does this become green? (0,1)
Dialogue: 0,0:00:00.00,0:00:10.00,Style1,,0000,0000,0400,,{\t(1,1,\1c&H00ff00)}Does this become green? (1,1)
\t(0,0) は処理系によっては t=0 で style modifiers の状態になる（初めから変化しきっている）可能性があるが、
VSFilter ではそうなっていない。
挙動があいまいになるので避けるべき。
a3r v0.1.1.2以前のt-rカラオケでは、この形が発生することがあり、変化するはずのものがしないで意図と違う結果になる可能性がある。
a3r v0.1.1.3のt-rカラオケでは、
\t(0,0) は \t(0,1) に変えるオプションがある（デフォルトで有効）。
クチパクなどと字幕のオンオフのシンクについて、 2008年末以降の試行錯誤で、閉口側については、以前「字幕のリップシンクへのブレークスルー」などのメモで書いたことと認識が変わってきた。 次の行と時間的に連続していない場合、 エンドタイムの同期優先順位は、原則「シーンチェンジ＞適正ecps（下の追記参照）＞音の立ち下がり＞閉口」で、 ちょうど立ち下がり付近で閉口するときはそこでエンドタイムにしていいが、 立ち下がる前に閉口するとき、一般には、エンドタイムを早めにずらすこと（末尾圧縮）はしない方がいい。 音の立ち下がりのフレーム換算は、最初に声が完全に消えるフレームを0とした場合、24 fpsとして、好みで+1か+2か+3がいいと思われる（WAV上の立ち下がりはビデオのフレームチェンジと同期していないので、+1フレームといっても時間で言うと0 ms程度～42 msの揺れがある）。 +1だと歯切れ良く、+3だとしっとり。 タイミング入門では「あまり余韻のように声の後まで字幕を残すな」と書いたが、 それは初心者向きの一般的注意事項で、0.5秒とか1秒の「余韻」は基本的にタブーだが、 次の行が連続して出るのでなければ、 微妙に（0.04～0.12秒くらい）“余韻”があった方がいいと示唆される。 声にエコーがかかっているときはまた別問題。
ecpsとは1秒あたりの実効文字数で、字幕の持続時間に対して字幕が長過ぎる（文字数が多過ぎる）と（ecps過大）、 鑑賞者が読み終わらないうちにその字幕が消えてしまう、という問題が生じる。 これは当然、避けなければならない。 テキストの簡略化（短縮）がまず考慮されるべきだが、 タイプセッターと翻訳者・編集者の力関係によっては「この字幕は長過ぎるので短くしてほしい」と要求できない場合もあるだろうし、 簡略化すると原作のせりふの微妙な含みや味わいが失われてしまうなど技術的に短縮できない可能性もあるだろう。
そのような場合、字幕テキストを短縮できないのなら、字幕の表示時間を長くすることでecpsを減少させることになる。 そして、字幕の持続を長めるには、スタートを早めるよりエンドを遅らせる方が良い。 エンドは最大500 ms程度まで立ち下がりから遅れることができる（500 msは好ましくないが、字幕の文字数があまりにも多いときはやむを得ないこともありうる）。 400 msの遅れはかなり安全に可能で、 300 msの遅れはほとんど問題にならない。 上記では、立ち下りから+1～+3を目安にするとしたが、+4も十分に可能だし、 字幕が長過ぎる状況では、+10程度までエンドを遅らせて良い（リードアウト）。 スタートが立ち上がりより前になるリードイン（フライング）はリードアウトよりは目に付きやすい。 500 msのリードアウトは意識されないこともあるが、500 msのリードインがあると、多くの人は「字幕が出るのは早過ぎる」と感じる。 字幕の文字数が多過ぎて、エンドを遅らせるだけでは間に合わないときはスタートも早めていいが、ずらす度合いはエンドの方を大きくする。 ただし100 ms程度のリードインは安全で、むしろ好ましい（この点はタイミング入門、 中級編、「字幕と音声のずらし方: 理論と実際」などで何度も繰り返している）。
シーンチェンジとスタート・エンドが微妙に食い違わないことは基本だが、 必ずしも立ち下がりより前のシーンチェンジで声が残っているうちに字幕を消す（負のリードアウト）必要はない。 -100 ms程度なら負のリードアウトは問題なく、-200 msも通常安全で、推奨はできないが必要なら-400 msは許容できる。 しかし、負のリードアウトががくさん必要な場合、逆にエンドをシーンチェンジの向こう側へオーバーランさせて、オーバーラン量を+5～8フレーム程度にする方法がある。 全例ではないが、かなりの例でその方が良いと示唆される。 オーバーランが+4フレーム以内ではフリッカーになるので、明示的にオーバーランさせるときは、必ず+6程度、十分にシーンチェンジから離すこと。
これについては「シーンチェンジに対する「明示的な」字幕のオーバーラン」として、中級編 (4) でも2004年に追記しているが、 重要な手法なので繰り返しておく。
EmEditor でSSA/ASSの構文ハイライト（中級編・付録C参照）は便利なときは便利だが、 スクリプトが複雑になると、環境によってはエディタの動作が重過ぎることがある。 条件によっては最新版（EmEditor v8）より7や6の方が軽いこともある。 一方、条件によっては最新版の方が速いこともあるし、もちろん旧版を選ぶと最新版でのほかの修正が生かせないデメリットもある。 どのバージョンを選ぶにせよ、構文ハイライトがうっとうしいときは（EmEditorのせいというより、内容が全然最適化されてないので）、ハイライトを無効にしよう。
デフォルトの環境では、[F11], [T], [T], [Enter] だが、 Tools, Select Configuration, Define Configurations... メニューにて、 設定名をTXTから-TXT、SSAから=SSAにそれぞれリネーム（選択後[F2]使用）しておけば、 [F11], [+] で構文強調オン、 [F11], [-] で構文強調オフ、になって便利だ（[+] が単体では "=" のキーボードレイアウトを仮定）。 SSA/ASSに限らず一般用途でも、テキストモードで軽快に閲覧したいとき上記切り替え（上の例では [F11], [-] ）を活用できる。
範囲が異なる多重のアニメーションを使いたいとき、 例えば、 トークンごとのtアニメーションとは別に行全体にtアニメーションをかけたいとき、トークンごとのrの意味（アニメーションで変化させたパラメータを行の初期値に戻すタグ）をベタで書くことでrを使わずに書けば、行頭に行全体用のtを置けるようになる。 逆に、行全体にかけたいtエフェクトをトークンごとのrのたびにコピペしてもいい。 効果は同じなので、状況によって書きやすい方を選べばいい。 \rで戻すトークンごとの効果が複雑で行全体のアニメーションは単純なら行全体のものを\rごとに書き、 逆に行全体のアニメーションが複雑ならトークンごとに\rの意味を直接書けばいい。 場合によっては混用も可。
rを使わないので言葉の意味では「t-r」カラオケではないが、r-less t-r karaokeと呼んでおこう。
a3r v0.1.1.3のt-rカラオケでは、通常 \rに 当たる部分を編集できるようにした。
安易に\rを使わないようにする、ということは一般的な注意事項で中級編のヒント 2005-07-22 でも既述。 t-rカラオケは、基本形なら\rによってコードが効率的になるが、範囲が異なるアニメーションが重なるときは\rを使わない方が見通しが良い。
2009年2月初めの a3r v0.1.0.3 以降で、 ルビ付き縦カラオケの作成効率が大幅向上する手順を見つけた。 自動化を増やしたわけでなく、試行錯誤でショートカットを追加して便利にした。
縦カラオケでいちばん面倒な問題はルビと親文字の色変化同期で、 t-clipの6ないし7種類のパラメータをどの順番で調整するか、という理解が急所のようだ。 「色変化が時間的に早すぎる」というとき、時間座標でなく空間座標をいじる、というトリッキーなアプローチがある。 Kの引数を足して作ったtの値は、「時間がその値になったとき、そこまで色変化する」という意味にならない。 カラオケは、概念的には連続色変化だが、実際には色変化を約42 msごとの飛び飛びで見ている。 制御はミリ秒単位でも出力は42 msごとという直観に反した時間軸。 「色変化が早すぎるから10 msずらそう」といった単純な発想では制御が難しい。 「Kの引数からの換算でないフレームチェンジ時の正確なtを決定してから、そのときの正しいY座標を入れる」（時間と空間の両方を調整する）のが本来だが、 簡易的にはtは放置して、単にY座標を1だけ増やすか減らすとうまくいくことが多い。 奥の手としては、例えば「色変化の最後の部分が1フレームだけ遅い」というとき、 tタグのaccelで変化に加速度を与える方法もある（乱用は禁物だが）。
2008年7月以降の最初の試み（「縦カラオケ」参照）はかなり実験的で作業量も多かったが、a3r v0.1.0.3 で便利なショートカットを増やし、見通しも良くなった。 [Pause] キーを押すと右クリックと同じ意味にある…というだけなのだが、従来と比べて、非常に便利だ。
流れをざっと整理すると、
\q2 を指定。Styleで@フォントを指定、位置7で、270度回転させ、左余白を調整して画面の右端または左端に配置する。上余白は漢字側は出したい位置に調整、ルビ側は上余白0に。{\fscx???} {\fscx} でパディングし、ルビの位置合わせ。長い漢字に短いルビのパターンは {\fsp?}ルビ{/fsp} で字間調整。短い漢字に長いルビのパターンは、漢字側の字間を {\fscx10} {\fscx} などで増やす。最初の3項目はASSの普通の機能なので説明略。 4番目の VKara1 について。 a3r で [Ctrl]+[Alt]+[Shift]+[1] で「マウスで位置決め」モードに入り（注）、 [F8] で右に大きい拡大鏡を出して、それを見ながら字の末端をポイントして右クリックする…というのが、 これまでの半自動縦カラオケの説明だった。
注: v0.1.1.0以降では、ステータスバーの右から2個目の区画（デフォルトでCOLORと表示されている部分）が X/Y という表示になる。 v0.1.1.2以降では、上記のステータスバー部分を直接右クリックで切り替えることもできる。 （v0.1.1.0より前では、上記区画にDialogueの番号が表示されていたが意味ないので変更した。）
基本的にはそれで問題ないのだが、字間をマウスで正確にポイントするのは、拡大鏡を見ながらでも結構面倒だ。 マウスは細かい動きには適さない。 そこでマウスを持たずに [Alt]+テンキー で、マウスカーソルを移動させると良い。 このテンキー機能自体は、非常に古くから a3r にある機能だが、縦カラオケでは非常に役立つ。 しかしY位置を取得するのに「右クリック」しなければいけなかった。 1文字ごとにキーボードとマウスを持ち返るのは面倒なので、0.1.0.3 では [Pause]キー（[Break]キーとも言う。[PrintScreen]の隣の隣） で右クリックと同じ意味になるようにした。つまり、[Alt]+[Num2/8] でポイントし、[Pause] を叩くとクリップボードにY座標が送られるので、 [Alt]+[Tab] で好みのエディタに切り替えてVKara1リストを完成させる。エディタに切り替えたら極力、キーボード（移動は矢印キーなど）だけで操作し、マウスは触らないようにする。a3r にフォーカスを戻したとき、前の位置にマウスカーソルが残っていて都合がいい。 エディタが内臓でなく、いちいち外部エディタとの間を行ったり来たりするのは、IDEに慣れた人には億劫かもしれないが、 ルビの位置・時間決めをきれいにできるIDEなどもともとない。 ある程度のエフェクトに進むとき、ASSの直接編集は避けて通れない道だ。 （VKara1作業は、本来、文字イメージのスキャンで完全自動化できるのだが、ここを自動化しても、たいして作業効率は上がらない。）
上記テンキー使用により、ピクセル精度での位置決めが楽にどんどんできる。 それによって、VKara2 で、漢字とルビの色変化も既に同期している可能性が高くなり、手動修正の必要も減る。 面倒だからと VKara1 を雑にやると、後から手動修正がいっぱい必要になって逆に作業が増える。
同期の調整は、ルビと親文字の色変化のスタート、エンドが一致していない場合に行う。 VKara1 をちゃんとやっておけば、大半は修正なしで既に合っており、ずれている場合も、ずれは1フレーム程度で済むことが多い。 実用カラオケ目的では、漢字とルビの完全同期は取らなくてもいいだろう。 もちろん合っている方が美しい。 実用カラオケでも限度の問題で、例えば「漢字」の「漢」が変化していないときに、ルビは「かんじ」の「じ」まで進んでいる…といった状態がまずいのは説明不要だろう。
同期確認は、[Ctrl]+[Shift]+[L] でビデオをアンロードして、無地の背景上でやる。 ビデオ上でやると背景によっては色変化の詳細が見にくい。 修正が必要な場合、 t-clipの性質上、時間と空間のどちらからも制御が可能だ。 例えば、「色変化が早すぎる」場合、単純に考えれば t値を大きくしてエフェクト開始時刻を遅らせるという方法がある。 しかし、時間側から t-clip をコントロールするのは、一般には見通しが悪い。 そうでなく「色変化が早すぎたのはスタートラインが前過ぎたか、ゴールラインが遠すぎた」つまり「その時間枠での色変化の場所が長すぎた」というふうに空間側で考えたほうが、たいていうまくいくし、検証も修正も容易だ。 多くの場合、clipを1ピクセル変えるだけでうまくいく。 「色変化が遅すぎる」場合も同様。
注意点として、例えば「漢字がまだ変化していないのに、ルビの色変化が始まってしまった」という現象のとき、 漢字の変化が遅すぎるのか、ルビの変化が早すぎるのか両方の可能性を考慮しなければならない。 （判断で迷いたくないときは、まずしっかりタイムしたローマ字カラオケを作り、 それをリファレンスとして画面のどこかに表示しておいて、漢字もルビもそれに合わせる…という方法もある。） 怪しい方から、テンキー＆Pauseで「ここが制御点になるはず」という位置を取り直し、対応するt-clipがその値になっているか見る。 もし2ピクセル（以上）ずれていたら、それが原因だろう。 漢字もルビも位置決めは正しいときは、上記のように1ピクセル調整してみる。 例えば「漢字側の色変化の突っ込みが悪い」とき、スタートラインが既に合っているようなら、ゴールラインを1ピクセル遠くにし、 同じ時間枠でより長距離を変化させるようにしてみる（要するに色変化速度をアップさせる）。 またスタートラインが測定上、合っているとしても、それをずらす必要がある場合もある。 直観に反するようだが、KカラオケもDialogueも 10 ms 単位でしか測れていないのに対して、 フレームのt値は細かい端数があるので、「このフレームで色変化開始」と思うそのフレームは相対時刻0ではない。 フレームで「色変化が見える」ようになるのは、24fps の場合、最大40 ms程度も遅れており、そのせいで、 t-clipの空間座標が、1ピクセル（色変化の速度が早い場所では2ピクセル以上）ずれることがある。 要するに、Kカラオケから変換したとき、一般には色変化開始・終了フレームにぴったりのt値が使用されていないので、 時間的な制御点と少しずれたタイミングのフレームで、空間的な制御をかけていることが起きる。
よく分からないときは、ルビ側・漢字側のどちらでも調整しやすい側で、同期させてしまえばいい。 VKara1がちゃんとしていれば、最悪± 40 ms程度のチートなので、カラオケのスウィング幅で吸収できる。
結果が合っていればどうやってもいいが、 作業効率で言うと最初に空間座標を調整して、 どうしても空間側からいじりにくいときだけ、次の手として時間座標をいじるといいようだ。 （本当に厳密なアプローチは、Kの引数の単純加算でない正しいt値を使うことだろうが。）
ルビのオーバーハング（例えば長いルビが一部次の漢字にかかってしまうこと）は、ルビを別レイヤーでt-clipするなら、 技術的には恐れる必要ない（漢字とルビがt-clipを共有するやり方のときは、まずいが）。 しかし読みやすさのため、あまりハングしない方がいいので、適当に少し字間をあけるのがいいだろう。 ルビ末端と次の漢字の始端はほぼ接触していたり、場合によっては、わずかに重なってしまっても構わない。 それを全部避けようとして、漢字の後ろに細いスペース（全角スペースの5分の1など）を入れまくると、カラオケ技術的にはすっきりするが、 日本語の文字として普通に見た場合、間延びして、いまいちになる可能性がある。 かといって、あまりに接近していたり、重なりすぎているのも、読みにくい。 ルビの有無と関係なく、必要に応じて、全角の10分の1程度のスペースを挿入する。
文字間が接近しているが、読みやすさなどの点で隙間を入れないほうがいいと判断されるときは、 t-clipは空間的に手前側で制御する。重なっている先まで全部clipすると、 前の文字が変化したとき副作用で次の文字の頭が着色してしまう。その間に休符があったり、スタッカートでは、特にまずい。 その逆に、前の文字が端まで変化しきらないで、次の文字の変化のとき変化完了するパターンに持ち込んでおくと、比較的自然に見える。 姑息な回避はせずに正攻法で…という場合は次の「t-clipで色変化のオーバーハングを直接避ける方法」を参照。
t-clipでは文字の色変化を長方形のクリッピングで行うため、 文字に斜めの部分があって、前後の文字と一部x方向で重なっているとき（例えばセリフのイタリックの f など＝オーバーハング、アンダーハングと呼ぶ）、 色変化が中途半端になったり、まだ色変化してほしくない次の文字まで前の文字の色変化の副作用で色変化してしまうことがある。
手っ取り早い回避法は文字間をあけること（\fsp）。ただし文字のバランスが崩れて見栄えが悪くなる可能性もある。
縦カラオケでは必要ないだろうが、どうしても避けられない大きなオーバーハングがあって、
何らかの理由で字間をあけることもできない場合、しかも色変化をどちら側に合わせても変になる場合は、
t-clip上では、重なっている場所も含めて完全変化させてしまい、
重なっている後続文字のほうは、本来の色変化時間になるまで別の\tタグで全透明にして隠しておく方法がある。
要するに、普通のKカラオケのように、オーバーハングしていても文字単位で変化（文字の端が斜めの線なら色変化境界が斜め）ということ。
縁ワイプという概念にとらわれすぎてはいけない。 技法の説明としては純粋な縁ワイプを例示するかもしれないが、 実際には、t-clipでは縁ワイプしながら同時にフェイスを変化させるのもまったく同じ手間で、 縁ワイプ風にやるときも、フェイスカラーも多少変化させた方が視認性が上がる。
「多少」に限らず、場合によっては、縁とフェイスの両方をはっきり色変化させてしまってもいい。
t-clipだからシャドウをつけられない、ということも全然ない。 一般に多少シャドウをつけた方が視認性が上がる。
レイヤーでアルファを使うときの一般的問題だが、半透明にするときは、下のレイヤーの色を考えて設計する。 特に、フェイドイン、フェイドアウトするとき、単純にやると、上のレイヤーの透明度が高くても、 下のレイヤーのせいで、きれいな半透明にならない。 非レイヤーのフェイドといっしょにフェイドアウトするときは、0.6程度の加速度を指定するか、または下のレイヤーのフェイドを早くして先に全透明に到達させておく。
Windows上のMKV再生で、 ソフトサブ字幕のタイミングが重なっているとき、 後から出る側の字幕の影の透過度が異常になることがある。 ハードサブは影響を受けない。
別記事「[ASS/SSA] MPC/VSFilterソフトサブ: 4aバグと回避」参照。 a3r v0.1.1.0 に回避支援ツールが搭載された。
通常は字幕を均等割付する必要はないが、 小さい文字で長めの注釈などは均等割付した方がすっきりすることもある。 一般的には \q2 で自動改行を無効にしたうえで、 \Nで改行地点を指定し、表示行ごとに処理する。 文字間、単語間、カシーダの3方式を紹介する。
fsp+小数を表示各行ごとに変える方式。いちばん簡単で目的によっては効果的でもある。 日本語などの分かち書きしない言語で特に便利だろう。
現在のVSFilterはfspの引数として小数が使えるが、
VirtualDubプラグインのTextsub.vdfでは、この引数は整数しか使えない。
したがってこの方法でVSFilter用に均等割付してもTextsub.vdfでレンダリングすると意図通りに動作しない。
Textsub.vdfでは fsp1 の次は fsp2 …となり、一般にそれでは均等割付に必要な微調整ができず、事実上 fsp による均等割付ができない。
Textsub.vdf を使う場合で文字間を微調整したい場合、各文字間に細いスペース（例えば {\fscx5} {\fscx}）を入れる方法がある。
fsp+小数に比べてかなり煩雑だが、その方法なら VSFilter でも同じことになる。
英語などの分かち書きする言語でも、同じ方法で文字間調整は可能だが、 これが最善かどうかは場合による。
もともと単語間を空けるのなら、 文字間ではなく、単語間のスペースで均等割付をすることもできる。 単語間方式は、以前にも紹介したことがあるが、表示行のスペースを{\fscxN} {\fscx} で調整する。 例えば文字間のカーニングやリガチュールを変えたくないときは単語間で調整するといいかもしれない。
デフォルトの文字間（半角スペース）が狭いフォントでは、単語間のスペースを大きくすることで均等割付する方が読みやすいことがある。 一方、調整量が大きく、しかも、その表示行が長めの単語ばかりだと、単語間の調整地点が少ないため、 単語間だけでは不自然になる可能性もある。 文字間方式と単語間方式の違いに注意する。
fspが小数を取れるのに対して、fscxの引数は整数値になる（スタイル指定の倍率では小数も使えるが、 タグのfscxはなぜかwcstolで読まれるので小数点以下は無視される）。 したがってフォント幅の1%未満の微調整が必要な場合は、別途行う必要がある。 1%単位では粗い場合は、カンマやピリオドの後ろを臨時でちょっと広くして調整するといいだろう。
アラビア語系の均等割付には独特の部分がある。 似た発想はンコ文字やモンゴル文字にもあるようだが、アラビア語の場合がいちばん一般的のようだ。
VSFilter の自動処理のデフォルト \q0 ではアラビア語がかなり挙動不審になるため、 ここでは最初だけ \q1 でプレビューし、改行場所を決めたら \q2 による手動改行に移る。\N 挿入により双方向アルゴリズム（以下 bidi と略）が乱れるとき、 また最後のピリオドなどは、RLMを追加して対処する。 従来のヘブライ語／アラビア語の字幕ではDialogue末尾のピリオドや感嘆符（ヘブライ語では疑問符も）を物理配置にするのが普通だが、 それだとDialogueの結合・分割のたびに混乱するので、できれば RLM 方式の方がいいと思われる（最終的な表示は、どちらでも基本的には同じ）。 割付は \an9 ベースで余白は適当に調整。一応 \fe178 を指定しておく。 （fe は名前が Encoding のため Unicode の場合は不要と誤解されやすいが、実際にはエンコーディングでなく文字集合で、 コードポイントを決定するよりもっと前の段階のフォントマッチングで必要になる。 多くのフォントはたまたま西欧語も表示できるので、漫然と0のままでも見掛け上は動作するが。） さて、
例えば、表示の1行目と3行目が少し短くて、2行目が一番長かったとすると、 1行目と3行目を少し長くして2行目に合わせればいいわけだが、 アラビア語の場合、文字間を調整するためのタグを挿入すると、そのこと自体で bidi 境界が狂ってしまい操作が難しい。 さらにアラビア語の均等割付では、単語間などのスペースを調整するより、連結線を少し長くする方法（カシーダ、別名タトウィル）が一般的。 ここでもそのアプローチを使おう。 Unicode的には「線を長くする」のではなく「Kashidaのグリフを挿入する」という考え方をする（言い換えると、 この方法でKashidaを挿入した単語は、余計な「1文字」が追加され単純な方法では検索がヒットしなくなるので注意）。 Kashidaを挿入する場所として、ここでは次の文字に連結して書かれるシーン、スィーン、サーッド、ダーッドの直後を選択する。 これは絶対条件ではなく、横線がつながっている場所なら一応どこでもいい。
挿入可能点の全部にKashidaを入れると長くなり過ぎるときは、一部だけ使う。 逆に全部使ってもまだ足りないときは、前とつながるターマルブータの前など、 適当に不自然でない場所を追加する（ただし1語で1カ所まで）。 Kashidaが挿入されると、横棒が長くなることに注目。
本来なら、Kashidaの横棒の長さを調整して精密な均等割付を実現すればいいだけだが、 ASSの場合、上述のように、倍率などを書くタグを挿入しようとすると、そのタグのせいで bidi が壊れてしまってやっかいだ。 Kashidaのグリフ単位でしか調整ができない。 2個、3個…と挿入すれば Kashida 部分の横幅を2倍、3倍…にはできるが、 1ピクセルやサブピクセルの調整はできない。 必要なら、最後の1単語なり、カンマの前後なりでレイヤー化して物理配置を使うことで、分からない程度に文字間を調整することで微調整も可能だ。RLMを推奨しておいて結局物理配置というのが中途半端だが…。
挿入して、と簡単に書いたが、bidi の編集は慣れないと戸惑うことが多い。 本質的にはそれほど難しいわけでないが、 インターフェイスが微妙だ。 世間の自称Unicode対応アプリの中には、bidi だとカーソル位置さえおかしく挿入どころでないものが多い。 そのせいで、入門者にとっては、分かりにくい bidi がますます分かりにくくなる。 普段のエディタでうまくいかないときは、 機能は限られているし原始的なようだが、Windows付属のメモ帳を使うといい。 （ここの例は実際には a3r のフォントビューアーのエディットボックスで編集している。こういう作業の場合、ただのエディットボックスでも一般的なエディタよりまし。）
英語圏などでは、文字の方向が右から左であること自体で混乱する人もいるようだ。 日本語圏では「漫画を読むときの読み方」「漫画のコマと同じ」と言えばアラビア語の方向自体は一瞬で理解完了すると思われる。
最初からレイヤー化で文字間だけ調整するのでなく、Kashidaを主とすることで、 より自然なアラビア語の均等割付が実現される。 日本語・英語などの均等割付と発想が違うので最初は分かりにくいかもしれないが、 要は横棒を長くして行を長くしているだけ。 均等割付なしとありでどこが変わるか見比べてみよう。
一つ目がカシーダなし、二つ目がカシーダあり。見本は画像とテキストの両方で示す。 一般にカシーダが入ると水平方向に少し長くなることに注意。
注意: (1) 優先順位はMicrosoftがMSIE 5.5で用いた実装に準拠した。 明確化のために、スィーンとシーンのように文字のつながり方としては同一であるものもなるべく個別に取り上げた。 (2) カシーダは単に文字の外形（この記事の目的では均等割付）を調整するための横棒の延長で、 カシーダを挿入してもしなくても発音上や文法上は何も変わらない。 (3) 正則アラビア語を中心にするが、音写では語末のターマルブータは無視した。 (4) Initial / Medial / Final は「開始・中間・終了」で統一した。「語頭形・語中形・語尾形」という呼び方は「語頭形・語尾形」が実際には語頭・語尾以外にも現れるため、紛らわしいので避けた。 (5) デザインのための参考資料なので、言語学的・語学的に正確とは限らない。
| 見本 | 説明 |
|---|---|
 | salṭa「サラダ」。 スィーンの開始形の後ろにカシーダを挿入する例。 |
 | ʾassalāmu ʿalaykum「こんにちは」。 スィーンの中間形の後ろにカシーダを挿入する例。 |
 | šukrān「ありがとう」。 シーンの開始形の後ろにカシーダを挿入する例。 |
 | ʿašara「（数の）十」。 シーンの中間形の後ろにカシーダを挿入する例。 |
 | ṣabāḥa「朝」。 サーッドの開始形の後ろにカシーダを挿入する例。 |
 | naṣr「救助、勝利」。 サーッドの中間形の後ろにカシーダを挿入する例。 |
 | ḍaḥika「笑う」。 ダーッドの開始形の後ろにカシーダを挿入する例。 |
 | min faḍlak （男性に）: min faḍlik （女性に）「お願いします」。 ダーッドの中間形の後ろにカシーダを挿入する例。 |
| 見本 | 説明 |
|---|---|
 | thalātha「三」。 ターマルブータの終了形の直前にカシーダを挿入する例。 |
 | tāʾih「迷った、さまよえる」。 ハーの終了形の直前にカシーダを挿入する例。 |
 | wāḥid「（数の）一、ある人」。 ダールの終了形の直前にカシーダを挿入する例。 |
 | hādhā「これ」。 ザールの終了形の直前にカシーダを挿入する例。 |
| 見本 | 説明 |
|---|---|
 | mā「何」。 アレフの終了形の直前にカシーダを挿入する例。 |
 | laqaṭa「集める」。 ターの終了形の直前にカシーダを挿入する例。 |
 | baẓẓa「噴き出す」。 ザーの終了形の直前にカシーダを挿入する例。 |
 | qabila「受け入れる」。 ラームの終了形の直前にカシーダを挿入する例。 |
 | ālika「あれ」。 カーフの終了形の直前にカシーダを挿入する例。 |
 | ウルドゥー語 bhag 「近くに」。 ガーフ（アラビア語ではまれ）の終了形の直前にカシーダを挿入する例。 |
