前 7 - 22 p ｜ 
もくじ i ｜ 次 7 - 24 n 
SSA/ASS形式で日本語の字幕を物理的に縦書きする方法。
3つの方法があります。
第3のやり方が最も便利と思います。 特殊なレイアウトについては、 第1の方法では縦中横が簡単ですが、縦書き中の英単語のような縦横混在が面倒です。 第2、第3の方法では縦中横は比較的面倒ですが、縦横混在も容易です。
第1の方法は、2003年6月、 doom9 の Japanese subtitles in SSA?スレで質問されて考え、 このメモの最初のバージョンとしたものです。 それに対するこのサイト（妖精現実）の掲示板#1291でのフィードバックが第2の方法です。 それをさらに doom9 スレに還元したところ、2004年2月に Sylf が各行ごとに frz を使わなくて良くなる方法を報告しました。 これが第3の方法です。
Alignment を 7 にすることで表示位置を右上にし、一文字ごとに\Nで強制改行することで縦書きにする。
ごく一部の行でだけ縦書きにしたいときは、{\an9} を用いても良い。
句点、読点は縦書きだと位置が微妙に思わしくない（注1）。
ここでは改行を2回することで改善しているが、より細かくやるには絶対位置指定を用いても良い。
（一般的には、句読点を使わないスタイルのほうが良いだろう。）
縦書きの行が二行以上に渡る場合の処理は、適宜、手動で行う。
\N の挿入を手動で行うのは面倒なので、Perlスクリプトで一括処理すると良いだろう。
Style: vertical subs,Mikachan-PB,40,16777215,0,0,0, 0,0,1, 1,1,7, 20,20,20,0,128 vertical subs,,0000,0000,0000,,わ\Nた\Nし\N、\N\N桃\N宮\Nい\Nち\Nご\N。\N\N十\N三\N歳 vertical subs,,0000,0000,0000,,ご\Nく\N普\N通\Nの\N\N中\N学\N一\N年\N生
文字コードはUTF-16が好ましいが、Shift_JIS で Encoding を128に指定しても良い。
注1: この問題は縦書き用フォント（@で始まる名前のフォント）を使うことで回避できる。 次の画像を参照。（2005年8月20日追記）
次のようにして「縦中横」を実現できる。
vertical subs,,0000,0000,0000,,わ\Nた\Nし\N、\N\N桃\N宮\Nい\Nち\Nご\N。\N\N13\N歳
縦のなかに英単語等を含める必要がある場合は、タグを使って90度回転させる。 （以下、2004年1月27日追記。掲示板での要望 #1287）
レイヤー的処理になるから ASS にしたほうが良い。 SSAでは Z-index が指定できないので、 複雑になると、自動コリジョン処理と競合して、位置指定が意図通りに働かないことがある。 ごく簡単なパターンなら、SSA でも可能だ。 SSA形式でもタグはASSタグなので、Gabest系ツール以外ではレンダリングできない点に注意。 （この割付は、方法2以下の方が簡単にできる。）
Style: Default,TheLittleBirdFont,30,&H00ffff,0,0,&H333333,-1,0,1,1,1,7,30,30,30,0,128
[Events]
Format: Marked, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: Marked=0,0:00:00.00,0:00:10.00,*Default,,0000,0000,0000,,昔\N\Nあ\Nる\Nと\Nこ\Nろ\Nに
Dialogue: Marked=0,0:00:00.00,0:00:10.00,*Default,,0000,0000,0000,,{\an7\pos(612,260)}{\frz270}faireal
Dialogue: Marked=0,0:00:00.00,0:00:10.00,*Default,,0000,0000,0000,,{\an7\pos(580,360)}と\Nい\Nう
Dialogue: Marked=0,0:00:00.00,0:00:10.00,*Default,,0000,0080,0000,,サ\Nイ\Nト\Nが\N\Nあ\Nっ\Nた\Nそ\Nう\Nな
Dialogue: Marked=0,0:00:00.00,0:00:10.00,*Default,,0000,0130,0000,,そ\Nし\Nて\N\Nそ\Nこ\Nに\Nは\N・\N・\N・
（2004年1月28日 掲示板での情報 #1291）
次のように名前が@から始まるフォントを使う方法もあります。 この方法のメリットは、一文字ずつ\Nをタイプしなくてもいいこと、句読点を使った場合に良い位置に来る確率が非常に高いことで、 さらに横文字は自動的に90度倒れてくれます。 デメリットは一行ごとにposタグを打つ必要があること、縦中横が面倒なことです。 Perl処理する場合、どちらでもほぼ同じ手間とは思いますが、文字ごとに\Nが入らないので、 タイプセットのあとスクリプトを更新するときなど、こちらのほうがやりやすいと思います。
Style: Default,@Mikachan-PB,30,&H00ffff,0,0,&H333333,-1,0,1,1,1,5,30,30,30,0,128
[Events]
Format: Marked, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: Marked=0,0:00:00.00,0:00:10.00,*Default,,0000,0000,0000,,{\pos(610,30)\frz270}わたし 桃宮いちご 十三歳
Dialogue: Marked=0,0:00:00.00,0:00:10.00,*Default,,0000,0000,0000,,{\pos(560,30)\frz270}ごく普通の 中学一年生
（2004年2月19日 Sylf）
次のように ASS の [V4+ Styles] セクションで Angle を指定する方法。各行の pos 指定は依然必要。
[V4+ Styles] Style: letter,@MS Gothic,100,&H00191919&,&H00000000&,&H00000000&,&H00000000&, 0,0,0,0,100,100,0,-90,0,0.3,0,2,30,30,30,0
シャドウがない場合、輪郭色と表面色を別レイヤーにすることで、低コストで理想的なフェイドが可能になる。
シャドウがある場合の処理はやや複雑だ。安定した定石と考えられる手順の一つは、速度差シャドウ4である:
{\1a&Hff&\3a&Hff&\4a&Hff&}
{\t(0,1000,1.0,\1a&H00&\3a&H00&)}{\t(0,1000,4.0,\4a&H80&)}
{\t(3000,4000,1.0,\1a&Hff&\3a&Hff&)}{\t(3000,4000,0.25,\4a&Hff&)}
フェイドイン、フェイドアウトは日常的なエフェクトだが、半透明状態のときに濁らないようにするのは意外と面倒だ。 ASS上で6種類の違ったやり方でフェイドを行い、変化過程を対比している。 左から右に時間が進行する。 （フェイドアウトも順序が逆になるだけで同じ。）
文字の表面色（フェイス）は白、 影（シャドウ）が赤、輪郭（ボーダー）が青。 フェイスが赤っぽくなっている場所は影が透けており、 フェイスが青っぽくなっている場所は輪郭がにじんでいる。3c問題による「輪郭色が漏れて濁る」のと、 フェイスが透過したことで結果的に「影が透けて濁る」のは別現象で、 区別する必要がある。影が透けて濁るのを抑えるには、 何らかの方法で「フェイスが十分に濃くなるまでシャドウをまったく描画しないか、ごく薄く描画する」処理が必要だ。 「フェイスが濃くなるまでシャドウの描画を遅らせる」のが「時間差シャドウ」、 「フェイスが濃くなるまではシャドウの濃くなる速度を抑える」のが「速度差シャドウ」である。
{\fad(1000,1000)}1 野菜で
レンダラー依存だが、一般には3c干渉問題のため、輪郭線がにじんで非常に濁る。 \fadは避けた方が良い。
;; 実際には1行
{\1a&Hff&\3a&Hff&\4a&Hff&}
{\t(0,1000,\1a&H00&\3a&H00&\4a&H80&)}
{\t(3000,4000,\1a&Hff&\3a&Hff&\4a&Hff&)}2 野菜で
guliverkli [ 1022372 ] で言及されている方式。 フェイドイン終了後の1aがゼロなら（半透明でなく不透明な文字へのフェイドイン。この例はそう）、 3c干渉はほぼ回避できる。 バッファリングが無効になって負荷が高くなる代わり、\fadフェイドより高品位になる。 しかし、この方法では、シャドウが透ける問題は対策されていない。 シャドウがなければこの方法でも良いが、シャドウがないならそもそもレイヤー化すれば\tを使うまでもない。 いずれにしてもお勧めできない。
300,0:00:01.00,0:00:05.00...,,{\fad(1000,1000)}{\3a&Hff&}3 野菜で
301,0:00:01.00,0:00:05.00...,,{\fad(1000,1000)}{\1a&Hff&\4a&Hff&}3 野菜で
輪郭線のレイヤーを分離し、\tを使わず干渉を避けるやり方。 単純\tフェイドと同じか、それよりやや上の品質を、はるかに低負荷で達成できる。 シャドウがないなら、 この手法はASSフェイド（に限らず一般に1aが非ゼロの処理）の定石として、 お勧めできる（単純\tよりさらに少し高品位になり、しかも低負荷）。 しかし、シャドウがある場合、シャドウが透けて濁る問題には無力だ。 レイヤー化はあくまで3c問題しか解決してくれない。
なお、レイヤー化では、通常、ボーダーを下のレイヤーにした方が見栄えが良いのだが、 このケースではボーダーの上にフェイスという順序にするとフェイスに付属しているシャドウがボーダーより上に来てしまうので、 ボーダーを上にするしかない。（ASSでシャドウだけのレイヤーをうまく作れず、シャドウがフェイスと連携しているため。）
;; 実際には1行
{\1a&Hff&\3a&Hff&\4a&Hff&}
{\t(0,1000,\1a&H00&\3a&H00&)}{\t(500,1000,\4a&H80&)}
{\t(3000,4000,\1a&Hff&\3a&Hff&)}{\t(3000,3500,\4a&Hff&)}4 野菜で
妖精現実 Tip (20050423) の方法。 シャドウのみ変化時間を半分にする2重\tフェイド。 フェイドイン直後・フェイドアウト直前にはシャドウがない（シャドウの出没に時間差がある）のが特徴で、 濁りやすい時期に、 濁りの根本原因であるシャドウそのものを不可視にしてしまうため、 濁りの阻止という意味では最強。 シャドウがない区間、文字が平面的に見え、シャドウの出現とともに3次元的に見え始めるところに、 わずかにグリッチがあるが、実用上は、まず誰も分からないだろう。
時間差シャドウは実は速度差シャドウの特殊例である。 前半は速度ゼロで全透過のままアルファが変化せず、後半は通常の2倍の速度でアルファが変化している。 つまり速度変化に不連続点があることが分かる。 それを改善したのが次の速度差シャドウである。
;; accel=0.5 , 2.0
{\1a&Hff&\3a&Hff&\4a&Hff&}
{\t(0,1000,1.0,\1a&H00&\3a&H00&)}{\t(0,1000,2.0,\4a&H80&)}
{\t(3000,4000,1.0,\1a&Hff&\3a&Hff&)}{\t(3000,4000,0.5,\4a&Hff&)}5 野菜で
;; accel = 0.25 , 4.0
{\1a&Hff&\3a&Hff&\4a&Hff&}
{\t(0,1000,1.0,\1a&H00&\3a&H00&)}{\t(0,1000,4.0,\4a&H80&)}
{\t(3000,4000,1.0,\1a&Hff&\3a&Hff&)}{\t(3000,4000,0.25,\4a&Hff&)}6 野菜で
時間差シャドウの修正版で、変化に非線形の時間差（つまり速度差）がある。 シャドウのフェイドインはゆっくり始めてだんだん加速し、薄い状態を長引かせる。 シャドウのフェイドアウトは最初はどんどん消して、減速し、薄くなってからを長引かせる。時間差シャドウと違って、 フェイドイン直後・フェイドアウト直前でもシャドウが完全に消えない。 速度差が大きいと、線形の時間差シャドウとほぼ同じになるが、 わずかな違いながら、シャドウの出没がフェイスの出没と同期しているため、グリッチがない。
最初の加速度設定では、変化初期の影濃度増加が（フェイスの濃くなり方との対比で）少し速過ぎ、ちょっと濁る。 後者では加速度を上げて（変化初期の速度を落として）濁りを防いでいる。 加速度パラメータの設定は、一般には、色使いなど個々のフェイドに依存する問題で、 ここで示した例が常に最善というわけではない。なお\tの加速度パラメータは、 一度書くとデフォルトの\tにも影響するようだ。加速度を使う場合で、 同じ行で加速度なしの\tを混用したいとき、そちらには変化率1.0（変化なし）を省略せず明示すること。
速度差シャドウは時間差シャドウの不連続点を除去してくれるが、 加速度設定が不適切だと、見た目がかえって濁るので注意を要する。例5は例4よりかえって悪化している。
ここでも、輪郭レイヤーを分離するとさらに少し品質が上がるはずである （速度差シャドウと別レイヤーの輪郭）。 特に、フェイド後の1aが非ゼロなら、輪郭分離は重要だ。 この例では、\tベタだけの速度差シャドウと比べて違いが認められなかったので、 見本は省略した（速度差シャドウの例と出力は完全に同じに見える）。
一般にはASSのフェイドと言えば1の\fadが常識で、出発点だが、 これが濁るのは明らかだ。 2はより良い方法だが、2を使うなら3が良い。 2よりも少し上、書き方も単純で、何より2と比べて負荷がずっと低い。 ただシャドウがあるときは別の原因で濁る。 自分ではこのケースでは4を常用していたが、 どうも6方式の方が優れているようだ。5は手法としては4より高度だが、 実際の出力で4に負けている。 シャドウの\t変化に加速度をかけるだけで自動的に時間差シャドウの上を行けるわけではなく、 加速度の設定が重要だということが分かる（この例では2.0では足らない）。 厳密に言うと、6のように変化させつつ3のようにボーダーを分離するのが今思いつく最善だ。
Cost 653.9 milliseconds.