'writing-mode'

Edit New

CSS Writing Modes

仕様書

配置モデル

[45] CSS Writing Modes

'writing-mode'

>>46

歴史

DSSSL

[54] JIS X 4153:1998 (ISO 1996)

  • 4.17 行進行方向 (line-progression-direction)
  • 12.1 l) 機能 bidi: 「表記方向左向き (right-to-left)」
  • 12.1 m) 機能 vertical: 「表記方法下向き (top-to-bottom)」
  • 12.3.1 表記方法: 「右向き (left-to-right), 左向き (right-to-left) 又は下向き (top-to-bottom) のいずれか」
  • 12.3.2 「段落が複数の表記モードを使う」 (横書き bidi のこと)
  • いくつかの流し込みオブジェクトに特質 writing-mode があって、 left-to-right, right-to-left が指定でき、ものによっては top-to-bottom も指定できる。
  • 12.6.6 implicit-bidi-method

[388] >>398 によると ISO/IEC 9541-1 に基づきフォントの指定が次のように解釈されます。

オプションの引数writing-mode:は,シンボルleft-to-right,シンボルright-to-left及びシンボルtop-to-bottomのいずれかを値とする。シンボルleft-to-rightの値は,引数listの前に次のリスト置くのと同等である。

("ISO/IEC 9541-1//WRMODES"
 "ISO/IEC 9541-1//WRMODE"
 "ISO/IEC 9541-1//WRMODENAME"
 "ISO/IEC 9541-1//LEFT-TO-RIGHT")
他の可能な値についても同様とする。

[389] 関連: 公開識別子

[390] >>398

(15) 特質writing-mode:はシンボルであって,left-to-right又はright-to-leftのいずれかを値とする。これは,ヘッダ行及びフッタ行の表記方向を決める。初期値はleft-to-rightとする。

[391] >>398

[202] filling-direction-specification = (filling-direction expression )

式expressionは評価の結果,シンボルleft-to-right,シンボルright-to-left又は シンボルtop-to-bottomのいずれか一つになり,領域コンテナの流し込み方向を指定する。流し込み方向が構文page-regionで指定されない場合,構文page-modelから継承される。構文page-region及び構文page-modelの両方にその指定がない場合,エラーとする。

[392] >>398

(48) 特質writing-mode:はシンボルであって,シンボルleft-to-right,シンボルright-to-left又はシンボルtop-to-bottomのいずれかを値とする。表記モードの決定する方向は,配置方向に直交する。初期値は,シンボルleft-to-rightとする。この特質は,行の配置方向を制御する。

(3) 特質writing-mode:はシンボルであって,シンボルleft-to-right,シンボルright-to-left又はシンボルtop-to-bottomのいずれかを値とする。表記モードの決定する方向は,配置方向に直交する。初期値は,シンボルleft-to-rightとする。

(6) 特質glyph-reorder-method:は,#f,文字列又は文字列のリストとする。各文字列は,グリフの再順序付けの方法の公開識別子を指定する。初期値は,#fとする。

備考 これは,普通ヒンズースクリプトで使用する。

(7) 特質writing-mode:はシンボルであって,シンボルleft-to-right,シンボルright-to-left又はシンボルtop-to-bottomのいずれかを値とする。表記モードの決定する方向は,配置方向に直交する。初期値は,シンボルleft-to-rightとする。この特質は,グリフのメトリクの決定において,どの表記方向を用いるかを制御する。

XSL モデル

[56] このとき導入されたモデルが基本的にそのまま踏襲されたようです。

XSL → XSL 1.0 (XSL-FO) → XSL 1.1

[65] この少し前に Microsoft が CSS の追加機能として i18n-format を提案していました。 書字方向指定は 'layout-flow' を使っていました。 そちらは XSL との統合で廃止され、 その後は CSS も writing-mode を採用しました。

[67] 前の WD (>>60) では全バリエーションが定義されていましたが、 この WD から本体規定と附属書に分離されました。

[73] 追加の値は、 「for more extensive internationalization support」 >>71 のための追加の値だと説明されていました。

[70] 選択の理由は 「covers the base writing-modes that are used as the official languages of the United Nations」 >>66 と説明されました。 国際連合の公用語は Arabic, Chinese, English, French, Russian, Spanish とされます。 国際連合が書字方向まで定めているのか不明ですが、 この各言語の現代の正式な書字方向は、 lr-tb か rl-tb です。 (Chinese が現国際連合加盟国である中華人民共和国の中文だとする場合。) この理由付けからは tb-rl が含まれた理由がよくわかりません。

[82] W3C は国際連合の機関ではないですし、 XSL は国際連合の採用言語という話も聞いたことがありません。 スポンサーか何か政治的な事情があったのでしょうか?

[81] XSL と何の関係があるのかわからない国際連合云々という基準で、 モンゴル文字で使われる tb-lr は追加の値に格下げされました。

[79] 向きの指定は glyph-orientation-horizontal, glyph-orientation-vertical で90度単位で指定できるようになりました。 I18N, CSS, SVG と協同で議論中とありました。 >>78 結局 XSL 2.0 の最期までほぼそのままでした。 reference-orientation も残され、 XSL 2.0 の最期まで存続しました。

