基礎技術研究へのとりくみ
メタ書式記述言語 Metaformat（MFML）
組版調整のルールを記述するXML語彙を公開しています。
xfy
ジャストシステム社のXML編集環境「xfy」の活用の研究・実用・提案を行なっています。
実験
- MIF（FrameMaker互換形式）をxfyで編集できるテンプレート
実用
- 抽出データ校正シート（校了DTPデータから書き出したXMLデータを帳票表示した校正用フォーム）をxfyで編集できるテンプレート
プッシュ校正
DTPデータから書き出したXMLデータを確実に修正できる方法を研究しています。
データベース/Webと組版の内容整合をいかに図るか
書き戻しデータには誤りが
DTPからXMLデータを書き出してデータベースに書き戻したりWeb等へ展開することはよくあります。
しかし通常、次のような原因で誤りが含まれてしまいます。
- 非定型な箇所はうまく書き出せないことがあります。また、
- 定型な箇所もオペレーターの個性によりうまく書き出せないデータになっていることがあります。
書き戻しデータの校正 − 本当に確実？
これを修正するために校正が必要になります。が、従来の目視方式では、次のような原因で誤りを見落とされてしまいます。
- データ仕様をよく把握していない人が校正したことによる見落とし。
- データ仕様を完全に把握している人でもうっかり見落とし。
- ぼんやり校正や手抜き校正。校正の料金体系は質よりページ数であり、見落としても罰則はないことが多いので…。
解決するには？
これを解決する方法としては、大きく2通りがありえます。
- データベースの更新とDTPデータの更新を同期させる。
- 同期させないままで、なんとかDTPからうまく書き出せるよう工夫する。
データベースの更新とDTPデータの更新を同期させる？
そもそも「なぜDTPデータから書き出しをしたいのか？」と問えば、
- データベースからDTPへ流し込んでから、
- DTPが校了するまで
であるならばその前提を解消すれば書き出しの必要もなくなる、という考え方が当然出てきます。
つまり、「DTP編集中も、赤字の反映をDTP上とDB上で同時に行わせればいいじゃないか」ということです。
DBとDTPの同時連携、というソリューション
具体的には、そのためのいろいろな製品が出ています。
そうした製品を導入した場合、DB・DTP間の同期を保つため、書き出し対象データのDTP上での修正は禁止ないし制限されるのが一般的です。
オペレーターのストレス
これはDTPのオペレーターにとっては以下のように、大きな負担と感じられます。
- 従来のように紙の上の赤字を見てDTPにそれを反映させるのでなく、DB上で反映することを学ばなければなりません。
- ないしは、DBと整合するようにつねに気をつかいながらDTPを修正することを習得する必要があります。
- ときには、赤字が反映不可能なケースも出てくるので、細かな手戻りも頻繁に発生するようになります。
- 赤字を無視したといって怒られることも出てきます。それに反論するのも疲れます。
「ただでさえ校了前の忙しいときに、何故こんな余計なことをしなければならないの…？」
システム担当 vs オペレーター
これに対してシステム側は、おおむね次のように訴えかけるのではないでしょうか。
- 時代の流れなので、慣れてほしい
- 全体の利益のため、我慢してほしい
- 運用でカバーしてほしい
システム担当 vs 校正者
あるいは矛先を変えて、工程をひとつさかのぼり、校正者に「DBシステム上での校正作業」をお願いするかもしれません。それならDBが許さない赤字は入れようがないからです。
すると今度は校正をやる側から不満が出てきます。
かりにプロ校正の方には、上と同じようなことを言って我慢してもらったとしても、しかし校正には、著者校正というものもあります。サプライヤー校正やメーカー校正であったりもします。
ひとことで言うなら、「お客様校正」です。
システム担当 vs お客様
そちらに対しても「こういう赤字や、ああいう赤字は今後入れないでください」とはなかなか言いだしにくいものです。
空気を読まないシステム担当者なら苦もなく言えてしまうかもしれませんが、たぶんその前に誰かがあわてて止めに入ってくれるでしょう。
お客様の機嫌を、現場の効率化という“些事”のために損ねるのはあまり得策ではないということで…。
システム担当 vs DTP
要するに、DTPの至上命題は上流から下流まで意思統一されています。すなわち、
- 赤字を全部反映させ、
- 納期に間に合わすこと！
そこで結局は、
- 「もう時間がなかったのでやむなく」
- 「とりあえず緊急措置としてDTPのほうだけ直しておきました」
システム担当 vs …
蟻の一穴。
こうして同期は無残に破られ、結局は書き出し後の校正は今回も必要となってしまいます。
その追加費用の原因は新しいシステムのせいにされ、「意欲的だが残念ながら失敗した試み」として、次回DTP時にはもう利用されません。
そんな悲しい結末を迎えるケースも耳にするのが実情です。
同期させないままで、なんとかDTPからうまく書き出せるよう工夫する？
そこで、「DTP・DB間の同期は大変なだけで結局無理」という考え方から、ふりだしに戻って、「なんとかDTPからうまく書き出せないだろうか？」ということを考えないといけなくなります。
そこで研究しているのが、書き出しデータのプッシュ校正です。
「プッシュ校正」と「プル校正」
従来の校正法は、成果物をただじっくりと見て、間違いの有無を読み取る、という受動的なものでした。
これに対し新しく考案した方法は、もっと押しの姿勢で積極的な「校正」であるという意味で、「プッシュ校正」と呼んでいます。（従来のやり方は「プル校正」ということになります）
プッシュ校正の手順
プッシュ校正方式とは具体的には以下の手順です。
- DTPデータから書き出しデータを作ります。
- DTPデータをコピーして、各項目を数字2桁等のハッシュに自動変換します。
- 書き出しデータをコピーして、同様にハッシュ化します。
- 上記2.を、書き出しデータと同じ構造に手入力します。
- 上記3.と4.を機械的につきあわせて、食い違いを自動検出させます。
- 食い違い箇所はどちらかが誤りなので、もし3.が誤りなら1.の該当箇所を修正します。
なお、ハッシュ関数としては、「項目の各文字のコードの和」等が自然です。
プッシュ校正の利点
この方式には、次のような大きな利点があります。
- 手作業4.は、それ自体が具体的な成果物を生み出すので、手の抜きようがない。
- 読みとばし等なく、確実に全項目のチェックがなされる。
- 手作業4.は数字入力なので、スキルや母語を問わず可能。→安く大人数でできる。
- 全項目が2文字に減るので、そのままタイプするより大幅に作業が少ない。→無節操に人海戦術ではない。
- 「校正」作業の大半は作業4.へ移行されるので、最終防衛線である品管6.の負担が最小限に軽減される。
- 必要に応じ、手作業4.の品質をも同時に評価可能。→校正の「質」を定量化できる。
プッシュ校正の皮肉
組版とデータベースのラウンドトリップの同一性担保。その捜し求めた最適解が、めぐりめぐって結局人海戦術だったというのは皮肉かもしれません。
でも今のところ、コストも品質もこれより勝る方法が見つからないように思うのです。
なぜ技術を志向するのか？
出版・印刷・各種組版をはじめとするこの文書関連業界は、
- 電子化
- ネットワーク化
- 構造化 の大きな激しい波に何度も洗われています。
- 文書更新作業の効率化であり、
- 文書更新の協同作業の緊密化であり、また、
- 文書更新の頻度向上と多媒体展開
- お客様とのやりとりの短縮化と、
- お客様の校正指示（赤字）の直接反映
その結果、かつての旧態依然とした設備産業と呼ばれていた時代とは、まったく様変わりした新しい姿を見せるようになりました。
新しい技術の可能性とは？
そして今もなお、新しい技術はめまぐるしく次々と生み出されています。それらは、研究のとりくみによっては非常に大きな可能性を秘めたものです。
その可能性とは具体的には、
どうとりくむか？
そのためには、まさに日々の編集/組版の現場に在る我々の経験から生まれるさまざまな改善のアイデアを、世界の新技術で柔軟にキャッチすることにより、
それは品質の向上と、コストの削減に直結するからです。
私たちには巨体はありませんが、少数精鋭たるの気鋭をもって、文書作成分野におけるソートリーダーをめざします。
