コンピューターソフトは、所有するのは贅沢品になりつつある（使用料を払って使うものへ）

　ここのサイトで、所有と共有について書いていることが多いので、そのへんについて、ウィリアムのいたずらが考えていることをまとめてみる。

---

　まず、所有しかあり得ないものというのがある。
　使うとなくなっちゃうもの。

　たとえば、ここに、バナナが１本ありました。

　もし、共有っていうことにしたら、食べられません。食べたとたんに共有できなくなります。
　でも、食べなきゃ意味ありません。
　こういう、食べたらなくなっちゃう・・とか、使ったらなくなっちゃうものは、基本的に、所有して、使用するものになります。

---

　一方、使ってもなくならないものを、所有するのは贅沢です。

　美容師さんがいたとします。美容師さんは、髪を切ってくれます。でも、その美容師さんを食べちゃうわけじゃないので（＾＾；）美容師さんは髪を切ってくれたあともいます。
　美容師さんは、なので、お客さんで共有するものです。お抱え美容師さんをつけるのは贅沢です。

　そういう概念だと、車もぜいたく品になってしまいますね。
　レンタカーで十分です。
　・・・という考えもあります。
　ただ、所有には、もうひとつあって、ずーっと使っているものでかつ、スケールメリットのないものは、所有しているほうが便利です。たとえば、冷蔵庫は、共有しているより、家庭用の冷蔵庫を買ったほうが、２４時間使っているので便利です。
　なので、車も毎日通勤や仕事で使っている人にとっては贅沢ではないです。
　まあ、週末だけなら贅沢かもしれない（贅沢が悪いわけじゃない、ただし、限度はあるが。。）

---

　このほかに、共有可能だけど、所有したほうが便利なものがあります。
　これが、本とかコンピューターソフト。
　本は、もちろん、共有することもできます。図書館で。
　でも、安ければ、いつでもどこでも見れて、書きこみ自由で便利なので、買っちゃいます。

　ソフトの場合、ネットを使って共有するというのは、昔は回線速度がおそくて不便だったので、私有化していました。

---

このように、所有するものは
・使うとなくなるもの
・いつも使っているもの
・所有のほうが共有より便利なもの
などで（まだ理由あるかも）

　上記に当てはまらない、ずーっとあるものを所有するのは贅沢だ！ということになります。

　コンピューターソフトは、以前は回線速度が遅く、インストールも大変だったので、所有したほうが便利という大義名分がありました。でも、回線速度が速くなった今、ちょっと使うだけで、インストールに時間がかかり、お金もかかるソフトは贅沢品、使用料だけ払って使えないかということになりました。ＳａａSなどは、この流れなのでしょう。

PDFファイルのＸＭＬ化は、物理構造をＸＭＬ化して、論理構造に変換したほうが・・・

　で、さっきの話の本題。
　ＸＭＬコンソーシアムＤａｙで聞いた話。

　目の不自由な方がみるための大きな教科書、拡大教科書というのがあるそうな。
　これをつくるため、文部科学省は、ＰＤＦでの提出を求めているらしい。

　ＸＭＬコンソーシアムのクロスメディアパブリッシング部会では、電子出版用のXML、JepaXを自動組版するFANTaStIKKというシステムを作り、これを使って、拡大教科書を作ろうとしているらしい・・・

---

　前に書いたように、
　ドキュメントには（いや、本当はドキュメントに限らずシステムには）

　　　・論理構造
　　　・物理構造

　の２つがある。

　教科書にした状態では、論理構造（章の見出し、本文、キーワードなど）を、物理的な紙の上のレイアウトで表現した状態になっている。

　この紙の状態をＰＤＦだと、そのまま表現する。ここでの情報の欠落は、まあないとみてよい。

　しかし、これをJepaXのような論理構造で表現しようとすると、込み入った物理情報が消える。
　また、自動組版では、一般に、このような込み入った物理構造情報は表現できない。

具体的な例を１つ

　　　　　　　　仏教の隆盛

―――――――――――――――――――――――――――→
　　　　　　飛鳥　　　　　奈良　　　　　　　平安
―――――――――――――――――――――――――――→
仏教伝来　仏教公認　　鎮護国家　南都六宗　　平安仏教
　.....　　.....　　　　.....　　.....　　　　.....　
　.....　　.....　　　　.....　　.....　　　　.....　
　.....　　.....　　　　.....　　.....　　　　.....　

