Supporting "not within an EM" at text-combine-upright and tts:textCombine for 縦中横 'tate-chu-yoko'

[himorin]

This issue is to track discussion originally in jlreq mail list starting from a copy from tt-module-cjk-ext-1.
Original intention is to extend width of tate-chu-yoko part in timed text over one EM and to allow overflow beyond line.

tracker in i18n-activity is w3c/i18n-activity#726, original issue is w3c/tt-module-cjk-ext-1#1

[himorin]

from 1st email

timed-text WG (字幕関係)でこんな議論が行われています。
Supporting "not within an EM" at text-combine-upright and tts:textCombine for 縦中横 'tate-chu-yoko'
w3c/tt-module-cjk-ext-1#1

実際のところ、書籍とかでは文字幅よりも広げるような処理を行っていることもある、ということですので、必要ならJLReqでの議論もあっていいのかな、という気はしているところです。

[himorin]

message from Bin-sensei

4桁のアラビア数字が問題となっているようで，これはそれなりに出てきますから，狭めたいというのは，当然に出てくる要望と思います．字幕では行間も狭いでしょうから，あまり行間へのはみ出しもできないでしょう．

なお，アラビア数字だけでなく，ラテン文字も縦中横にします．ラテン文字でも文字幅を超える例は，それなりにあり，少し程度であれば行間にはみ出せばよいのですが，いろんなケースを考えると何らかの整理した方法は必要だろと思います．

個人的にいえば，文字幅を超えるような縦中横の重要性は，私はそれほど感じていません．なぜなら，私は問題のあるものは最初から縦中横にしないからです．

しかし，私以外の人にとっては，かなり切実な問題かもしれません．特に自動処理を考えると必要性は高くなるでしょう．いくつか，これを考えるための背景などが知っておいた方がよいかもしれませんので，この際，いくつかの問題点をまとめておきます．

縦中横を最初に採用したのは写研のSAPCOLだったと思います．これを考えた際のメンバーである小野澤さんは，現在のような文中（行中）に配置するのではなく，縦組での横組にした見出しなどを処理したいがためだったような説明を以前されていました．ですから，このような問題は，開発者にとっては想定外のことかもしれません．

しかし，現在，最も使用されているのは文中（行中）に配置するケースが圧倒的に多いので，“文字幅を超えるような縦中横”の問題は，なんらかの対応が必要といえるでしょう．

次に，その重要性の判断ですが，日本語組版における数字表記の扱いともからんできます．日本語の数字表記は，主なものとして漢数字表記とアラビア数字表記があります．以前は，縦組では，原則として漢数字表記であり，それも十，百，千といった単位語を用いる方式でした．ですから，この時代に二三人と書けば，23人ではなく，概数の“にさんにん”と読みました．それが，徐々に単位語を用いない方式となりました．ですから“にさんにん”は“二、三人”と書かないと意味が通じなくなりました．

そうなると，縦組でアラビア数字にしてもよいのではという考え方が出てきます．数字表記の能力というか，意味のとりやすさでいえば，意見の違いがあるとしても，一般的にいえば，アラビア数字の方がすぐれています．その意味でも，今日では，縦組でも圧倒的にアラビア数字表記が多いでしょう．そうなると，西暦の4桁の表記の使用も多く，これの処理は，当然に大きな問題となるでしょう．

となれば，横向きに文字を傾けるよりは縦向きの方が読みやすいに決まっていますから，縦中横の使用が増え，その重要性も高くなったといえます．しかも，ラテン文字の使用も，今日では増えていますから，その意味でも縦中横の重要性も高くなったといえるでしょう．

次に，どの範囲までは，つまり文字列の全長は，どこまで考えてよいかの問題です．日本語組版は，一般的にある程度の行間を確保します．例外的な場合や辞書など特別の例を除いて，最低の行間は，通常は文字サイズの二分と考えてよいでしょう．ですから，文字列の全長は文字サイズよりは，ある程度は超えて，行間にはみ出してもよいと考えてよいでしょう．

