データベースからＷｅｂや本、雑誌などを自動生成するＤＢ編集の考え方（その５：入力)

土日シリーズで、土曜日に書く、データベースからＷｅｂや本、雑誌などを自動生成するＤＢ編集の考え方です。

前回は、自動生成の出力についてでした。
今回は、入力についてです。

---

■入力内容

　自動編集する場合というか、手動でも、雑誌でもＷｅｂでも、とにかく編集するときに必要なものは、こんなかんじ

１．文章、写真、図などの素材

２．小組みデータ

３．レイアウトデータ

４．環境によって必要なもの
　　フォント（外字フォント含む）、ＰＰＤファイル、
　　組版規則（禁則、２分４分の文字指定）など。。。

ただし、４の環境については、環境は整っているという前提で、注意点だけを、他の話の中でするにとどめ、１～３について説明します。

---

■素材

　文章、写真、絵、すなわち、
・文字データ
・画像データ（図をドットで表したもの）
・線画データ（図を線で表したもの）
　があります。

　文章に関しては、
　　　文章そのままのものと、
　　　　　文章を。で改行して「いない」もの
　　　　　。のあと、改行し１文字下がっているもの
　　　強調するところをタグで書いてある場合、

　があります。ちなみに、。のあと１文字下がっていないし、改行しないものは、新聞記事などにあります（一見すると不便なんだけど、実は、後の工程で、字下げ指示のタグをいれるとき、スペースを切らないですむ分便利だったりすることもある。ちなみに、台湾のほうの原稿では、字下げ２文字っていうのがあるみたい）

　なお、タグが入っていない場合、外字の部分をどう表現してあるかが問題です。
　（あらかじめ決めておき、自動編集のときに、ＤＴＰ用に置き換えるか、あらかじめＤＴＰの外字表現にしておいてもらう）
　なお、丸付き数字は、ふつう２０までしかありませんが、あれは、合成文字か、外字で作ります。

　画像データはＪＰＥＧ、またはＴＩＦＦできます（ＥＰＳもあり得るかも？）。
　ＤＴＰ操作用のサムネイルと出力用のものが１つのファイルの中に入った状態でくる。。かな、いまは。。
　Ｗｅｂじゃない限り、ＰＮＧは、ありえないです（＾＾）
　逆にＷｅｂに使う場合ＴＩＦＦはないので、ニュートラルな入力というとＪＰＥＧになっちゃうんだけど、ＪＰＥＧもなあ。。どのくらい劣化させるかの話があるからなあ。。
　ま、その場で適当にあったフォーマットを考えます。

　線画データはＥＰＳかな。。もしくはイラレのaiとか。。

　なお、会社のロゴは線画の場合もありますが、外字のケースもあります。
　この場合、外字の文字幅が異常に長くなります。このことがＤＴＰ上問題起こらないか（適切な文字置きになるか）は、自動変換前に確認する必要があります。

---

■レイアウトデータ

　素材をレイアウトしていくわけですが、直接レイアウトするというよりかは、

・ある意味的なまとまり＝小組みを作り、
・小組みに素材を配置して
・その小組みをレイアウト上、どこにおくかという情報を書いておいて
　それにもとづいて、小組みをレイアウトするという手法をとります。

　このとき、「その小組みをレイアウト上、どこにおくかという情報」がレイアウトデータとなります。
　ＤＴＰソフトをつかって、レイアウティングしてもらい、それをテキストで書き出すというような場合もあるし、あらかじめ決まった方法でテキストで作っておくなんていう場合もあります。
　なお、レイアウトは条件によって変わる（この小組みがきたら、２段抜きとか）ようにしておく場合もあります。

---

■小組みデータ

　上の説明にある「小組みに素材を配置して」に対して、どのように素材を小組み内のある位置に置くかという指示を書いたものです。

　なお、文字の組版規則（禁則文字や、分離禁止文字、文字置きの際の２分アキ、４分アキの規定、追い込み順序など）などは、ＤＴＰのほうにあらかじめ読み込ませておき、自動編集のほうでは、そーいう細かい処理をさせないほうが、よいのですが、どーしてもやんないといけない場合は、そーいうデータも作っておくことになります。

　ただし、外字に関しては、なんらかの対処をしないといけないことも多い（外字コードを書き出すとか）

　まあ、これらの指示は独自フォーマットで書くことになるかなあ。。

---

■注意点

　フォントに関して、自動編集を行う場合と出力先が違うＯＳのときに注意。
　ＤＴＰに書き出すのであれば、対応できるけど、そうでなくって、
　　　自動編集をWindows上で行い、ゲラをＰＳ出力して
　　　それをＭａｃに持っていき、そのWindowsのＰＳファイルを。。。

　なんていう場合、Windowsのフォント名で書き出すと。。。っていうことがある。
　また、もっと単純ミスで、そもそもフォントがない！（埋め込みにもしてない）っていうこともある。

　また、逆に埋め込みの場合、古い出力機で問題が。。もうさすがにおきねーか。
　昔はWindowsで埋め込みでＲＩＰかかんなかったり、埋め込まないと文字化けしたりした。

　あと、ＯＬＥを使っている場合、ＯＬＥの部分をＥＰＳにして、ＲＩＰかけると荒画像で出てしまうなんていうことが昔はあった気がした。。いまもかしら？

---