[80] glyph-orientation-vertical には auto があり、 全角の漢字とラテン文字は 0、 それ以外は 90 とされました。 漢字用句読点とその他漢字的文字は横書き字形、縦書き字形の別があるとき縦書き字形を使うとされました。 回転する文字の決定は利用者エージェント依存で、 country, language, script, character properties, font, character context によって複雑で、 UTR #11, JIS, その他国家標準に従うのが良いとされました。

[1] XSL 1.0

値行内部品・文の進行ブロックの進行シフト方向
lr-tb (lr)→↓↑
rl-tb (rl)←↓↑
lr-bt→↑↑
rl-bt→↑↑
lr-alternating-rl-bt→ (奇数) ← (偶数)↑↑
lr-alternating-rl-tb→ (奇数) ← (偶数)↓↑
lr-inverting-rl-bt→ (奇数) ← (偶数)↑↑ (奇数) ↓ (偶数)
lr-inverting-rl-tb→ (奇数) ← (偶数)↓↑ (奇数) ↓ (偶数)
tb-lr↓→←
tb-rl (tb)↓←→
tb-lr-in-lr-pairs↓←→
bt-lr↑→←
bt-rl↑←→

Formatting Properties 7.27.7 "writing-mode" http://www.w3.org/TR/xsl/slice7.html#writing-mode

Internationalization A.1 Additional "writing-mode" values http://www.w3.org/TR/xsl/sliceA.html#writing-mode-add

  • [2] 表で、シフト方向とは、基線類の調整方向。
  • [3] 注意する必要があるのは Unicode の bidi 算法との関係 (横書き系の時に影響) と、グリフの向きかな。

[122] 数少ない XSL の実装の中でもよく普及していたという アンテナハウスの XSL Formatter は、 writing-mode を独自に拡張していました。

[125] 独自とはいっても附属書には入っていました。

[75] その後の XSL 1.0 W3C勧告や XSL 1.1 案は附属書と分離された状態のままでしたが、 XSL 1.1 の CR でなぜか本体に再統合されました。 その後の版では統合されたままで、 XSL 2.0 の最期に至りました。

[87] CSS に提案されていた layout-flow モデルは XSL との統合で破棄されました。 CSS Text で XSL との統合モデルに基づく writing-mode が導入されました。 これは XSL (附属書含む) のサブセットになっていました。

[102] XSL (附属書含む) の有り得そうな組合せ全部に比べると、 使わなそうな writing-mode は省かれていますが、 lr/rl と tb/bt は一応全組み合わせ用意されています。 XSL (本体のみ) のよくわからない選択基準よりは論理的なサブセットにみえます。

[93] XSL の glyph-orientation-* は最初から最後まで90度単位でしたが、 CSS は実装に

  • 0度だけ
  • 90度単位
  • 任意

... の実装水準の選択を許していました。 (XSL も CSS も対応している直近の角度に丸めるとされていました。)

[103] 書字方向の記述に使わなそうな (装飾的な使い道はあるかもしれない) 任意の角度まで認めているのは XSL より記述能力が高いですが、 実装してもしなくてもいいとは相互運用性ガン無視。

[94] CSS は vertical:90,270、 horizontal: 0,180 のとき Unicode Bidi algorithm を適用するとしていました。

[126] CSS の WD の編集者に MS の Michel Suignard と W3C の Chris Lilley の名前が挙がっていました。 Michel Suignard は layout-flow の WD i18n-format にも貢献者として挙がっていました (i18n-format の編集者と貢献者は全員 MS)。 おそらく writing-mode にも Michel Suignard が主に関わったのでしょう。

[96] IE は CSS WD モデルの writing-mode の一部に対応していました。 従来の layout-flow にも対応し続けました。

IE の開発はその後凍結されており、 他の Webブラウザーもなかなか追随できなかったため、 長らく IE + writing-mode/layout-flow が Web 上で縦書きを実現する唯一の手法でした。

[4] Firefox 2 は実装していません。 (名無しさん)

[5] Opera 9 では SVG 1.1 で定義されている値が使えます。

[393] Web Workshop - Internet Explorer 5.5 における縦書きレイアウトの使用, , https://web.archive.org/web/20001206235000/http://www.microsoft.com/japan/developer/workshop/author/css/verticaltext/verticaltext.asp

[6] WinIE 6 では lr-tb と tb-rl が使えます。

[7] テスト用 http://suika.suikawiki.org/gate/2007/cssom/viewer?c=p%20%7B%0D%0A%20%20writing-mode%3A%20tb-rl%3B%0D%0A%7D%0D%0A;h=%3Cp%3E%3Cbutton%20type%3Dbutton%20onclick%3D%22%0D%0A%20%20w%20(getComputedStyle%20(this.parentNode%2C%20null).writingMode)%3B%0D%0A%22%3E%3Ccode%3EgetComputedStyle%3C%2Fcode%3E%3C%2Fbutton%3E%0D%0A%3Cp%3E%3Cbutton%20type%3Dbutton%20onclick%3D%22%0D%0A%20%20w%20(this.parentNode.currentStyle.writingMode)%3B%0D%0A%22%3E%3Ccode%3EcurrentStyle%3C%2Fcode%3E%3C%2Fbutton%3E;p=n;x=style-element;i=html-div (名無しさん)