以下は，文字列の全長が文字サイズを超えた場合に限定します．この場合の処理としては，以下のような方式が考えられます．

文字サイズや，文字の変形をしないで，そのまま平均に左右の行間にはみ出す．

なんらかの処理を施して，文字列の全長をそこで使用して文字サイズと同じにする．（ある程度はみ出しを考え，文字サイズの1.25倍，あるいは1.5倍とすることも考えられます．）

文字列を狭める方法としては，以下が考えられます．
　文字を変形（長体に）する
　文字サイズを小さくする
　字間を詰める

字幕で問題としているのは，4桁のアラビア数字でしょう．和文と組み合わせて用いるアラビア数字の字幅は，一般に二分です．ですから4桁ですと，文字列は2倍になります．ところで，活字組版時代には，アラビア数字の字幅を四分とした例がありました．ですから，4桁のアラビア数字を長体にして，文字列の全長を全角にすることは可能と考えてよいでしょう．

ただし，ラテン文字の変形は，一般に避ける傾向があるので，アラビア数字と同様に考えてよいかどうかは，意見が割れることだと思います．

ですから，縦中横の場合，以下の処理が可能になれば，よいかもしれません．

文字列の全長は，デフォルトのまま処理するこれについては，以下の3つが考えられる

原稿段階で，縦中横にする要素で文字列の全長が一定の大きさを超えるものは，縦中横の処理から除外しておく

これに加え，縦中横の文字の変形，文字サイズなどを指定することも可能なので，これと組合せてもい（自動処理にはなじまないが）

自動処理で，全長が一定の大きさを超えるものは，縦中横の処理を除外する（ここでアラビア数字とラテン文字で別扱いができれば，なおよい）

文字列の全長が一定の値を超えた場合は，自動的に一定の値に変える．（変える方法は，選択できるのが望ましといえるが，デフォルトは変形でよいかと思います）ただ，この処理ではラテン文字を含めてよいかどうかは問題となるでしょう．

さらに追加していえば，縦中横の処理で行間へのはみ出しが大きい場合，前後の行に縦中横の文字が重なってしまう場合にどうするかという問題もあるが，この場合は，自動的に行間を広げるという処理も必要になるでしょう．

以上です．

[himorin]

comment from @macnmm

インデザインの縦中横機能を開発したときは、フォントの事情で行の高さを超えるケースは多いかと思って、縦方向の幅のみが固定されています。縦中横の幅（縦方向）は他の和文と同じくて、横方向は自由です。ユーザーに任せましたので、他の行に跨がってしまうことも可能です。Requirements のガイダンスを書くなら機能の使い方は明確になりますが、開発者向けのであれば、どこが自由か、どこが固定でいいかを入れるといいと思います。

also additional

言い換えれば、インデザインの縦中横は行の高さへの影響は和文一文字のみとなっています。幅も高さも一緒で、溢れると文字は横方向に溢れます。これはwebの考え方と違います。

[himorin]

comment from @kojiishi

元々、1em幅を超える縦中横をCSSに入れなかったのは、これを入れると、行間や傍線やルビの処理を決めなければいけなくなるからでした。おそらく現実の用法としては、そのような組み合わせが起きる場合には縦中横にはしない、というのが回答だと思うのですが、CSSの機能として実装する以上、それらの挙動を決めなければならず、仕様を決めるための議論の長期化が想定されたためです。
InDesignなど対話型のアプリケーションでは、重なれば明らかにおかしいので、重ならせることで製作者に注意を催せば十分だと思われますが、contents と style の分離を目指すCSSとしてはなんらかの自動処理が必要になると思います。その辺の提案をセットで出せるのであれば、Level 4 に入れてもいいとは思いますが、傍線やルビが自動的に処理されることがセットになると複雑性が上がるため、実装側からの支持がどれほどあるかは、聞いてみないとわからないところです。

[himorin]

comment from Bin-sensei

1emを超える縦中横をCSSに入れなかった事情はわかりました．

