DTPの言葉の発生の時代からクリエイティブを生業としている自分である。

その昔、書籍の発行や所有はごく一部の者の特権だった。

その後、数百年が経過し、初期の活版印刷が廃れ、より簡易で安価なオフセット印刷が現れて、世の中は大印刷時代の幕開けととなった。

和文タイプや電算写植機のオペレーターがまだ一つの職業として存在していた時代。

しかし、ツールの大衆化と価格の低下は今までは当たり前として存在していた職業に終焉を告げる。

Aldusが『PageMaker』によって提唱したDTPは、瞬く間にデザイナーを飲み込み、目の前のディスプレイで印刷物の原稿作れる時代がやってきた。

勿論ここでもツールの大衆化と低価格化は避けられない。

頭の固いデザイナーは、いつまでたっても『フォントが、、』『文字詰めだ大事だ』などと専門的な知識に逃避行する。

しかし、DTPが一つの職業として存在する時代は終った。

もう少し正確に言えば、版下を制作するという作業が専門業種が無くなりつつあるのだ。

DTPは独立した業種ではなく単なる作業でしかない。

DTPはデザインを行う者が当たり前に持つべき作業スキルの一つになった。

近い将来、DTPや組版という言葉も死語となり消えていくだろう。

※ここではDTP=コンピュータを利用した組版制作(技能)を指しています。

「簡単にレイアウトする」難しさ。

CMSを利用したサイト構築と管理はエンドユーザー向けとしても賢い選択だ。
個人的には多くの場合Joomla!CMSを利用している。
しかし多くの場合CMS導入には大きな「面倒」を抱え込む結果を生むことが多いのも事実である。
それは「CMS=簡単に記事をレイアウトしてアップできる」と勘違いしている点だ。もちろん「記事を簡単に作成してアップ」はできる。
しかし、「簡単にレイアウトする」こととは別問題だ。

「自由度の高いエディター」と「編集者のレイアウトスキル」が不可欠。

必ず分けて理解しなければならないこの問題が、多くの場合は混同され、厳密に吟味されないまま会話の中にまぎれ込んでしまう。
CMSを導入したのにエンドユーザーが自由に記事編集をできない。
手間要らずサイトを構築したはずが、いつまでたっても制作者の手を離れず、ユーザーに感謝されるどころかCMSそのものに疑念を持たれて、数年後には元の静的サイトへと逆戻りという結果も珍しくない。
それもこれこ全ては「記事を簡単に作成してアップ」できることと「簡単にレイアウトする」が同一視されていることが原因だ。
それではCMSにおいて「簡単に記事をレイアウトしてアップできる」ことは可能だろうか。
簡単にレイアウトするためには、「自由度の高いエディター」と「編集者のレイアウトスキル」が不可欠である。

「自由度の高いエディター」に対する答え「Windows Live Writer 2011」

Joomla!には標準で「TinyMCE」が装備されている。
良く出来ているエディターではあるが、殆どビギナーのエンドユーザーにとっては敷居の高いものである。
エンドユーザーの平均的なスキルとモチベーションは、「WORD程度なら知ってるかも。。。しかも新たにソフトを学習するのはイヤ! 」といった程度であると言えるだろう。
このスキルとモチベーションに対応可能な編集環境とは何だろうか。
それは以前から何度か言っている「ブログエディタ」の利用だ。
という訳で、お勧めのブログエディタと言えば、「Windows Live Writer」。
最近、joomler.netさんの記事でWindows Live Writerが2011になったと知ったので、早速ダウンロード。
Windows Live WriterとJoomla!のコンビネーションはこちらのトピックを参考に!

「編集者のレイアウトスキル」に対する答え。

この命題に対する答えは、得られていない。
レイアウトやデザイン力といったものはそれだけで、長い期間をかけ学習して身につけるものだ。
しかしながら、「自由度の高いエディター」を手に入れたエンドユーザーはきっと気付くだろう。
自分に足りなかったのはレイアウト(デザイン)力だったのだと言うことに。そしてそのレイアウト力は容易には手に入らないことにも。

仕事には必須なSketchBook Pro の最新版を遅まきながら手に入れました。
正直、前バージョンの2010は価格も機能も満足できずに購入は見合わせていましたが、今回のバージョンはコストパフォーマンス的にも納得できるものなので、購入しました。