てなかんじで、入力と出力を書いたので、今度は肝心の中身の処理について書いていきたいと思います。

フレームワークは開発標準を規定する

　昨日のアクティビティのはなしで、「開発標準」と書くべきところを「フレームワーク」とかいてしまっているので、ここで、開発標準とフレームワークについてと、その関係について、ちょっと書いてみたいと思います。
　これ、昨日書いた東芝ソリューションのＢＲＥＷにおけるフレームワークとも関係してくるので。。。

---

■開発標準とフレームワーク

　開発標準とは、開発する際の手順を標準化したものです。
　富士通においてはＣｏｍｐｏｒｎｅｎｔＡＡなどを意味します。
　（各社あるが、公開されていないので、公開されている開発標準を選びました　＾＾；）

　一方、フレームワークとは、システムを開発するとき、そのシステムの土台となるアーキテクチャ（システムの基本構造）をさします。アプリケーションは、フレームワークの上に構築されるので（実際にはフレームワークから呼び出されるので）、フレームワークの制約に従うことになります。
　Ｓｔｒｕｔｓや、.netフレームワークなどがコレにあたります。

　っていうことで、開発標準は、標準化された開発手順等＝手順＋アルファ、
　フレームワークはシステムの基本構造＝プログラム構造、ぜんぜん違うものです。

---

■開発標準は、フレームワークに大きく左右される。

　しかし、まったく関係ないかというと大アリで、フレームワークが決まってしまうと、外部設計以降の手順が決まってしまったり、大きく制約を受けたりします。

多くの開発標準では、

　　要件定義
　　外部設計
　　詳細設計
　　テスト
　　運用

　というフェーズをとります（もっと細かい場合ももちろんあるけど）
　このうち、要件定義は、影響を受けにくいのですが、それ以降は、フレームワークに基づいて、設計が決まってしまうのです。
　具体的に言うと、外部設計の中に画面設計がありますが、画面設計で、いくら私は、こんな画面が作りたいと主張しても、フレームワーク的に作れなかったら、つくれないです。その画面は。

　そして、画面からイベントが発生し、そのイベントを処理するクラスができ。。。というカタチから、要求を満たすには、どこかの画面で何かのイベントをおこし、その要求を満たす処理を実行しないといけません。。っていうような、要求と画面が結びついたフレームワークもあるし、一方、バッチプログラムを作るフレームワークでは、画面なんて考えませんから、そんな作業はいりません。

　ということで、フレームワークには、それに向いた開発標準というのがあります。
　そのため、開発標準とフレームワークは結びついてしまうんです。（要求仕様以降は）

---

■Ｓｔｒｕｔｓにおける開発標準

　たとえば、Ｓｔｒｕｔｓの場合で考えると

１．まず、画面周りをhtmlファイルでつくる（ボタンをおして、次の画面に切り替わるぐらいまでつくっておく）

２．その画面のＨＴＭＬの、buttonやSubmitのところのなかで、サーバーに処理に行くものを選んで、.doとする

３．ＨＴＭＬファイルから、とりあえずActionFormをつくる（inputのところがそうなる）

４．ダミーで.doのところのActionクラスを作る（正常系の画面に遷移するだけにする）

５．クラスはできたのでstruts-config.xmlを書く

６．１で作ったＨＴＭＬファイルをＳｔｒｕｔｓタグにして、ＪＳＰにする

７．配置して、動くかどうか確かめる（ダミーでうごくはず）

８．４のダミーの部分を入れる

９．出来上がったらテストする

という形になる。今回はＤＢのほうを抜いているので実際にはＤＢの作業が入る。

で、このとき、１が外部設計の画面、２がインターフェース設計で、ここまでが、外部設計。詳細設計は８の部分で考えることになるけど、そのまえに、プログラムを作って確認してしまうということになる（テストファーストっぽいことになるんだね。結局）。

　で、８の部分で考えた設計が、実際にプログラムされて、つながっていって、最後にテストで通すことになる。
　つまり、この設計方法では、外部から内部へとだんだんとテストしていくので、プログラム完了しているときにはテストは終わっているはずで、（テストファーストだから）テスト工程というのは、単なる確認作業になる。

　これが、単体テストを省略する論理的根拠となっている。

　ってなかんじ。。。

---

■ということは、フレームワークができると、開発的には大きい

　ＢＲＥＷの件でいうと、ＢＲＥＷのフレームワークができたということは、それにあった開発標準が作れるということで、そーなってくると、開発の手順が見えてくるので、これは、ちゃんとした開発と管理をやろうという場合には、おおきな意味があるものだと思う。まあ、今回の東芝ソリューションのフレームワークが、開発標準までにらんだものなのかどうかっていうのはわかんないけど、現行の開発標準に取り込まれたり、新しい開発標準ができてくるのは時間の問題だろう。

---

■ただし、要件定義は規定できない

　ただし、どんなフレームワークでも、要件定義の、「何をつくるか？」っていうところまでは規定できない。フレームワークはあくまで、どうやって作るかであり、何をつくってもＯＫ（っていっても、Ｓｔｒｕｔｓで組み込み作るやつはいないけど。.netで組み込みって言うのは、あり？ナシ？）っていうかんじなので。。

　一方、各社の開発標準には、要求仕様をきめる部分も含まれている。

---

　ってなところですかね・・・