Re: 和欧文間の空き or Segment Break Transformation Rules

少し間をおいて考えていたのですが

   1. 和欧間アキを、空白文字が入っているとして説明するか、入っていないとして説明するか、という問題。これは、純粋に、仕様上の問題と思われる。これは、
   括弧類を半角として説明する方が都合がいいため、そういう実装がないのは承知でJLREQではそう仮定して定義する、のと同様ではないかと。
   2. 実装に対して「和字＋欧文空白＋欧字」などの組み合わせにおいて、和欧間アキのための組版規則を推奨するかどうか、という問題。
   3. Segmentation Transformation Rules に対する考え方の問題。

木田さんが整理されたいのは、１ですか、２ですか？ ３は、２には影響を受けるかもしれませんが、１とは独立で議論できる問題ではないでしょうか？

2020年4月30日(木) 0:02 Atsushi Shimono (W3C Team) <atsushi@w3.org>:

>
>
> On 2020/04/29 12:02, 木田泰夫 wrote:
> >>
>  で、和欧文間の空きにどう関わってくるかというと、ここの空間を空白文字を使って記述してもいいのではと。一般的な空白文字は、欧文書体を見ると、例えば
> Helvetica で同じサイズの和文全角と比べて三分くらい。広すぎるのですが、それこそ、空白の幅を CSS
> で調節すれば良いのですよ。空白文字がない場合の調節はすでに記述されていますよね。あってもなくても同じ結果。だって同じことを達成するのに違う言葉を使っているだけなんですから。
> >>
> >>     荒削りですが、こんな方向。どうでしょう？
> >>
> >>
> >> 「空白文字を入れず、和字と欧字の間にアキを入れる」という概念と
> >> 「空白文字を入れて、その前後が和字と欧字だったら、空白の幅を調整する」という概念
> >> の違い、という意味ですか？
> >
> > はい、その通り！
> >
> >> それはありだと思いますが、segment transfomation ruleとのかかわりがよく見えません。もう少しご説明いただけると。
> >
> > 現在の Segment Break Transformation Rules では、ここに空白文字が入ります。しかるに、JLReq
> はここに空白文字を期待していません。その齟齬は、JLReq と欧文組版の、空間を開けたいときにそれを implement
> する方法の違い、というもっと深いところに根差しています。その違いが JLReq と国際化環境との互換性を悪くしています。Segment Break
> Transformation Rules
> がどうのというより、その互換性を悪くするアーキテクチャの違いを解消したい、というのが意図です。実際に見た目上で開けるかどうかは別問題というわけ。
>
> # なんだか流れをゆがめるコメントをしてしまった(現状追認の上での次善策追及的な流れでの)感はすると
> ころではありますが、、
> 多分、～Rulesとのかかわりが、というよりは、
> ・デジタル世界における日本語組版では何が望まれるのかという追求
> ・現在のhtml/cssを含めたデジタルのドキュメントプロセッシングの中で日本語組版の要求を実現する追求
> の交錯点だと思っているところです。前者はJLReq v3の議論として追及し(ようとし)ている点であると認識
> しております。で、後者は目先のところを見たところで、まさに今繰り広げられている議論(の一部)なのか
> な、と。もちろん、CSS WG的な面での議論では後者の観点からの提案が現場で活用できる意見として求めら
> れているわけなのだと思うところですが、ある程度はsimple-rubyみたいに、前者の観点から(歴史的に導入
> された規則をそのまま持ってくるわけではないデジタル時代という観点で)の理想論を、JLReq TFでは煮詰め
> ないといけないのかな and/or 求められているのかな、と思ったりもするのです。。
>
> # という意味？流れ？で空白 vs spacingの議論は興味深いな、と思うところです。はい。
>
>
>
>