つまり、年表の下に、事柄をいれ、その下に小さな文字で説明を入れたい場合、その位置に、事柄をいれたい。
この場合、ＤＴＰでは、固定的な枠（フレーム）を年表の下に作成し、そこにテキストを流し込む。

　これを文章構造にしてしまうと、年表と、事柄を別々に格納することになる。
　このとき、「事柄をここに、何行で置く！」という物理情報が消えてしまうと、
　そして、この年表の幅を広く取れないと、横に順番に並べると、枠が重なり、重ならないことを優先させると、下にびろーんとなってしまい、？？？となる。
　年表と関係無しに事柄を並べると、なにがなんだかわかんなくなる。

　枠の大きさがあれば、これは、→をつかって、交互に並べると入ることがわかる。
　（まあ、ここは手作業になると思うけど）

　このように、図と文章が関連している場合、論理構造だけでは不十分で、物理情報も必要になる。

---

　ということは、ＰＤＦから再度組反して、別の形で出したい場合は、ＰＤＦの物理構造を一度そのままＸＭＬにして、そこから論理構造を抽出し、その間に、リンクを貼るような構造にしないと、情報がぬけて、分けわかんなくなる。

　ただ、拡大したいだけであれば、ＰＤＦをそのまま大きくしたほうが、物理構造を再構成しないでいいので、簡単だ（一度論理構造にしないといけないケース＝メディアを変換したい場合＝音声読み上げ、検索など）。

　また、はじめからエディタで論理構造中心に編集して、自動組版というのは、レイアウトで複雑な物理構造を表現したい場合、無理がある。むしろ、この文章を組み合わせて、複雑な物理構造を生成する、レイアウター、具体的にはＤＴＰオペレーターが、タグを振るようにしたほうが、精緻なタグ付けができる。

（ＤＴＰオペレーターが、タグを振る＝InDesignなど、ＤＴＰソフトで、組版スタイルと論理タグの関連付けをちゃんとして、そのスタイルを守るようにして編集、ＸＭＬを書き出す。その後、物理フォーマットにもとづいたＸＭＬも書き出す。文章構造に基づいた論理的なＸＭＬを書き出す際、その文章にＩＤをふり、後に物理構造をもとにしたＸＭＬ書き出しには、その文章ＩＤを埋め込んでリンク付けをする）

　ってことで、印刷会社がこれらの操作をやって、拡大教科書はＰＤＦを拡大し、もっと、音声読み上げとか、検索のために論理構造のＸＭＬを使ったほうがいいと思うけどなあ・・・

自動組版とドキュメントの物理・論理構造、データ保持方法（ＲＤＢ，ＸＭＬ）とか。。。

　あるエントリを書こうと思ったら、その前提部分が長くなってしまったので、その前提というか、説明部分である、自動組版に関して、整理して、ここに書きます。

---

■ドキュメント構造と自動組版

　ドキュメントには（いや、本当はドキュメントに限らずシステムには）

　　　・論理構造＝文章の構造
　　　・物理構造＝文、絵（線画）、イメージをどこに、どんな形で配置するか

　の２つがある（システムの場合、モデル＝論理構造、ビュー＝物理構造と思ってください）。

　論理構造が、ある一定の法則により、物理構造に変換できる場合、

　もっと具体的に易しく言うと、
　　　　見出しとか、本文とか、文章の構造に対して、
　　　　見出しならフォント１４ポイント、２行組み、本文９ポイント、行送り１．５行のような
　　　　　　　　レイアウティングが決まっている場合、
　自動組版可能である。

---

■自動組版と、組版支援

　実際の組版を考えよう。

　論文や小説のような「読ませる」文書は、レイアウティングが一定のほうが、調べやすく、見やすい。なので、これらにおいては、自動組版だけで、十分な時がある。文章構造が決まれば、それに対応したレイアウティングが決まるからである。このような自動組版は、バッチシステムでおこなってもよい。TeXの利用なども、一考である。


　しかし、チラシなど、「見せる」文書は、非常に複雑な論理と物理の構造対応をもっていたり、レイアウターのセンスでレイアウティングして、構造の対応関係は、言葉では表現できない場合がある。また、一度レイアウトしてみて、おかしかったら、手直ししたいという場合もある。

　純粋なレイアウティングで競うようなポスターであれば、illustratorなどでやって、自動組版は行わない（この場合、テキストデータを流し込む）。
　しかし、ある程度構造化され、規則によって、ある程度の精度まで持っていけるものがある。これを半構造化と呼んでいることが多いかな？旅行パンフレットなどが、それにあたる（表枠が連結していたり、行数が違ったり・・・）。