[8] WinIE 6 には DOM属性 writingMode があります。 (名無しさん)

[9] >>8 currentStyle で得られるのは指定値 = 算出値 = 使用値のようです。 (名無しさん)

[10] Opera 9 には DOM属性がないようです。 getComputedStyle や currentStyle では DOM属性もなく、 getPropertyValue でも空文字列しか得られません。

[11] 縦書きHTML/CSSに関するメモ - 血統の森 web実験小屋 ( 版) http://momdo.s35.xrea.com/web-html-test/vertical-text/index.html

[321] SVG 開発前に提出された案のうち、 PGML は縦書き対応していませんでした (bidi は曖昧) が、 VML は layout-flow モデルでした。 SVG 1.0 の最初の WD は書字方向を扱っていませんでした。

[323] の第2次 WD >>322 は、独自の新設の CSS 特性を定義していました。

[327] WD で前者は CSS2 direction, unicode-bidi に置き換えられました。 >>326 縦書きは消失。

[328] WD >>329 で XSL モデルに完全に置き換わりました。

[334] XSL は参照せず同様の規定がありました。 この前後の XSL と CSS の WD と見比べると、時期的にも内容的にもほぼ中間的な形でした。

[336] その後 1.0 W3C勧告に至るまでの改訂で基本的な構造は変わっていませんが、 規定は細かくなっていました >>335。詳しくは要検証。 SVG 1.1 では変更なし (細部は要検証)。 SVG Tiny 1.2 (黒歴史) では direction と unicode-bidi だけ残してあとは抹消されていました >>335。

[340] SVG2 で新モデルに更新されました (>>339)。

[262] TTML は、 の最初に公開された要件 WD の時点で、既に visual style parameter の1つとして 「block progression dimension」 「inline progression dimension」 「line stacking strategy」 「reference orientation」 「writing mode」 を採用することを決めていました。 >>263 XSL 1.0 と CSS2 を参照していたものの、 こうした概念があるのは XSL 1.0 の方だけでした。

[265] の最初の WD は tts:writing-mode を規定していました。 値は lr-tb, rl-tb, tb-rl, tb-lr, lr, rl, tb でした。 block progression direction, inline progression direction を指定するものとされていました。 それ以上の詳細は XSL 1.0 が参照されていました。 >>264

[266] その後名前は tts:writingMode、 値は lrtb などハイフンなしと改められましたが、 TTML 1.0 は最後までほぼそのままでした。 XSL に direction, unicode-bidi が導入されたのを踏まえて TTML 1.0 にも同義の tts:direction, tts:unicodeBidi が追加されていました。 >>51

[267] TTML2 は XSL モデルに CSS の text-orientation を追加しました (>>268)。

[295] SMIL は、 WD で XSL 1.1 direction からコピーした textDirection を追加しました。 この時点では DFXP (後の TTML) にある writingMode と unicodeBidi は意図的に不採用とされました。 >>294 (詳細は規定はなく XSL 1.1 を参照。)

[297] CR で textDirection に ltro, rtlo が追加されました。 >>296 (なぜか unicode-bidi ではなく新しい値。)

[298] 同時に XSL 1.1 writing-mode からコピーした textWritingMode が追加されました。 値は lr-tb = lr, rl-tb = rl, tb-lr, tb-rl。 >>296 (値の選択基準は DFXP とされました。なぜか tb は除外。)

[354] OpenDocument はかなり変則的な XSL モデルを採用していました。 1.0 から 1.3 までほぼ同内容です。

CSS3 CR モデル

[98] XSL モデルを若干整理したもの。

[127] CR の編集者は MS の Michel Suignard でした。

[129] この CR は実装困難として再検討されることになりました。 この当時の CSS WG の議事は非公開で、 断片的な情報しかありませんが、 西暦2004年には書き直しが始まり、 西暦2005年には新しい CSS3 Text Effects Module WD が公開されました (が書字方向関係は Text Layout module に分離するとして、 削除されていました)。 CSS Text

[130] の CSS3 Text Effects Module WD の編集者は fantasai でした。 fantasai は に、 CSS3 Text の改訂作業中で縦書きの扱いを検討していると書いていました >>83。 この当時はまだ分離する決定がなされていなかったのでしょう。

[133] fantasai は CR 当時から技術的な懸念を指摘していました。

[134] 分離後の CSS3 Text Layout は、 非公開の CSS WG 内部案が https://www.w3.org/Style/Group/css3-src/css3-text-layout/ にあったとされます。その内容は不明ですが、 に fantasai が仕切り直しに当時の版を CVS に追加したものが公開されています >>116。 CR と比べると:

[137] 編集者は MS の Paul Nelson とされていました。 fantasai の検討は反映されなかったのでしょうか。

