Re: JFYI: tate-chu-yoko

仕様では「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同様の「エラーにして、製作者が修正」という想定でいいのかもしれません。

2019年7月27日(土) 16:42 Kobayashi Toshi <binn@k.email.ne.jp>:

> Koji Ishii 様
> みなさま
>
> 小林敏です
>
> 1emを超える縦中横をCSSに入れなかった事情はわかりました.
>
> 4桁のアラビア数字など,かなり1emを超えるものは,ある意味,
> いろんな意味で無理をすることですので,それは,そんな無理に付
> き合うことはないと考えることもできるかもしれません.しかし,
> すこしだけ,これに関連した問題点を指摘すると,最近の事情は,
> やや1emを超えるものが増えると予想されることです.
>
> 1つはアラビア数字です.活字組版やコンピュータ組版の時代に
> は,和文と組み合わせて用いるアラビア数字の字幅は常識として二
> 分でした.ですので,何も考えなくても2桁のアラビア数字は縦中横にしても1emを超えなかったのです.
>
> しかし,今日の和文の混植に用いるアラビア数字の字幅は二分とい
> う常識が通用しなくなっている,二分より字幅が大きくしたものが
> けっこう出てきたように感じています.こうした場合,2桁のアラ
> ビア数字でも,変形しないと1emに収まらないということになりま
> す.
>
> もう1点は,ラテン文字を使用した場合です.1文字の場合は,1em
> を超える字幅の文字は,あまりないと考えてよいでしょうが,これ
> に上ツキ,下ツキが付くと,やや1emをはみ出してしまうケースが
> 結構あります.しかも,ラテン文字の変形は,望ましくないという
> 考え方があります.これも何かしないといけないとなると……,な
> んとかしてという意見も出る可能性はあるかと思います.
>
> 以上です.
>
> Koji Ishii さん wrote
>
> >
> 元々、1em幅を超える縦中横をCSSに入れなかったのは、これを入れると、行間や傍線やルビの処理を決めなければいけなくなるからでした。おそらく現実の用法としては、そのような組み合わせが起きる場合には縦中横にはしない、というのが回答だと思うのですが、CSSの機能として実装する以上、それらの挙動を決めなければならず、仕様を決めるための議論の長期化が想定されたためです。
> >
> > InDesign
> > など対話型のアプリケーションでは、重なれば明らかにおかしいので、重ならせることで製作者に注意を催せば十分だと思われますが、contents と
> > style の分離を目指すCSSとしてはなんらかの自動処理が必要になると思います。その辺の提案をセットで出せるのであれば、Level 4
> >
> に入れてもいいとは思いますが、傍線やルビが自動的に処理されることがセットになると複雑性が上がるため、実装側からの支持がどれほどあるかは、聞いてみないとわからないところです。
> >
> > 2019年7月26日(金) 6:21 Nat McCully <nmccully@adobe.com>:
> >
> > > 追伸
> > >
> > >
> > >
> 言い換えれば、インデザインの縦中横は行の高さへの影響は和文一文字のみとなっています。幅も高さも一緒で、溢れると文字は横方向に溢れます。これはwebの考え方と違います。
> > >
> > > ナット
> > >
> > > -Nat
>
> ―――――――――――――――――――――
> 小林 敏(toshi) 2019年 7月27日
> e-mail: binn@k.email.ne.jp
> ―――――――――――――――――――――
>
>

Received on Saturday, 27 July 2019 23:33:36 UTC