体験版を使った限りでは相変わらずの致命的なバグ、
-マーカー描画部分などに突然にじみ状の輪ができ、しかも上書き保存されている?-
があるものの、これ以外のスケッチソフトが無いのも事実なので、 まぁ、購入しました。

ちなみに、コミュニティはこちら

長い間「WEB上で共有編集できるプロジェクト管理ソフト」を探している、もちろんフリーだ。

簡単なようで中々見つからない。 『GanttProject』なども中々良いが、共有ができない。

『OpenProj』は良くできているらしいが重くてレスポンスに難があるらしい。凡そ日本語しているらしいが、色々な人が参加するプロジェクトでは完全日本語がありがたい。

システムが高機能なほど、日本語への対応は不可欠だ。

『Trac』は高機能らしいが、インストールが面倒そうだ。

『redmine』は評判も良いが、なぜRubyなんだ。。

『gantter』 は“Gantter is a FREE web-based project management tool.”と紹介されているように、ブラウザベースのプロジェクト管理ソフトだ。
特に“google docs integration”と謳われているように、google docsとの親和性が高い。おまけに“Available in 11 languages”の中には日本語も含まれているし、ChromeとFFではエクステンション化されているので便利さMAXだ。
しかし、ガントチャートの吐き出しファイルを直接編集できない。。

プロジェクト管理ソフト」を探しのたびは続く。

フローチャート(流れ図)を書くのはとても難しい。
職業柄、色々とフローチャートを描く。
WEBサイトのフローチャート、ゲームのフローチャート、ビジネスモデルのフローチャート、その他色々。

フローチャートはその企画者の頭の中の思考を描くようなもので、どれほど考え(アイデア)が構造化されているか、またその思考を紙の上に記述(表現)できるかという2つの重要な要素が関係している。
どちらにしてもフローチャートは『設計図』そのものなので、フローチャートのできが悪いと理解やそのシステムの構築に非常な努力を要することがある。

そう、フローチャートは極めて重要なのだ。
しかし、このフローチャート、JIS企画の記号を間違い無く使い分ければ良いという訳ではない。
私自信フローチャート記述に重要要素は以下の4つだと考えている。

  1. 線の方向

    • システム設計のフローチャートなどでは条件分岐で元の位置戻るような線も存在するが、これは極力避けた方が良い。可能な限り、表現とレイアウトを工夫して一方向にフロー(流れる)ように。
      (オブジェクト処理ではフローチャートの記述そのものが不可能と思えることも多い。)
  2. 用紙の方向と大きさ

    • フローチャートは基本的に1枚の紙に収めること。
      もちろん大型のシステムでは無理なこともあるが、その場合はフロー概要を1枚にまとめて、詳細は別紙にする。
      紙のサイズはA4からA3くらいが良いだろう。
      用紙の方向は基本的に横方向だが、次の『フローの方向』とも関係し、縦方向でも可。
  3. フローの方向

    • これは非常に重要。通常のフローチャートは上から下又は左から右のパターンが多いが、システムの基本概念と一致させることが大切。例えば、何かが解決するイメージなら、上から下。何か良くなって行くイメージなら下から上なんて言うのも良いかも知れない。
      気を付けなければならないのは左から右へのフローチャート。情報記述の優先順位しては、左と上と右と下では明確な順位が存在する。つまり横方向のレイアウトの場合はフローの記述と用紙の上下、左右が完全に一致していないと、読んでいて混乱が生じる。 重要でも無い要素が上に位置したりすると何が何だか解らなくなる。
      (記述の場所が無くなって、適当に配置したりすると、、もう大変。)
  4. シンボルの描き分け

    • シンボルは描き分け過ぎない方が良い。
      共通の処理や概念は共通のシンボルを利用するのが良いが、たとえ描き分けがなくても理解できるように『流れ』を作る必要がある。


しかし、何故フローチャートが必要か?
それは他の人に対してシステムや作業の流れを説明するためである。
しかし、、、しかし、オブジェクト的な処理やプログラミングなど、実際には既存のフローチャートで記述することは無理で、新たな方策が求められている。

「ArtRage3」のための改定版、『ArtRage3で絵を描こう!』が届いた。
本書には私のこちらの絵も載せていただいている。

スタンダードな電子書籍フォーマットePUBの作成サービスを始めました。
現在はβテスト中で無料作成しています。
無料作成期間は未定で、作成ePUBファイルの修正などにも未対応ですが、宜しければご利用ください。