4桁のアラビア数字など，かなり1emを超えるものは，ある意味，いろんな意味で無理をすることですので，それは，そんな無理に付き合うことはないと考えることもできるかもしれません．しかし，すこしだけ，これに関連した問題点を指摘すると，最近の事情は，やや1emを超えるものが増えると予想されることです．

1つはアラビア数字です．活字組版やコンピュータ組版の時代には，和文と組み合わせて用いるアラビア数字の字幅は常識として二分でした．ですので，何も考えなくても2桁のアラビア数字は縦中横にしても1emを超えなかったのです．

しかし，今日の和文の混植に用いるアラビア数字の字幅は二分という常識が通用しなくなっている，二分より字幅が大きくしたものがけっこう出てきたように感じています．こうした場合，2桁のアラビア数字でも，変形しないと1emに収まらないということになります．

もう1点は，ラテン文字を使用した場合です．1文字の場合は，1emを超える字幅の文字は，あまりないと考えてよいでしょうが，これに上ツキ，下ツキが付くと，やや1emをはみ出してしまうケースが結構あります．しかも，ラテン文字の変形は，望ましくないという考え方があります．これも何かしないといけないとなると……，なんとかしてという意見も出る可能性はあるかと思います．

以上です．

[himorin]

comment from @kojiishi

仕様では「UA must fit the contents within 1em」となってはいますが、BlinkとWebKitは実際には1.1emまで許しています。これくらいであれば、変形によって損なわれる美観の方が、傍線やルビと重なった時の不都合よりも大事と想定したためです。これを超えた場合、変形させる前に専用にデザインされた幅の狭い字形があればそちらを使い、それでもだめなら変形をします。
https://helpx.adobe.com/jp/fonts/using/open-type-syntax.html#hwid

1.1emまで許す部分は、以前CSSWGに一度却下されていますが、もう一度上げてみてもいいかもしれませんね。
小林先生のおっしゃる、元々小野澤さんが想定されたような利用例や、TTMLのニーズには当てはまらないかもしれませんが、TTMLはルビや傍点は使うので、どうするのでしょうね。TTMLはどちらかというとプロフェッショナルな映画の字幕などの利用を想定していると思うので、InDesign同様の「エラーにして、製作者が修正」という想定でいいのかもしれません。

[ogwata]

新聞における元素記号の組版例を見かけたのでご報告します（見出しだけでなく、本文2段目にもあります）。そもそも論になってしまいますが、私は元素記号を1文字に収めること自体に抵抗を感じています。

[palemieux]

See additional information at w3c/csswg-drafts#4319 (comment)

[akiseino]

急に登場し恐縮でございますが、IMAGICA Labの清野と申します。
面識のあるpalemieuxからこちらのトピックを教えていただきました。

弊社映画やテレビ、インターネット配信などの字幕含む映像制作を行っておりまして
映像業界にいる者の立場からコメントさせていただきます。

もともと映画の字幕では縦中横を扱うことが多くあります。
例えば部屋番号を201のように3桁で表示したり、年号を2019のように4桁で表記します。
2桁であれば通常の文字幅(1em)を超えることはないのですが、上記のような
3桁や4桁で表現することもあり、その際には1emをはみ出して表記します。
それらの具体的な表記は以下になります。
w3c/tt-module-cjk-ext-1#1
これらは作品制作時に監督や翻訳者の意図が反映されていることもあり
通常変更ができないのが実情となっています。

時代的な流れとしましては、もともと手書きで自由度の高い字幕を明記し
フィルムに焼き付けて映画を上映していた時代がありました。
その後デジタルシネマになり（字幕を画として重ね合わせることもまだ多くあるのですが）
xmlでの表記も追加されSMPTEで標準化されています。
https://ieeexplore.ieee.org/document/7291893
そしてここ数年、映画作品をインターネット配信する際にTTMLなどをベースにした
各インターネット配信事業者が定める仕様が登場し、この議論に加わった形となります。

そもそも発端となる内容や経緯が業界によって違うことは認識しておりますが、
映像業界の背景や現状など明記させていただきました。

ご不明点などございましたらご連絡のほどよろしくお願いいたします。