fantasai モデル

[139] fantasai は CSS の縦書きモデルを再検討し、 西暦2004年から2005年にかけて、 CSS と Unicode の関係者に向けた論文として発表しました。 Unicode Consortium では UTN #22 と呼ばれています。

[140] 本論文は縦書きと横書きの混植事例を分析し、 適度に一般化した形で整理した上で、 これを CSS で実現する手法を提案していました。

[141] 縦横混植を言語や用字系によらない一般化したモデルで記述し、 現実的に実現可能な手法を示したのは初めてかもしれません。 これより前に公開されたものは見当たりません。 現在からみても非常に優れた分析です。

[142] Logical Text Layout >>138:

  • [144] 必要な script 情報
    • script の horizontal directionality: ltr, rtl, none
    • script の vertical directionality: ttb, btt, none
    • script の orientational category: horizontal, vertical (蒙古文字など), bi-orientational (漢字, Ogham など)
    • 縦書き script の bi-orientational transformation: rotate (蒙古文字、Ogham など), translate (正立。 CJK)
  • [145] block of text の設定
    • what block progression to use
    • how to orient non-native text: rotate right, rotate left, stay upright

[146] 基本は script 本来の性質から導かれる自然な方向に組んでいき、 混在時の扱いなど2点だけ指定されたものに従えばいい。 (このモデルが導出された根拠は本文参照。)

[143] 実装案 >>138:

[147] これを Unicode Bidirectional Algorithm といかに統合するかも述べていました。 bidi アルゴリズムとの関係性もこれまでのどの仕様案より踏み込んで検討していました。

[148] 縦中横には言及しておらず、どう考えていたのか不明です。 CSS3 CR にも縦中横の例はあったので、 fantasai も存在は知っていたはずです。 本論文は一次元に文字が並ぶ行を扱っていて、 縦中横以外にも割注、ルビ、数式といった構造には言及していませんでした。

再始動

[151] UTN #22 の提案はその後 Unicode 側では進展しなかったようです。 CSS 側も、 fantasai が CSS 2.1 など他の課題に取り組んでおり、 長らく手つかずでした。 その間書字方向は CSS3 Text Layout として分離され別の編集者が割り当てられましたが、 ほとんど進展しませんでした (>>134)。

[152] 、 fantasai は CSS WG の公開 CVS で ED を公表しました >>116。 、 block-progression が block-flow に改称されました >>174 (その後2010年に巻き戻った後再改称)。 おそらく UTN #22 モデルに合わせて整理しようと試みていたのでしょうが、 ほとんど進んでいませんでした。

[153] 西暦2010年、 CSS を使った EPUB の日本語対応に関与していたアンテナハウスの関係者が改善を要望しました >>12。これを契機に fantasai と共にアンテナハウスの関係者が編集者に加わりました。 、 fantasai は日本滞在中にアンテナハウス社を訪問し、 全面的な改訂に着手しました >>115, >>118, >>149。

[180] EPUB の日本企業の関係者らは、 この間のに、 当時の案から writing-mode の lr-tb, tb-rl への対応が (EPUB の日本語対応には) 必要であるとしていました >>179。

[154] 再始動してからの一連の作業が反映された WD:

  • [155] block flow direction: horizontal writing mode (downward/upward), vertical writing mode (leftward/rightward)
  • [156] line orientation: under/over

[169] 旧 writing-mode (direction と block-flow の shorthand) は破棄されました。 block-flow は新 writing-mode に改称されました。 writing-mode と direction (および bidi) は分離され、 writing-mode の特性値が一新されましたが、 SVG 1.1 が既に旧 writing-mode を使っていたので、 block flow direction 部分だけを読み取って読み替えることにしました。 (結果的に IE の writing-mode との互換性も保たれましたが、 意図的にそうしたのか不明。)

[175] この WD 以前の ED に一時 block-flow: bt >>174, writing-mode: horizontal-bt がありましたが、削除されました。 完全性のために追加したものの、 実用性から削除したといったところでしょうか。 過去の CSS 案になく、 XSL モデルに相当するものがあるくらいです。

[178] 下から上の縦書き (具体例は Ogham) は未対応とされました。 text-orientation で一応表示させられないことはありません。

[170] 5年前の提案と比べると text orientation が横書き用、縦書き用が合体し、かつ SVG 1.1 との互換性のため、やや理論的整合性を欠くようになったこと、 縦中横に対応したことが違います。

[257] text orientation が縦書き時専用となったことで、 日本でたまに行われる横書き文中の倒した縦書きのようなものが扱えなくなってしまいました。

[171] text-combine は CR 時点で組み文字 (letters) と割注 (lines) のための機能でしたが >>97、 その後分離されていました (>>129)。 ただ分離後に公開された最古の ED には既に含まれていませんでした >>116。 縦中横用として再追加されたとき、 block (組み文字) と upright がありました >>172。 後者が縦中横用に新規追加されたものなので、 block は非公開時代の最終案にでもあったのでしょうか。 (再追加時点で、 JLREQ にないので一旦削除するか?と注釈がありました。 実際その後削除されました。なお削除前に一時 cluster と改称されました。) ともかく、 この時点で text-combine は 「複数の文字を組合せて1文字扱いにする」 機能のようです。 (割注は「1文字」ではないので、分離か削除されたのでしょう。)