ArtRage3の日本語版がイーフロンティアより7月30日に発売されるようだ。
以前、ambient Design社のMatt氏にメールした時は本家よりリリースされると聞いていたが、どのような経緯かイーフロンティアより販売されるようになったらしい。
個人的には英語版を使用しているので、あまり関係無いが、まあ、、しっかりサポートさえしてくれれば良いでしょう。

先日ArtRage3で描いた、サンタの絵(第二弾)。
チェ・ゲバラをモチーフにしました。 簡単に描画プロセスを紹介しています。

 jos15Menu_3011
Step1. set a reference image and draw line to easy by pencil.

jos15Menu_3012

Step2. fill background to blue color by paint roller.

jos15Menu_3013
Step3. Face!

jos15Menu_3017 
Step4. and Red Santa outfit.

 jos15Menu_3019
Step5. easy and easy..

jos15Menu_30110

jos15Menu_30111

 

che2

Glasses.. Finish!  looks Johnny Depp?

See other ArtRage articles.

image http://threepress.org/ ではepubcheck 1.0.5 とepubpreflight 0.1.0を利用したePUBのバリデートチェックサービスを行っています。

iPadではvalidなePUBでないとダメだとか、色々な話があるので、本ブログePUB関連記事を何点か抜き出してvalidなePUB電子書籍制作を試してみました。

コンバータやソフトによるePUB制作では問題も多く見られ、今回はDreamweaverで作成しましたが、色々と面倒で、いちいちこのファイルを作成しないとダメとなるとちょっと面倒ですね。

一応、IPAフォントを埋め込んだので、iPad、EPUBReader、Reader Library、Adobe Digital Editionsでは問題無く表示されます。 

こちらでダウンロード可能ですので、試してみてください。(IPAフォント埋め込みなので4MBと大きいです。。)

 

追記:20100618

その後色々と試してみて、iPadで画像が表示されないというバグ?がありました。
ePUB的にはvalidでもiPadでは支障ありなんてこともあります。
ファイルを解析すると、幾つか制限があるようでした。現在のファイルはiPad、EPUBReader、Reader Library、Adobe Digital Editions、http://bookworm.oreilly.com/対応です。

追記:20100625

iPad(iBooks)をはじめ各リーダーソフトには色々クセがあります。
そのため変換サービスやソフトへ完全に頼ることも無理です。iBooksのカバーグラフィック対応の変換サービスはsmashwords.comくらいですが、そのソフトは手直しが必要です。

今、電子書籍はホットなニュースだ。
その中心的なファイル形式がePUBである。
ePUBはxhtml、CSS、画像などをまとめてzip圧縮したものだ。
単ファイルでの配信やDRMへの対応を考えて一塊にしたのだろう。
しかし、ePUBのレイアウト能力は非常に低いものである。
実際にはCSS2に基本対応なのだから、理屈上はかなり自在なレイアウトが可能な筈だが、リーダーソフトが対応していない。

電子書籍時代の入り口に立った日本でも、ネット上には様々な意見や考えがアップされている。
その中の幾つかは正しく、幾つかは間違っている。(、と私は思っている)


以下に巷でささやかれている意見に対して私なりの考えを簡潔にまとめてみた。

  1. ePUBで自由なレイアウトはできない。
    現在のePUBの仕様とリーダー環境では、自由なレイアウトは不可能だ。(自由とは何か、、という哲学的命題は別として)

  2. ePUBは現在の日本語文章レイアウトに対応していない。
    現在のePUBの仕様とリーダー環境では、紙書籍によく見られる日本語文章レイアウトには対応していない。
    見た目だけ良いのであれば、縦書きやルビなどもトリッキーなCSSやテーブル組みで可能かも知れないが、あまり勧められない。

  3. ePUBでは日本語の書籍(雑誌等)は作成できない。 ×
    ePUBでは日本語の書籍(雑誌等)は問題無く作成できる。
    ただ、今までの紙書籍のレイアウト、表現とは違ったものになるだけだ。
    私は日常、縦書きの文章は書かないし、ルビもふらない。
    私の話す言葉は縦書きでもないし、ルビもふられていない。

  4. InDesignでePUBは作れる。 ×
    もちろんInDesignでePUB出力は可能だが、満足のいくレイアウトが再現されるわけではない。
    InDesignで満足できるePUB出力が可能であれば10年前にWEBページはページレイアウトソフトで作成可能になっていただろう。
    InDesignに期待している人の多くは、HTMLやCSSと文章の構造化を理解していないのではないだろうか。
    ※今後InDesignの基本コンセプトが変化してソースが書き直されれば別の話。しかし、それはもはや別のソフト。

  5. PDFが良い。 × 
    もちろん間違っている。
    WEBと現在の情報電子化は人間の情報記録の歴史上、大きな変化点だ。
    そのことを理解すれば、W3Cが持つ基本コンセプトや多くの理想主義者の試みからPDFが如何に外れているのかが解る。

  6. ePUBではデザイナーの力が発揮できない。 × 
    もちろん間違いだ。
    デザインは制約された環境の上で情報を効率良く伝えることを目的としている。
    紙の書籍にも様々な制約があるように、電子書籍にも制約があるだけだ。
    これこそデザイナーの腕の見せ所だ。

  7. ePUBが流行らなくて、アプリやPDFが主流になる可能性がある。
    もちろん未来のことなんて解らないが、もしそうなれば、関係制作者(デザイナー)と多くの理想主義者の敗北だ。

  8. ePUB最高! × 
    もちろんそんな訳は無い。
    単なる通過点だ。

