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

 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 Thursday, 13 February 2020 12:05:27 UTC