　この場合、とりあえず、自動組版でＤＴＰに自動生成結果を読み込ませ、ＤＴＰソフトでちょっと修正して最終出力するという、組版支援が行われる。あとでの修正前提なので、これはバッチでは困る。

　なぜ、組版支援などをするか・・・これは、印刷のコスト構造による。

　たとえば、旅行パンフレットの場合、文字部分（文字組）部分と、イメージ部分（あれ、何組みっていったっけ？イメージ組？たしか、月組、星組、宙組でないことは確かなんだけど・・・）では、組版価格が異なる。
　そして、文字組部分は、複雑な表枠なのに、お金があんまりもらえない。
　そこで、その部分を機械化して、人手をかけないようにするため・・・と、聞いたことがある（だけで確かではない）

---

■自動組版と組版支援の例

　たとえば、電話帳を考えよう。
　この場合、住所がある一定文字数になったら、２行組みにして、どんどん次のページに送っていってもかまわない。こんなもんは、自動組版でよい。

　旅行パンフレットの場合、ある場合は、２段組、あるケースは、４段組とかある。

　例を示そう

　料金これは、全日
　料金こっちは、３種類

　このような場合、３種類の日にちも１種類の日にちも表現でき、それに基づいて組版方法を変える必要がある。
　今の自動組版では、ルールを書けば、これくらいはできる。

　問題は、ここの
【静岡発】東京ディズニーリゾートバスツアー★東京ディズニーシー★
の
静岡、島田、藤枝、焼津、清水、富士発/2日間
のようなケース。
Ｗｅｂだから、この組版で許されるが、本だと、「はあ？？」となってしまう。

　このような、文字が入りきらない場合、今の自動組版技術だと、これに長体（文字の高さを変えず、幅を細くして、文字を追い込む）か、フォントサイズを変える。

　しかし、ある一定以上文字があふれると、長体では不自然な字になる（つーか、読みにくい。最高長体４号（４０％）までできるけど、そこまですると、笑っちゃう字になる）。そこで、フォントサイズを落とすと・・今度、周りとの感じで不自然になる。

　人がやる場合、並体（幅を同じ、高さを変える）１０％、行送りをちょっと狭くして、１行分のスペースを作り、そこにあふれ文字を流し込む。
　このとき、行が増えるので、どの程度の間隔にすると不自然でないかの微調整をする。

　こーいうのは、コンピューターでやらせるより、人間がやったほうが早い。

　そこで、この場合は組版支援となる。
　このようなケースは、普通非常に多くあるので、現実的には自動組版でなく、組版支援でＤＴＰに流し込む形のほうが多いのかな？

---

■ＲＤＢとＸＭＬ

　構造が明確な場合は、ＲＤＢでデータを保持したほうが、入力も、自動組版も早い。

　しかし、半構造化のように、あるときは１項目、あるときは３項目と、結構項目によって変わる場合は、ＸＭＬのほうがいい。このようなものをＲＤＢで実現すると、正規化によって、表を分割し、それをＪＯＩＮするので、処理スピードが遅くなること、(RDBだと）途中からデータの書き方を変えた場合、対応できなくなってしまう（ＸＭＬだと、タグの切り替えで柔軟に対応できる）からなどのためである。

　さて、ＸＭＬのものを、ＸＳＬＴで処理するか、ＤＯＭで一度読み込み、プログラムを使って処理するかだが、構造が複雑とはいえ、条件があり、その条件がＤＴＰソフトに流し込まなくても分かるものであれば、ＸＳＬＴでよい。

　一方、流してみた組版結果によって組版が異なる場合（ある文字を修正したので、この修正箇所の枠の右側に、線を付けて欲しい＝流し込まないとどのページのどの位置に線を付けるか分からない）、ＤＯＭでプログラム処理する。そして、

１．流し込み結果がＤＴＰソフトの組版エンジン処理に依存しない場合
　　プログラムで流し込み位置を計算して、処理する

２．流し込み結果がＤＴＰソフトの組版エンジン処理に依存しない場合
　　仮に一度ＤＴＰソフトに流し込み、
　　（あふれたりして）ＮＧだったら、自動的に補正して、再度流し込む。
　　これをうまくいくまで繰り返す。

---

　といった感じだと思います。

　で、本題は、また今度書きます・・・って、おい（＾＾；）