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

>
>
> > こんど私がCITPCのセミナーで発表する資料 <
> https://1drv.ms/p/s!An5Z79wj5AZBgrp06H7M3ZUfkyQ4AA?e=neOwwA>です。
> >
> > 村上さんの資料 <https://blog.antenna.co.jp/CSSPage2/archives/100

> >です。古いですが今でも正しいようです。
> >
> > 角川の資料 <
> http://kadokawa-epub.bookwalker.co.jp/download/CharacterOrientationEval_JISX0213-20150123.zip?attredirects=0&d=1

> >を見ると、いかに文字横転で困っているかが
> > 分かります。しかし、大半はAmazonのバグのようです。
>
> 物理屋的なまなこで見ると問題があるところにその上にまた何かをかぶせてとやるとどうせ最終的には
> 天動説の周転円みたいに破綻していくような気がするので、いい塩梅の何か(UTR#50とか)を念頭に全体設
> 計を構築して、それぞれのコンポーネントをその何かに合わせていく努力をやって、例外を何らかのカテ
> ゴリに押し込んで個別処理する、というのが理想論かなぁ、と思うところなのです。
> # なんかどこかのミーティングでもぼやいたような気もするんですが、、。
> # 天文屋的なまなこで見ると、黒い羊のお話みたいにもっとダメになるので却下。。。
>

JIS X 0208もUnicodeもInDesign文書も巨大なレガシーで、
そこからは逃げられません。蓄積されたものが大量にあります。


> というところで、VO=Uなのにvertがあるので使われちまうとか、vertがないフォントがあるとかはそれ
> ぞれを改修していく努力を継続する(VO=Uだとvertは読まない！とかは横暴なんだろうというのはありま
> すが、、それはさておいても)というところなのだと思うのですが、いろいろ頭の中でぐるんぐるんして
>


VO=Uでvertを使いまくっているフォントもあるようです。
かつらぎフォントです。Ken Lundeから教えてもらいました。



> いるなかで、これは、逆に、U+2016みたいな
>
> 「縦書き用グリフと横書き用グリフがそれぞれ別なコードポイントで割り当てられている」
>
> というような文字が特異値、というか鬼子というか、いまはVO=Uに含められているけれど、一つまとめて
> 括らないといけない別枠だったりしないかなぁ、と思ったりもするところです(すでに出てる話でしたら
>

諸悪の根源はUnicodeだと言いたいけど、それ以前
のJISにも責任があるのかな？

ごめんなさい)。そのコードポイントたちの出自は当然ながら歴史的に必要性にかられた重大な意味のあ
> るものであるのですが、CSS writing-modeみたいに縦横を割り当てたプロパティー一発で変えられる時代
> に、元データは縦書きかもしれないけれどもそれを変換して横書きの電子書籍として出すというような
> ユースケースがもし沸き起こってきたら、逆に横書きの中で縦に立った文字が出てくることになるのかな、
> と。
>

EPUBの前の時代の国内の電子書籍リーダは、縦横切替
が出来るのが普通でした。いまでも、アクセシビリティ
を重視したEPUBリーダは縦書きと横書きの切り替えを
alternate style tag(IDPF)を使ってやっています。  縦書き
しか読めない人、横書きしか読めない人がいる以上、
やらざるを得ません。今後、商用のEPUBリーダでも
対応を期待しています。表示がどれほど変になっても
読めないよりはマシです。

<余談>そういえば、WAIの仕様で、コンテンツを利用者の
好みに応じて切り替える機構がありましたね。</余談>

村田 真


UTR#50の際にどんな議論があったのかわからずにいろいろ眺めているだけのところですが(ishiiさんご
> めんなさい、、)、シングルソースマルチアウトプットなる構想(妄想?)も聞こえる今日この頃、という文
> 脈に立つとちょっと気になるところではあります。。
>
>
>
>
>
>

-- 
Regards,
Makoto