DTPの現場から 〜笛の音がきこえてくる〜

Trueflow３

この記事を書くにあたって、このブログがＤＴＰブログだということを

久しぶりに思い出した　いやし　です（笑）。

いやぁ、ホントに書かなくなったねぇ。。。

書こうと思えばいくらでもありそうなものなのに、

怠慢なことこの上なしです＞＜。

まぁ、これを機会に週に一度くらいは書こうかなぁ、なんて、言ってみた。

曜日を決めるのも方法論としては面白いよね。

義務的とはいえ、それが継続につながりそうだから。

というわけで、それを後日決定しようと思います。

↑結局後回しｗｗｗ（日本人だもの）。。。

何はともあれ、休日返上で長々と機械の設置に立ち会わされ、

しかも暇つぶしのYahoo!麻雀も９連敗となると気持ちも滅入るというものです（笑）。

さらに、そんな散々な状態の中で思い出した

ファンタジーサッカーもタイムリミットギリギリで不完全燃焼。。。

ちゃんと仕事しろって？（笑）

とはいえ、代理店のかたとの業界レベルの世間話も２時間ひっぱればいいところでしょう＾＾。

とりあえず、無事Trueflowは２.２１から３へ無事バージョンアップしました。

明日からはトレーニングの予定となっております＞＜。

その後、データの移行とワークフローの再構築。

前回の導入のときと違って、たった一人の戦いではないにしろ、

面倒なことに変わりはなく、色々と知恵をしぼらなければならなくなりそう。

勝負は明日からなのだ。

ちなみにTrueflowというのは、ＤＴＰソフトで作成したデータを

印刷するために適したデータに変換する装置のことで、

ＲＩＰ（ラスターイメージプロセッサー）にあたります。

まぁ、これは話し出すと長くなるので説明はしないことにします（笑）。

興味があれば言ってください＾＾。

新たな記事として書きますから。

ないと思うけどｗｗｗ（笑）。

Microsoftという名のヤツ（笑） その１

最近、オフィス系アプリの標準化という話を聞く機会が増えている気がする。

事の発端は、人間臭い言い方をすれば、

Microsoft Officeの独占状態からの嫉妬からきているのであろうが、

考え方としては、非常にフェアで合理的だ。

何せプラットフォームを選ばず、

すべてのオフィス系アプリとの互換性を図るという考え方なのだから、

ユーザーとしては、気軽にソフトの乗り換えができちゃうというわけだ。

これには、オープンソースのオフィスソフト、OpenOffice.orgが大きく貢献している。

このソフトはオープンソース、いわゆるタダ（語弊があるが）なのに、

Microsoft Officeとほぼ互角の機能なをもち、

なおかつ、Windows、Mac（現在X11のみ対応、次バージョンで正式対応予定）、Linuxと

ほぼ全てのOSに対応している柔軟性を持っている。

この柔軟な対応が評価され、このソフトを正式採用する企業も増えてきているようだ。

こうした普及も手伝って、オフィスソフト共通のドキュメントファイルフォーマットを

策定しようという動きが生まれ、規格されたのが、ＯＤＦ（OpenDocument Format）だ。

これは、OpenOffice.org 2.0の標準ファイル形式となっている。

その後、構造化情報標準促進協会 (OASIS) 、国際標準化機構（ISO）、

国際電気標準会（IEC）によって標準規格に認定され、

一太郎 2006（追加モジュール）、KOffice、StarOffice (StarSuite) 8.0

IBM Workplace Managed Client 2.6、Writelyなどが採用を始めている。

仕様は、複数のXMLファイルをZIP形式でデータ圧縮したファイルで、

解凍ソフトで解凍すると、圧縮ファイル中のファイルとディレクトリが、

ドキュメントの実際の中身に対応している。

要するに、乱暴にいえば、ホームページのように、

HTMLファイルとリンクファイル（Image、cssなど）が整理されて格納されている感じだ。

これは、データベースなどデータの二次利用の際に有意義に活用される気がする。

ただ、圧縮形式なため解凍しながら文書を開くというレスポンスの課題はあるようだ。

とはいえ、この理想的な働きはユーザーとして歓迎すべきことであり、

