: 組版のルールをプレイヤー(表示装置)側にもたそうとする 意味の分からない議論

【電子書籍の(なかなか)明けない夜明け】 第12回 「意味による改行」をめぐる討論 -INTERNET Watch.


組版ルールはJavascript?などのScript化して ドキュメント側が持つべきですよね。

組版を含め表示にはいろいろルールがあると思いますが、そんなもの国によっても、言語によっても、作者によってすらちがうでしょう。

それを、いわゆるブラウザー側に持たせようとするから問題なんでしょう。

ギガ超えCPUが当たり前の昨今、そして、JITが当たり前の昨今。

そういった、異なって当たり前の部分は スクリプトにして、ブラウザ側でJITして利用すればいいだけなのでは?

数ある組版ルールをプレイヤー側に持たせるというのは、おかしいと思いました。

いまは、スクリプト言語の時代なのに、発想がバイナリ時代

それこそもう、DRMを除いて、表示系は組版系はJavascriptとCSS3 でどこまでできるか?できないならHTML5を拡張しよう。というノリでいいと思いました。

おそらく、使っているという、特殊なタグの挙動をChrome エクステンションのようにJavascriptで拡張可能にすればいいんですよね。ユーザー独自タグと その処理のJavascript化で問題ない気がします。

Comment

  1. aya @_a_t_d_ より:

    お邪魔します。。
    なんか、本文が長い時、スクリプトで処理するとどのくらいの重さになるのか気になっているのですが、それって、どうですか?ブラウザの方が早いと勝手に思っているのですが……

  2. kokorohamoe より:

    Javascript化することによる処理の劣化は一般的には4分の1とか、その程度です。
    改行処理が33ms かかるとしたら 140msぐらいかかる。という話ですが・・・
    1ページあたり 10分の1秒の処理速度の差は 人間にはわからないでしょう。

    ただし、世の中には20分の1以上遅いスクリプトを書く人がいるので、そういう人だとわかるかもしれませんね。ただそれにしても最近はJITといって
    実行時にスクリプト言語をコンパイルしてマシン語として走らせてしまうことが多いので
    スクリプト言語がボトルネックというのはあまり聞きません。

    もし、その手の処理が遅いということであればAndoridでつかっているDalvik(Java)アプリも同様に仮想VMを使ったJavascriptに近い構造ですのでAndroidアプリが重いという事になりますが そういう話は聞きません。

    JITを摘んだJavascriptが遅いというのは Javaが遅いというのと同じ議論ですが Javaが遅いという話はあまり聞きませんね。このご時世。

  3. kokorohamoe より:

    当たり前ですが、ここで言うJavascriptはC++などもチューニングできるレベルのプログラマが、ゴリゴリにチューニングしたJavascriptという物を想定しています。 だって出版社あたり1つか2つしかないのですから。そこはお金をかけるという想定です。

    しかし、その出版社ごとの組ルールを作る費用のほうが、企画策定して複数の規格をプレイヤーに積む費用よりも安いとおもう。という事です。
     
    参考までに、過去一番ひどかった例では1000倍遅いC++のコードなどを見たことがあります。
    なので、スクリプトが速いかどうかはブラウザかどうか?ではなく、スクリプトを書く人がプロフェッショナルかどうか?に依存するでしょう。

Leave a Reply

メールアドレスが公開されることはありません。

注意(NOTICE)

コメントの投稿は反映までに時間がかかる場合があります。 Post Comments may take some minutes to publish.