[173] これ以前は i18n-format 由来の 「縦中横1996です。」 という横書き部分が行からはみ出した例が示されていました。 それがこれ以来 JLREQ 由来の 「平成20年4月16日に」 という例に変わりました。 1文字サイズに収めない縦中横は対象外になったようです。

[118] fantasaiと日本語組版 ​思い出と功績を日本人関係者が振り返る, 小林龍生, 村田真, ​下川和男, https://www.aplab.jp/fantasai-and-japanese-text-layout

2010年9月25日から10月4日まで、fantasaiを新宿のイースト、4階の6坪ほどの会議室に閉じ込めて、CSS Textの第一稿(Editor’s Draft)を書いてもらった。

[119] 流石に言葉の綾だと信じたいが、こういう表現で自分達の (手によって導いたという) 「功績」を誇る人にはなりたくないものだ。

[382] Bug 46123 – Implement block-flow support for all of layout (master bug) ( ( 版)) https://bugs.webkit.org/show_bug.cgi?id=46123

[312] WebVTT はちょうど新 Writing Modes と同時期に開発されました。 canvas 2d のテキスト描画APIは、 横書き用と縦書き用が用意されながら、 縦書き用は CSS が未成熟であるとして正式仕様に含められませんでした。 WebVTT の縦書き対応は、 新 writing-mode に相当します。

[314] HTML5 の編集者の Hixie は fantasai の師匠に当たります。 ほぼ同時期に並行して実施された両者の開発を互いにある程度関知していたことは間違いないでしょうし、 canvas と WebVTT での扱いの違いは CSS 側の開発進捗を反映しているようです。

[315] に HTML5 (当時) canvas 2d v3 としてテキスト描画の API が追加されました。 fillText などは横書き用でした。 CSS の定義を参照する形で規定されていました。 同時に fillVertcalText など縦書き用も定義されたものの、 CSS 側が不十分ということで、 規定全体がコメント化されて隠されていました。 >>316

[318] この部分は canvas v4 >>317, v5, v6 と遅延されていきました。 実装もされないまま、 奇しくもちょうど11年と1日が経過した日、 整理のついでに消されてしまいました >>319。 別案の検討すらされていないようです。

[301] HTML5 (当時) timed text track モデルと WebSRT (当時) 構文はの開発開始当初から writing direction の概念を有していました。 DOM属性は direction。 当時は既定値が横書き、 D:vertical で縦書き右左でした。 >>299, >>302 D:vertical-lr で縦書き左右でした >>306。

[307] レンダリングは、 CSS に写像する形で定義され、 direction は文字列から決定、 block-flow は D: から変換することになっていました。 >>305, >>304

[310] わかりやすくと D/direction は vertical に、 vertical は rl に、 vertical-lr は lr に、 horizontal (DOM属性値) は空文字列に改称されました。

[313] その後 block-flow が writing-mode に変更されたり、 direction が plaintext になって独自アルゴリズムは不要となったりといった形式的な変化はありましたが、 構造は変わっていません。 text orientation 相当の制御を WebVTT で記述する方法はありません。

向き

[177] ごろから、 これまで (CSS 以外も) 厳密に決め(られ)なかった、 文字の向きの個別具体的な挙動が定義されるようになりました >>176。

[181] 第1案が一通り出来上がった WD >>14:

  • [182] text-orientation が vertical-right かつ vertical writing mode, upright かつ vertical writing mode のとき、 vertical typographic mode。 rotate-right, rotate-left のとき、 horizontal typographic mode。
  • [183] vertical typographic mode
    • vertical script の grapheme cluster: 文字の intrinsic orientation を使う。
    • horizontal-only script の grapheme cluster: text-orientation 依存 (upright if upright, sideways if vertical-right)
    • Common, Inherited, Unknown script の文字の orientation: UA, font 依存
      • vertical-right で普通 upright か sideways かの判定に EAW を使える: F, W は upright (vertical font settings), N, Na, H は sideways (horizontal font settings)。 (A の処遇は未定)
      • font & font system が mixed-orientation typosettings に対応しているなら、 vertical-right はそれを使うべき。 upright typesetting に対応しているなら、 upright はそれを使うべき。
      • UA が合成するとき (例えば OpenType font が vert を持ち vrt2 を持たないとき):
  • [184] script orientation
    • Han など列挙した script は vertical script
      • うち Monolian と Phags Pa はrotate、それ以外は translate
    • UAX #11 全角文字は vertical script, translate
    • それ以外は horizontal-only

[185] WD >>15 時点でも基本の構造は同じで、 EAW 関係がより厳密な定義になりました。 WD 時点までに更に微修正が入ったのに加え、 text-orientation 値が改称されました。

[189] この WD 間の改訂で、 text-combine は廃止されて、 一部 (条件を記述) または全部の文字を縦中横する text-combine-horizontal と、1文字分のサイズに圧縮するかどうかと方法を指定する text-combine-mode が追加されました。