今後の展開に期待が持てるというものだ。

しかし、それに対して『待った』をかけたものがいる。

そう、ヤツが動き出したのだ（笑）。

つづく。

Microsoft Officeは高くて買えないっていうかたはどうぞ＾＾→OpenOffice.org

『PAGE2007』見聞録 その３

さらにPAGE2007見聞録のつづき。

web to print以外で大きく注目されたものの一つとして、

あげられるのは実は『WindowsVista』。

もちろん内容はOSの新機能！

ではなく、地味〜に新フォントの問題点（笑）。

今回、Vistaに搭載されたMicrosoft純正のフォントは６書体。

MS明朝、MSゴシック、MSP明朝、MSPゴシック、MSUIゴシック。

さらに、新書体としてメイリオ。

メイリオとは明瞭という意味らしいが（オヤジギャグなのか？）、

画面上で綺麗に表示することを第一に設計されたクリアフォントなる書体らしい。

感じとしては新ゴのようなデザインゴシックで、少しポップな感覚を受ける。

ただ、そんなものは業界的にさしたる問題ではなく、

何がそれほど話題となっていたかというと、

今回の上記６書体において、JISの規格を変更されたということ。

業界以外の人にとっては、ピンとこないかもしれないが、

こっちでは大問題だ（笑）。

具体的にいうとJIS1990からJIS2004に変更されたということになるが、

その際に、168字の字形変更と10字の追加が行なわれている。

それはJIS上での話で、XPからVistaでの字体変更は122字、

追加文字に関しては、MS明朝系が17,807字から19,321字、

MSゴシック系が20,458字から22,213字追加されている。

ちなみにメイリオは20,684字らしい。

まぁ、書体によって文字数を変えること自体、意味わかんないですが……。

とりあえず、追加については、新書体が搭載されれば問題ないが、

字体変更は文字自体の形状が変わっちゃうので大問題になりかねない。

人名、地名などに関われば、責任問題ともなろう。

　 例えば、こんな感じだ。

字体変更は、追加文字や機種依存文字と違ってバケたりするわけではないので性格が悪い。

Microsoftは書体のバージョン違いとし（ver2.5→ver5.0）、

XPでも利用可能の対応をとっているが、これはこれで混乱を巻き起こしかねない。

先方の環境を知らない場合、出力紙なしのデータ入稿では判断がつかないということになる。

正解がわからないという最悪の状態が起きてしまうということ。

どうせならフォント名称を変えるくらいの処置はして欲しかった。

NEWでもMark2でもゼータでもダブルゼータでも何でも良いからさ（笑）。

そもそも、DTPの世界ではこういうフォントが存在しないし、

Adobeが設定してきたAdobeJapan1-なにがしの規格を完全に無視している。

これに対しては、AdobeもAdobeJapan1-5N、AdobeJapan1-6Nと苦しい処置をとっている。

また、モリサワ、フォントワークス、ダイナフォントとベンダーの対応も様々だ。

対応については、興味のある方は以下のサイトへいってみることをお薦めするとして、

こちらとしては、活気づいてきたweb to printやバリアブルなど、

データ入稿関連のフローに水をさされた感が強く。

「Microsoftめ、やってくれる……」

なんてガンダムチックなセリフを吐くに止まってしまう（クアトロ大尉口調でどうぞ）。

どうせクレームをいったところで、新しいJISの規格は国の方針だし、

みなさんで新しいフォントをつかっていただければって言われるのが目にみえている。

そんなこといったってねぇ……。

誰しもがPCに明るいわけじゃないんだよねぇって話ですよねぇ（苦笑）。

モリサワの対応

フォントワークスの対応

ダイナフォントの対応

『PAGE2007』見聞録 その２

PAGE2007見聞録のつづき。

あくまで個人的な印象として『web to print が熱い！』ということでしたが、

その火付け役というべきソリューションが『Press-sence iWay』だろう。

決して、ミニセミナーの向かって右側の司会の女の子の対応が気に入ったから紹介するのではない（笑）。

簡単にいえば、web to printの窓口的な部分を全てカバーするソフトになる。