最近、電子書籍関連のニュースも多く個人的にも作成したりしていますが、どうも「電子書籍」という名称がややこしい。
フォーマットが違えばそのフォーマットに対応していないソフトやデバイスでは表示されないことは当たり前ですが、そのうち(既に?)FLASHで作成されたものまでもが電子書籍と呼ばれるでしょう。

その昔、「シンカ」やピーターガブリエルの「XPLORA 1」など伝説的な「マルチメディアソフト」というのもありまりました。
どちらもMACのソフトですが、今の言葉で言い換えれば、正に「新時代の電子書籍」でした。
しかしこれらは真の「電子書籍」とは言えません。

現在、世界中の出版界を巻き込み、グーテンベルグ以来の書籍革命と呼ばれる「電子書籍」の出現は過去のものとは全く異質なものです。

現在の電子書籍に必要な特徴として、以下の5項目を挙げてみました。

  1. 独立したデバイス
    少なくとも8時間以上はバッテリーが持って欲しい。
    これじゃないと、自由に本を読むなんて普通のことができない。
  2. テキストを引用(コピー)し再配布可能な構造。
    テキストじゃないと! 個人的にはDRMは×です。著作権や費用回収云々の問題じゃなく、自由じゃないからです。
  3. 出版の自由を確立するために、誰でも(多くの人に)作成可能で単純な構造。
    電子書籍の時代はself publishingの時代です。
  4. 1000年後も再生可能な記録、又は配布方式(ファイルフォーマット)
    紙書籍って以外と長持ちです。電子情報の脆弱性と未来互換の低さは危険ですね。
    これはデータをできるだけプレーンなテキストにしておく必要あり。
  5. 自由なマーケット拡大を阻害しないために、物理的な制限を設けない。
    もちろんWEBも物理的だけど、、ネットさえ繋がっていればどこへでもコンテンツが送れないと!


上記特徴の項目には、実際にはデバイスとコンテンツ(ファイル)、配布の3つが含まれていますが、 ここで問題なのが、上述した2と3(+4も)の「電子書籍フォーマット」(※1)に係わる項目です。

現在電子書籍と呼ばれるものには様々なフォーマットや方式が存在しますが、個人的にはePUB形式が適当で主流にもなると思っています。

そこでこちらも個人的に「電子書籍」を定義しました。
このあたり、簡単にでも決めておかないと、仕事の時に困りそうなので。

  • 電子書籍
    ePUB(広義ではSGMLやXMLのサブセット。)
    構造化された文章構造を持つもの。
  • アプリ書籍
    それ以外のもの(pdf,FLASH,iPhoneアプリなど)
    FLASHやアプリからxmlを読み込んで、、と言うのは今のところグレーゾーン書籍っていうことで。


勿論これはePUBが優れているという理由では無く、現状は最も適したファイルフォーマットであると言った理由です。
私自身、「ePUB最高!」なんていうスタンスではありません。
「今のところePUBかな、、HTML5でも良いけど、、」程度と思って頂ければ幸いです。

(※1)
厳密に言えば、作成と配布ファイルがあります。
紙書籍は作成と配布の情報形態は同じですが、電子書籍の場合は違ってきます。
例えば、構造化していないデザインをInDesignで作成し、ePUB化すると作成ファイルは将来的に使えないデータです。
このあたりの話は長くなりそうなので、割愛。