Re: JLReq の文字クラスと Unicode の文字クラスとの関係

下農さんお帰りなさい🛬（入れ替わりで私は19日から数日間だけですが US です）

> あ、PAGE2020盛り上がったようでおめでとうございました ;)

どうも。Twitter に、冊子の優位性がデジタルでは消滅する、という部分に反応したコメントがありました。こういうテクノロジーの影響など、基盤というか前提条件をなす部分について、もっと知見の発掘と議論があるといいなと思いました。

> 実際にはフォントシステムがやっているのだと思っていますが違いますかね。テキストは html だけではありませんし。
>> 
>> 　とは思ったりはするのですが、、現実的にフォントは情報を持ってるだけで(不完全な情報の状態を含め)いろいろ合わせて誰かがやらないといけないところなはずで、簡単にレイヤー分離はできないところで、どう整理するのがいいのかなぁ、などなどと、、。縦書きの時に回るべきフォントが云々もその一例かもしれませんが。


他にも特定のテーブルがあったりなかったり、テーブルのフォーマットも OpenType だったりオリジナル TrueType だったり、そういうところもアプリケーションに任せずにきちんと吸収して欲しいんだけれど、Apple の CTFont などはどうなんだろう。縦書きで回転が不安定な問題もそういう下層の API で吸収できる部分があるのかもしれません。これ、真面目に調査しておくべきかも。

>> 　そういえば近い(?)話でこういうのも出ています。
>> https://github.com/w3c/clreq/issues/245



この辺りを見て思うのですが、組版ルールの言語間でのコンパチビリティ。言語依存の部分がどうしても残ってしまうのは仕方がないとしても、合わせられる部分では合わせられるといいですね。組版ルールの大統一理論とか

木田

> 2020/02/13 21:05、Atsushi Shimono (W3C Team) <atsushi@w3.org>のメール:
> 
> 　shimonoです
> 
> # ようやく旅(immersive-web WG F2F)やらイベントやらでのオフラインから戻ってきました、、
> 　あ、PAGE2020盛り上がったようでおめでとうございました ;)
> 
> On 2020/02/04 11:23, 木田泰夫 wrote:
>>>>>   JLReq 文字クラスが影響を与えるのは：A) 改行（分割の可否）、B) デフォルトの空き量、C) 行長の調整のための開け詰め、D) 本文の記述、でしょうか。文字詰めも Unicode に定義されているんですか？
>>>>> ここがちょっとグレーなところで、justification は一度却下されています。その理由としては、Unicodeは情報交換符号であり、レイアウトは上のレイヤー、ということが原則なんですが、Bidi や Vertical_Orientation はレイアウトに拘りますし、そもそも改行規則もレイアウトと言える分野なので、条件が合って、うまく説得できれば、というグレーエリアです。Aを中心に持っていきつつ、B-Dも潜り込ませられれば、という塩梅でしょうか。
>>>> まあね。plane text に justification が必要か？と問うて私も dismiss しますね ;)
>>>> と言いつつ、ICU というもっと踏み込んだ存在もありますし、ever updating unicode に対していつも適切な行長の調整を行うために何が必要かと言う議論は valid ですよね。
>>> # 最近、また別な問題を巻き込むだけだとは思いつつも、表示とデータの分離という意味では、縦横での
>>> font shapeの切り替えはどっちかというとフォントでちゃんとやるべき話(いや、XML/XSLTとかの歴史に
>>> 学べ(!?)というのはさておき)だよなぁ、とか思ったりとか、、"文字"そのものが持つべき属性ってどこ
>>> までなんだろうなぁ、と、フォントとかharfbuzzとかなどなどの領域をちゃんと勉強しないとと思うとこ
>>> ろです。。
>> 実際にはフォントシステムがやっているのだと思っていますが違いますかね。テキストは html だけではありませんし。
> 
> 　とは思ったりはするのですが、、現実的にフォントは情報を持ってるだけで(不完全な情報の状態を含め)い
> ろいろ合わせて誰かがやらないといけないところなはずで、簡単にレイヤー分離はできないところで、どう整
> 理するのがいいのかなぁ、などなどと、、。縦書きの時に回るべきフォントが云々もその一例かもしれません
> が。
> 
> 　そういえば近い(?)話でこういうのも出ています。
> https://github.com/w3c/clreq/issues/245

>> Need to tailor UAX #14 for line-breaking with quotation marks
> 
> 
>>> 　逆に、日本語的には、ものすごーく乱雑な議論かなとは思うのですが、
>>> Line_Break = Open_Punctuation かつ East_Asian_Width = Wide
>>> は前(後)条件によっては0.5em削る、みたいな、CJではEast_Asian_Widthをちゃんと使えるように条件が
>>> 整うといいのかなぁ、と、学習中の門前の小僧はナイーブに(理想論を)妄想したりするところではありま
>>> す。。
>>> # まぁ、でも、そんなand条件のプロパティー利用をはめちゃうと、逆にunicodeのレイヤーに妙な制約を
>>> 課しちゃうことになっていかんという話なのだとは思うのですが。
>> そんなふうに簡単に行く場合もあるんじゃないかと期待しているのですが。神は詳細に宿る。難しさも詳細に宿るので、真剣に見てみないとわからないかもしれませんね。
> 
>  +1

Received on Friday, 14 February 2020 00:23:36 UTC