[205] このグリフ回転法には難色を示す人も多かったようです。 本手法がとても複雑に見え、理解を遠ざけたことが大きな要因にあったようにみえます。 一方でフォント依存となっていることも問題視されましたし、 EAW のような必ずしもこの目的に適していない情報を複雑に組合せていることにも批判がありました。

[206] ただ編集者らが説明していた通り、当時利用できた情報と実際的な制約の中で実現できることには限界がありました。 問題を突き詰めていくと、 (対象となる問題や解法案を十分に理解していないものを除けば、) Unicode が1つにまとめた記号の東アジアと欧米での用法の違いだとか、 フォントによる実装の違いだとかの、 従来 Unicode や他のアプリケーションが目を瞑ってきた難題に行き着いたようです。

[342] EPUB2 は CSS2 を使っており、 direction と unicode-bidi もそのまま使っていました >>341。

[344] EPUB3 は CSS 2.1 と CSS Writing Modes を使っていました。 direction と unicode-bidi は使ってはならず、代わりに HTML で記述しなければならないとされていました。 >>343

[346] 案以後、 (禁止されている direction, unicode-bidi を除いた) CSS Writing Modes の特性は、

... と規定されるようになりました。 >>345

[350] CSS 側が未だ WD で仕様が安定していない (実際変更された) ため、 EPUB 側の標準化スケジュールに合わせるため凍結する意図と思われます。 しかし意味だけ最新版を参照するという謎な規定になっています。 これ以後の CSS 側の変更の結果、 EPUB3 は実装不能となってしまいました。

[351] writing-mode の指定がパッケージに書いたメタ情報の page-progression-direction と一致していなければならないともされていました >>343。 page-progression-direction は 「The global direction in which the Publication content flows.」 で値は ltr と rtl とされています >>352。 これと writing-mode が矛盾し得るのかどうかよくわかりません。

[191] グリフ回転の情報を Unicode 側で管理するべきと考えた人々が、 Unicode Consortium に働きかけました。 、 UTR #50 の最初の版が公開されました。

[207] CSS は UTR #50 を使って再定義する流れとなりました。 ただ UTR #50 は JLREQ をベースにしたものでしたから、 日本語以外も含めた当時の Unicode 全体を検討した CSS の従来案の成果が含まれない不完全なものでした。 ゆえに両者の摺り合わせが必要となりました。

[209] 平成24(2012)年に入って、 CSS 側が UTR #50 を使う形に改められました。 同時に並行して各文字について、 UTR #50、 各フォントの実装状況、 JLREQ、 JIS X 0213、 書籍や漫画の実例などから個別に詳細に検討されました (>>190)。 (こうした作業が UTR #50 にどの程度反映されたのかは要検証。)

[210] UTR #50 への統合 & 新しい UTR #50 の SVO & MVO モデルへの更新が一旦終わった時点の WD >>17 の時点での概要:

[215] vertical typesetting synthesis は UTR #50 と統合され置き換えられると注記されており、実際次の WD までに削除されましたが、 旧版と UTR #50 の関係性 (と当時の CSS WG の分析) を記述したものとして参考になります。 WD には各カテゴリーの詳しい説明もあります。

  • [216] Upright (SVO=U & MVO=U) or Transforming (SVO=MVO=T): mixed-right でも upright でも upright。 transforming は縦横でグリフがぜんぜん変わるので選ばないといけない。
  • [217] Upright-Transforming (SVO=T & MVO=R): upright では upright で、(理想的には) 縦書きグリフ。 mixed-right では sideways。
  • [218] Sideways (SVO=R & MVO=R): mixed-right でも upright でも sideways。
  • [219] Non-Vertical (SVO=U & MVO=R): mixed-right では sideways。 upright では upright。

[224] UTR #50 の変更を反映した WD 時点までの変更:

  • [225] mixed-right → mixed に変更: UTR #50 orientation (旧 MVO のこと) により、 U, T (その後の改正で消滅), Tu: upright, R: sideways, Tr: upright typesetting 用 glyph がフォントにあればそれ、 なければ sideways
    • システムによっては Mongolian, Phags-pa は実際には sideways
  • [226] mixed, upright の upright: vertical font metrics。 なければ合成 (実装依存)。 vertical typesetting 用 font features (vert など)。 isolated form。
    • [230] upright といってもグリフを回転するべき場合がある (dash や enclosing punctuation など)。 (東アジアのフォントは縦用の字形が入っていても西洋のフォントには入っていない。) UTR #50 の SVO に sideways にするべき文字のデータがあったが削除された。
  • [227] mixed, upright の sideways: horizontal metrics, 90度回転。 フォントに sideways text that is typeset in vertical lines 用機能があれば使う。
  • [228] sideways, sideways-right, sideways-left: horizontal font metrics。
  • [229] vrt2 はフォント依存になるので不使用。
  • [231] text-combine-horizontal の条件付縦中横は削除、 text-combine-mode は削除。 (将来送り、としつつその後も本項執筆時点まで復活せず)