まさに、web to printのインターフェイスを提供してくれる。



具体的にいえば、受発注やデータ入稿、変換（プリフライト含む）までをこなす優れものだ。

しかもJDF運用をすれば、あらゆる部分での自動化が約束されそう。

POD、オフセットなんでもござれというわけだ。

まぁ、今のところは、あくまで、年賀状などweb上でのサンプル選択を含めてのバリアブルや

自動組版、データ入稿といったところがメインなのだろうが、

こういった仕組みを構築するだけでも結構傷害があったりしたものだ。



webなだけに、やれHTMLだcssだ　Javascript　だ、

情報を管理するために後ろでデータベースを走らせるためにCGIがどうだって、

印刷屋の分野を超えたところで色々技術の習得が必要だったりするわけです。

この部分に業界レベルで振り回された感はいなめません。

どうしても半ば脅迫的に開発の部分の必要性が迫られていたような気がします。

僕的には、やはり餅は餅屋なんだなぁって、あらためて感じました。



概要を把握するために理解することは大切ですが、

細部まで突っ込んでしまうと力が分散化されて実力を発揮しにくくなっちゃうということ。

大切なのは、しっかりしたビジョンを持つことであって、

必要な部分は良き協力相手を得ることによって補える。

餅は餅屋、自分の分野をしっかり固めて、ベストを尽くすことが大切なのだとあらためて感じた。

まぁ、しっかりしたビジョンがあってだが……。



とにかくサーバーサイドでのサービスが中心となり、

前回記した技術を含め、あらゆるものが連携されていくことは間違いなく、

その辺りは、しっかり把握していかなくちゃなぁって思いにかられました。

そろそろ本屋へ走らなくちゃいけませんね（笑）。

つづく。

『PAGE2007』見聞録 その１

ひさびさにDTP関連の記事のアップ。

印刷業界では年に数回イベントとして展示会があるのですが、

僕は、その中の『PAGE』、『IGAS（もしくはJGAS）』に参加するケースが多いです。

『PAGE』はソフトウェア中心、『IGAS』はハードウェア中心といった感じを受けます。

ですので、今回の『PAGE』のほうが僕的には楽しいですね。

ミニセミナーも多いですし（笑）。



今回の『PAGE2007』は、おそらくMacOSX10.5とAdobeCS3が中心になるだろうと

昨年あたりは予想してたのですが、見事に間に合わなかったですね。

ですので、何がテーマとなるのだろうとある意味意地の悪い興味を持って参加しました。

まさかVistaの話題で賑わうはずもないですしね＾＾。

そこで僕が目の当たりにしたのは、すごくありふれた世界でした（笑）。

PDFワークフロー、RGBワークフロー、JDFワークフロー、POD（バリアブルを含む）などなど。

ただ、ひとつひとつ別のベクトルを持ったその技術たちが今、

同じ方向を向き、大きな流れを生もうとしている感覚を持ちましたね。

上司命令でしかたなく受けたセミナー『進化する印刷ワークフローweb to print』。

たまたまタイミングが合って受けたミニセミナー『Acrobat8とInDesignServer』。

これらの影響をモロに受けているだけかもしれませんが……。



それでも印刷業界でのwebへの取り組み自体はそれほど珍しいものではないし、

何をいまさらって感じのものではあるのも事実です。

それが新鮮にうつるのはやはり、ようやくパーツがそろってきたということじゃないのかな？

あらゆる入稿形態に対応するために必要な技術。

PDFであったり、RGBフローであったり。

クライアントに提供するサービスとしての

サーバーサイドでの画像データベースや自動組版、POD。

外部デザイナーやライターとの連携としてweb上での分業化。

さらにリモートプルーフのレベルを超えた遠隔地添削のアプローチ。

そして、印刷をトータルで管理するMISを中心としたJDF。

ハードやネットワーク環境の高速化などのパフォ−マンス向上がもたらしたものは、

本当に大きなものなのかもしれませんね。

これらがつなぎあわされて、色々な可能性を示しだしています。

これからが本当の意味でのweb to printの世界が開けていくのではないだろうか。

そんな想いにかられた今年の『PAGE2007』でした。

つづく。