[232] UTR #50 は従来の SVO を廃止してしまいました。 Unicode 側の認識では、 MVO は (UTR #50 編集者の思うところの) 日本用、 SVO は英語用であるところ >>241、 日本以外はあまり重視せず先送りすることになったようです。 (先送りといっても本項執筆時点まで10年近く何の動きもなく、 実質開発中止でしょう。) そもそも Unicode 側はプレインテキストで最低限の表示に必要なデータを整備できればよいとしていたようです。

[233] CSS は mixed に MVO のデータを、 upright に SVO のデータを使っていましたが、 SVO が消滅して upright が宙に浮く形になりました。 本来 upright でもハイフンや括弧は縦書き用になる必要がありましたが、 根拠となるデータを Unicode が提供していないため、 常に upright な字形を使う (forced upright) ことになりました >>220。 (fantasai はそれでは使い物にならないと説明したものの、 CSS WG の決定には抗いませんでした。)

[234] forced upright といっても実際には縦書きデータがあるフォントでは縦書きデータが使われるので、 結局のところどう表示されるかは実装依存となってしまいました >>221。 また変更が反映された仕様書 >>18 も、 Note としてダッシュや括弧は回転させなければならない、 SVO のデータが昔はあったがなくなった (ので詳細は実装依存だが何かしないといけない)、 という感じになっていて、 forced upright にするという決定が反映されたのかどうかよくわからない状態になりました。 (forced upright を主張した人達のメールをみると、 アルファベットと漢字の向きが決まればあとは edge case なのでどうでもいいという類の認識が示されていて、 相互運用性などは重視されていないようです。。。)

[258] UTN #22 の系譜の CSS の用語と、 UAX #50 の用語とは、 似ていても意味が同じでないことに注意が必要です。 現在の CSS の仕様書の説明と変更の過程から、 次のように解釈できます。

  • [259] CSS の upright は UTN #22 の transform につながるもので、 文字列を横書きの字形の向きをそのまま縦に並べ替えることを言っています。 並び順だけで字形は不問なので、 横書きと縦書きで字形が同じ場合 (UAX #50 の U = Upright) のほかに、 まったく違う場合 (UAX #50 の T = transformed) や横書きを回転した字形が縦書き字形の場合 (UAX #50 の R = Rotated) が含まれます。
  • [260] CSS の sideways は UTN #22 の rotate につながるもので、 文字列を横書きの左右の関係を保ったまま縦並びに回転させることを言っています。

[261] ただこの両系統の用語の意味は CSS が UAX #50 を採用する過程で変質し曖昧化しており (用語自体も両者それぞれ何度か変更されました)、 現在の規定からその意図が明確とは言い切れません。 またそれがどこまで意識的に変更されたものかも判断が難しいです。 関係する CSS WG の議論も、人によって用語と概念の解釈が違うように思われます。

[19] WinIE9 は lr, rl, tb, lr-tb, lr-bt, rl-tb, rl-bt, tb-lr, rb-rl, bt-lr, bt-rl に対応しています。 bt はなぜかありません。いずれも CSSOM 上のみならずレンダリングも変化します。

[20] Chrome は lr, rl, tb, lr-tb, rl-tb, rb-rl に対応しています。

[21] 現行 CSS3 の horizontal-lr, horizontal-rl, vertical-rl にはどのブラウザも対応していません。

[22] IE9 は -ms-writing-mode を構文解析時に writing-mode に置き換えるようです。 -ms-writing-mode の方には IDL属性は無いようです。

[23] Text — SVG 2 ( ( 版)) https://svgwg.org/svg2-draft/text.html#WritingModeProperty

[24] 日本語組版処理の要件(日本語版) ( (Japanese Layout Task Force 著, 版)) http://www.w3.org/TR/jlreq/ja/#directional_factors_in_japanese_composition

[235] WD >>25 時点まで:

  • [236] 方向の記述が block-start/block-end, inline-start/inline-end に変更されました。
    • [237] これで XSL モデルの残滓が writing-mode という特性名くらいで後はほとんど別物になりました。
  • [238] text-combine-horizontal の条件のうち数字列だけ復活しました。

[255] CR >>27 時点までに、 text-combine-horizontal は text-combine-upright に改称されました。

[28] IRC logs: freenode / #whatwg / 20141219 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20141219#l-130

[377] TEI は書字方向の扱いを検討し、 基本的なものは CSS Writing Modes で、 ワードアート的な特殊例は CSS の transform で記述するとの結論を得ました。

[378] 下から上の縦書きは text-orientation: sideways-left で表現可能とされました。

[379] 牛耕式は (TEI では行ごとにマーク付けすれば良いので) CSS Writing Modes や transform で書けるとされました。

[380] 渦巻状のものは SVG で扱うべきものとされました。

[381] 用例として示されたうち下から上の横書きをどう記述するべきなのかは不明。

sideways

[242] CR 後、 実装状況が芳しくなかった機能の処遇と SVG との統合が問題となったようです。 CR >>32 までの変更:

[249] text-orientation は日本語の縦書き中の英数字などの制御にほぼ限定され、 英語などの寝かせた縦書きは writing-mode で扱うことになりました。 縦書き文中のアラビア文字の上から下への右横書きや、 下から上への Ogham のような従来カバーされていた稀な用途は、 対象外とされてしまいました >>250。 ここに至って UTN #22 モデルの面影もほとんど消えてなくなってしまいました。

[339] SVG2 は (慢性的な資源不足もあって長年放置され) 長らく SVG 1.1 の XSL ベースのモデルのままでしたが、 このとき direction, unicode-bidi も含め CSS Writing Modes を利用する形に改められました。 >>338

[34] 409155 - writing-mode doesn't work on th or td elements - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=409155

[251] writing-mode に新たに追加された sideways-rl, sideways-lr と text-combine-horizontal の数字列の条件指定は、 Level 3 から外され Level 4 だけになりました。

[254] Chrome は writing-mode: horizontal-tb, vertical-lr, vertical-rl; text-orientation: mixed, sideways, upright; text-combine-upright: all に対応しています。

TTML2

[268] TTML1 は XSL モデルの writing-mode, direction をコピーした tts:writingMode, tts:direction を定めていました (詳細な処理モデルの規定は無し、詳しくは >>262)。

[269] TTML2 はそれを残したまま CSS からつまみ食いする形で tts:textOrientation を追加しました。

[271] WD >>270 時点では、 当時の CSS 相当の値を独自に規定していました。

(script 判定方法の規定はなし)

[278] WD >>277 時点では、 UTR #50 Vertical_Orientation を参照する形に改められていました。

  • [280] horizontal writing mode では無意味
  • [279] mixed: rotated glyph: sideways, non-rotated glyph: upright (rotated or not は VO 次第)。 sideways: block progression direction が右左か左右かにより、 時計回りか反時計回りに90度回転 (回転はグリフ置換かアフィン変換によって行われ、 どちらになるかはフォント次第)。 upright: 何もしない。
  • [281] sidewaysLeft: rotated glyph は反時計回りに90度回転。
  • [282] sidewaysRight: rotated glyph は時計回りに90度回転。
  • [283] sideways: rotated glyph は block progression direction が右左か左右かにより、 時計回りか反時計回りに90度回転
  • [284] upright: すべての文字を Vertical_Orientation が U として扱い、回転しない。 グリフ置換も回転も発生しない。

[285] 慎重に読むと CSS とは違うことを言っています。 UTR #50 と同じかどうかは判断が難しい。

[287] CR >>286 時点では、規定内容はほぼ同じながら、 glyph ではなく glyph area が回転するしないという形になっていました。 glyph area は XSL と TTML がグリフごとに想定する表示上の単位。 規定はいくらか厳密になったといえますが、 現実のフォントの実装やレンダリング処理、 CSS との関係を考えるとき、 適切な改正だったのか判断しづらい。

[289] PR >>288 時点では、 CSS の変更に追随した改廃がありました。 慎重に読むと CSS と同じか怪しいのは変わらず。

  • [290] horizontal writing mode では無意味
  • [291] mixed: rotated glyph: sideways, non-rotated glyph: upright (rotated or not は VO 次第)。 sideways: glyph area 時計回りに90度回転 (回転はグリフ置換かアフィン変換によって行われ、 どちらになるかはフォント次第)。 upright: glyph area 何もしない。
  • [292] sideways: すべて glyph area 時計回りに90度回転。
  • [293] upright: すべての文字を Vertical_Orientation が U として扱い、 glyph area は回転しない。 グリフ置換も回転も発生しない。

(CSS と違って writing-mode には変更なし。)

[369] なお、当初は ST 428-7 との互換性を理由に下から上の縦書き対応が模索されましたが、 CSS にないという理由で対応されませんでした >>370。 (ST 428-7 は CSS の系譜に連ならない独自モデル。 書字方向 )

[385] https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20HTML%3E%0A%3Cstyle%3E%0Asection%20%7B%0A%20%20border%3A%201px%20solid%20currentcolor%3B%0A%20%20position%3A%20absolute%3B%0A%7D%0Adiv%20%7B%0A%20%20writing-mode%3A%20vertical-lr%3B%0A%20%20border%3A%201px%20solid%20gray%3B%0A%7D%0Ap%20%7B%0A%20%20writing-mode%3A%20horizontal-tb%3B%0A%7D%0A%3C%2Fstyle%3E%0A%0A%3Csection%3EX%3Cdiv%3E%3Cp%3EA%3Cp%3EB%3Cp%3EC%3C%2Fdiv%3EY%3C%2Fsection%3E%0A

[386] Chrome だと position:absolute 中の writing-mode が違うブロックに外接するよう position:absolute 箱のサイズが決められますが、 Safari はそれを無視するので、横にはみ出してしまいます。

div に min-width を指定するとそこまでは広まりますが、 内容がそれより大きければはみ出します。

[387] 再現コードをうまく作れないのですが、 条件によっては幅だけではなく高さもおかしくなるみたいです。

Updated: