overprint

印刷とそれ以上の何かについて(少し電子書籍寄り)。気が向いただけでは更新されません。

INDD 2012 Tokyo (続)

INDDの感想をこっそり書いてたら早々に公式に捕捉されてた…。こうなったら各セッションについてもうちょっと書いてみよう。

B-1 電子書籍オーバービュー

前回も書きましたが、このイベントの参加者層がよくわかっていなかったので、最初のセッションがどういう内容でくるかが楽しみだったのですが、境氏は最新情報を容赦なくガンガン詰め込んできて、かなりのボリュームでした。これで打ちのめされた人もいるんじゃないでしょうか。

この後、前回書いたAmazon PODの紹介があったのですが、前回の補足をすると、「DSP/RTBオーディエンスターゲティング入門」は発売1ヶ月くらいで1000冊も販売したそうです。デジタル版(PDF&EPUB3)が1890円なのに対し、POD版は2940円と割高なのですが、POD版のほうが売れているということです。内容によって電子書籍とPODで売れ方が変わるのかもしれません*1

DSP/RTBオーディエンスターゲティング入門 ビッグデータ時代に実現する「枠」から「人」への広告革命 (Next Publishing)

DSP/RTBオーディエンスターゲティング入門 ビッグデータ時代に実現する「枠」から「人」への広告革命 (Next Publishing)

B-2 EPUB概要、事例

ここからは各フォーマットごとの解説といった感じになります。が、このセッションまでは特にInDesignに関係なく…。

林氏の説明はEPUBの基本的な解説、中でもEPUB2の経緯を踏まえた上でEPUB3の解説をされたのはすごくわかりやすかったです。

高瀬氏は現状のリーディングシステムで組版表現がどの程度対応しているかを調査報告されていて、この資料EPUB制作に関わる人にはかなり有用だと思います。

佐々木氏は実際にEPUB電子書籍(雑誌)を制作する側からの事例を紹介されたのですが、音楽系の場合、楽曲の映像や音声を加えると著作権使用料がかなり負担になってしまうという話が印象的でした。伊集院静「なぎさホテル」電子書籍には井上陽水の楽曲が使われているそうで、その結果販売価格の7%をJASRACに支払っているとのこと。
コスト的にはバカにならない額なので、佐々木氏が制作する音楽雑誌では、場合によってはリハーサル映像を追加しても曲が始まると音を消すといった涙ぐましい手間をかけているそうです。

このセッション3名ともすごく面白い内容だったのですが、45分に詰め込んでしまったため駆け足になっていたのが本当に残念でした。それぞれ別のセッションでじっくり聞きたかったです。

B-3 EPUB制作におけるInDesignの活用

ここから(やっと)InDesignを使った内容に。まずはEPUB。CS6で強化された機能を紹介しながらInDesignを使ったEPUB制作のワークフローを解説されました。

私自身はまだInDesignCS6は使っていないし、EPUB制作にInDesignを使ったことがないので詳細な解説はできませんが、以前のバージョンに比べて機能が増えて便利になったとはいえ、まだまだけっこう大変そうだという印象でした。

とはいえ、これは機能的な問題というよりは、これまでのInDesignアプリケーションの目的も、ユーザーの指向も、リフロー型EPUBとは方向性が違っているためなのではないかと思います。ページサイズを決めてその中に収まるようにレイアウトをして、文字をきっちりと読みやすいように並べていく…ということを前提にしている人たちには、リフローなんて言われてもピンとこない人もいるだろうし、結果的に出来上がったEPUBを見てもアラばかりが目についてしまうのではないでしょうか。

個人的にはInDesignEPUBなら固定レイアウトのみに対応して、リフローの場合はDreamweaverで修正しやすいデータを書き出すことに特化したほうがよいんじゃないかと思います。

B-4 ADPSことはじめ(InDesignの電子雑誌ソリューション)

InDesign電子書籍と言えばADPS…と言える状況ではないのが残念といえば残念ですが*2、そんな状況で樋口氏が提案するのは「ADPSでインタラクティブなプレゼン資料をつくろう」ということでした。

制作会社が作ったプレゼン資料をAcrobat.comにアップして、各営業がiPadにダウンロードしてプレゼンに使用するということですが、この領域は電子書籍とは異なるかもしれないけど確実にニーズはあると思います。しかもこれだとAdobeにお金払う必要がない(笑)

とはいえ、こういう使い方だと現時点ではiBooksAuthorと競合してしまうような気がします。.ibooksファイルは無料コンテンツなら配布自由なので、ADPSが.folioファイルとして単体で配布ができない現状を考えるとiBooksAuthorのほうが便利なのではないでしょうか。逆に更新が多い場合や特定多数向けに配信したい場合は、acrobat.com経由で強制的にアップデートされるのはADPSのほうが便利だと思います。

もっとも最大の問題はこういうニーズとAdobeの戦略が噛み合っていないということに尽きるのですが。今のやり方ではユーザーも増えにくいし、本当にもったいない。

B-5 InDesignのもうひとつの電子書籍ソリューション「MCBook/MCMagazine」

モリサワ電子書籍MCBookと電子雑誌MCMagazineの紹介。これは試しに使ってみるというわけにはいかないので詳しいことはまったく知らなかったのですが。

MCBook自体のアプリケーションがWindows用で、iOSアプリ化はMacでおこなうという、WindowsとMacの両環境が必要というのはなかなかハードルが高い気がしました。

あとMCMagazineの特徴で述べられていた、テキスト部分が別ウインドウでリフロー形式になりモリサワフォントが使えるというのは本当に便利なのか疑問でした。元のテキストと同じフォントならともかく、別のフォントじゃ見づらくなる(元のテキストとのつながりが分かりにくくなる)のではないかと思いますが…。

B-6パネルディスカッション「電子書籍はビジネスになるのか? どうやったらビジネスにできるのか?」

最後はパネルディスカッションですが、これはちょっと盛り上がりに欠けた印象でした。これまでのセッションがフォーマットやツールの話ばかりだったので、その後でビジネスに関するディスカッションというのもちょっと難しかったのかもしれません。*3

「ビジネスになる」と一言で言っても、書籍と雑誌、制作と販売、BtoBかBtoCか、などによっても内容が変わってくるでしょうから、そこをひとまとめにしても議論が深まらないように感じました。
もっとも参加者がどういう内容に関心があるのかわからない状況でディスカッションをするのも難しいだろうとは思いますが。

*1:例えば会社で購入するような本の場合はPODのほうが売れるとか

*2:いちおう最初期から試していたので少なからず期待はしているのです

*3:ほぼ唯一ビジネスに関する話をした佐々木氏が加わっていればまた違ったのかも

INDD 2012 Tokyo

InDesignユーザーの祭典」INDD 2012 Tokyo に行ってきました。

InDesignトラック(DTP向け)と電子書籍トラックの二つが同時に行われたのですが、私は電子書籍トラックに参加。「InDesignユーザー」だからInDesignトラックのほうが多いのは当然でしょうし、私も仕事的にはこちらに出るべきなのですが、個人的な興味は電子書籍のほうだったので電子書籍トラックにしました。*1

とはいえInDesignイベントで電子書籍ネタに参加する人たちがどういう立場なのかよくわからなかったのですが、制作関係が多かったのかな?

最初の境祐司氏のセッションからもうかなりの情報量で、続くEPUB、ADPS、MCBook/MCMagazineと各フォーマットの解説も45分では到底収まりきらない濃密な内容でお腹いっぱいでした。*2

率直な感想としては、「これInDesignイベントじゃなく電書イベントとして宣伝したら倍以上人数集まるんじゃないか?」と思いました。とはいえ進行、運営も含めてすばらしいイベントだったと思います。

Amazon POD

当初予定になかったセッションとして、Amazonのオンデマンド書籍印刷サービスが紹介されていました。仕事的にはこちらの方が電子書籍よりも少し近いこともあり、とても興味深い内容でしたのですこしご紹介。

オンデマンド書籍印刷といえばEspresso Book Machineを使った三省堂書店のサービスが有名ですが、三省堂のが表紙は単にインクジェットプリンタでカラー出力しただけなのに対して、Amazon PODはPP加工(ラミネート)されていました。また本文用紙も三省堂のに比べて厚めの紙が使われていて写真等もきれいに印刷されていた印象を受けました。

Espresso Book MachineはXEROXのモノクロレーザープリンタに表紙印刷用のカラーインクジェットプリンタを付け、出力からくるみ製本&三方裁ちをすべて自動でやってしまうのですが、Amazonのは各工程の橋渡しを人がやっているのではないかと思います。となると製造コストはAmazonのほうがかかっていると思いますが、紹介されていた書籍では三省堂もAmazonも販売価格は同じだそうです。ということは出版社の利益率が異なるということなのでしょうか?

注文から24時間以内に印刷〜発送を行い、在庫切れ表示は出さないということだそうです。しっかりしたロジスティクスを握っているところがこういうサービスを行うと、普通の印刷会社がいくらがんばっても勝てないんじゃないかという気もします…。

ちなみに三省堂書店はEspresso Book Machineのシステム使ってオリジナルリングノートの販売をやっているようです。書籍印刷だけじゃあまりプリンタ回らないのかな…。


日本の電子出版を創ってきた男たち (OnDeck Books(Next Publishing))

日本の電子出版を創ってきた男たち (OnDeck Books(Next Publishing))

*1:後で映像が公開されるという話だったのでどちらも見られるのが分かっていたというのもありますが

*2:本当は内容についていくのに相当エネルギー使ったので、かなりお腹すいてたところにAdobeからの差し入れで助かった

電子書籍と日本語組版 - 「W3C技術ノート 日本語組版処理の要件」出版記念

日本語組版処理の要件 第2版」(Requirements for Japanese Text Layout 以下JLREQ)完成とその書籍版の出版記念として、2012年4月23日に開催されたJAGATセミナーに参加してきました。
以前参加した「EPUB3策定の経緯と電子書籍の今後」と関連した感じで、すごくおもしろかったです。というわけでつたないまとめですがレポートします。

ちなみに当日のプレゼン資料はJAGATのページからダウンロードできますがzipファイルにパスワードかけられているという…。資料くらい公開してもいいと思うんだけど…。

参考:togetter「W3C技術ノート 日本語組版処理の要件」出版記念セミナー まとめ

小林龍生氏「W3C日本語組版処理の要件の発刊に際して」

  • JAGATのセミナーでこんなに人が集まったのははじめてでは?(2部屋開放されていた)
  • JLREQはだれでも無料で読める
  • JLREQが出たあと、それが影響を与えたEPUBCSSについてこれから紹介
  • JLREQ作成に関わった関係者を紹介

イースト高瀬拓史氏「日本語組版の要件とEPUB3」

  • EPUBフォーマットの制定に際してJLREQと深いつながりがある
  • 2009年末から2010年あたりの話。もうけっこう時間たったけどまだそれほど普及しないね>EPUB
  • 2009年11月12日 JEPA EPUB研究会発足
  • 2010年1月22日 JEPA IPDFに加盟
  • 2010年1月27日 iPad発表
    • iBooksで採用されたEPUBに関心が集まった。EPUB仕様書に3000件くらいアクセスがあった
  • 研究会に技術に明るい人がいなかった→2月 村田真氏がEPUB研究会に参加
  • 当時は独自の技術仕様を策定する計画だったが、EPUB仕様改定に対して要求仕様をまとめることに→ここでJLREQがすごく役に立った
  • 2010年4月1日 EPUB日本語要求仕様→JLREQへのリンクだらけ
  • 短期間で仕様をまとめることができたのはJLREQのおかげ
  • 出版と無縁だった高瀬氏にとって最良の入門書

村田真氏「W3C日本語組版ノートとEPUB3」

資料:http://www.slideshare.net/MURATAMakoto/w3-cepub3

主要なマイルストーン
  • JEPAによる要求仕様がチャーターからリファされた→要求仕様に徹していたため
  • 国際化サブグループを設立して村田氏がコーディネーターになった
  • 国際化サブグループの要求仕様→ここで入らない要求は議題にされなかった
IDPF国際化サブグループ札幌会議
  • 要求仕様をまとめることに徹する
  • コーディネーターとして村田氏は相当な恐怖と不安に襲われた→これが仕様を出す最後のチャンスだった
  • 参加メンバーのほぼ全員と面識がなかった
  • JEPAとMicrosoftだけが支援してくれた
JLREQの果たした役割
  • 要求を整理する基準になった→詳細な記述で全員が確認できた
  • 台湾はJLREQをすべて見た上で、そこに記述されていない差分のみを主張してきた
  • JLREQがなかったら言葉の整理だけで何日かかったかわからない
JLREQの恩恵にあずかる人たち
  • EPUBCSS、XSL-FO、OOXML、ODF
  • 日本だけでなく台湾、香港、中国、内モンゴルなど
  • 韓国はJLREQを参考に韓国語組版の要件を作ろうとしている
  • 個人的には電子書籍関係のどのプロジェクトよりも日本語にとって最も重要だと思う。不滅の業績だと言える
JLREQの本質的な意義
  • 日本語組版を客観視して相対化したこと(=国際化)
  • 他者(外国)はどこが同じで、どこが違うのかを認識することができた

石井宏治氏「W3C日本語組版ノートとCSS3」

  • 1993年のJIS X 4051から、Word、IEの日本語組版の実装とCSS規格制定の歴史を紹介
  • 日本語が読めない人でもJLREQを参照して仕様策定の参考にできた
JLREQの仕様をどこまで実現できているのか

JLREQを基に、それがCSSEPUBなどの仕様、Word、IE、Webkitなどの実装でどれくらい対応できているのかを細かく紹介されていました。これ資料的にすごく有用だと思うのでぜひ一般公開していただきたいところ。

2012-04-27 追記
石井さんが資料を公開してくださいました。ありがとうございます!
http://www.slideshare.net/kojiishi/w3ccss3-201203-jagat

今後の課題
  • 実装のためにも安定化を進める
  • Firefoxで縦書きが実装され始めている
  • 相互運用性の確保を進める
  • 日本語特有の問題を進める→ルビ、行取り等
  • 高度なレイアウト、ページ組版など→AdobeやMicrosoftが実装を進めている

アンテナハウス石野恵一郎氏「AHFormatterによるJLREQの自動組版

書籍版の制作を担当したアンテナハウス石野氏による裏話(?)

参考:AH Formatter V6 による JLReq の自動組版

  • AHFormatter v6で書籍版の制作をほぼ自動化で進めた
  • 制作と機能実装を並行して進めた
  • XHTML用のXSLTが既存だったのでCSS組版した
  • 図版画像はぜんぶ新規にSVG化した
  • 索引を作るのに苦労した
ワークフロー
  • Web用のXHTMLと書籍用のXHTMLは別なものを作った
  • 本文中に画像の色を述べた箇所→モノクロ書籍では通じない
  • 小林敏先生の要求が厳しかった
  • CSSはアンテナハウス独自拡張を多様(ベンダプリフィックス:-ah-)
  • 索引…索引項目をspanで囲んで読みを追加
  • 追加拡張…実装と同時に進めるのでやりたい放題
  • ページをほぼ占める図版が連続した場合の処理が相当大変だった

モリサワ「JLREQと電子書籍における組版処理の実装」

モリサワの紹介と、MCBookでの組版実装のデモンストレーションだったので、細かいレポートは省略。デモンストレーションの時に関係者が「もうちょっとウインドウ小さくしてみて」「うーん、おしい」とか食いついてたのがなんか微笑ましかったです。

パネルディスカッション

最後に関係者によるパネルディスカッションが行われました。

モデレータ鎌田氏:日本語の文化と国際化

《視点》

  • 文化について
    • culture:社会の中の振る舞いの総体
    • Culture:上位文化
  • 日本語情報処理について
    • 定義と可視化によって適用領域を広げる
  • 日本語の国際化について
パネリストより

高瀬氏:

  • 自分(日本語組版)を客観化するということはEPUB仕様を通して実感している
  • これまで無意識で当たり前だと思っていたことが実はルール化できていなかった
  • JLREQには「体裁がよい」という表現がでてくるが、それをなぜ体裁がよいと感じるのか。UX(ユーザーエクスペリエンス)としての読書体験に影響を与えているのか考えるきっかけになるのかも

モリサワ小野氏に対する質問:

  • モリサワ組版エンジンを海外展開する計画は?→アジア圏では引き合いがあるが、欧米では未定

小林敏氏:

  • 「体裁がよい」とは、誤読されない、読みやすい、見て気持ちよいということ
  • 経験の世界→職人仕事
  • まず問題を明らかにすることが重要
  • 本を読むときも問題を意識しながら(例:行間の問題)
  • 新しい問題について考える

アンテナハウス石野氏に代わり会場にいた小林社長:

  • 仕様を知っていれば言語を知らなくても組版できる→マーケットが開ける
  • JLREQのおかげで言語を知らなくても海外のメーカーが組版実装を開発できる
  • 我々も海外に出ていかなければならない


小林龍生氏:

  • UTR#50仕様策定に際して、非日本人のエディタがJLREQを参照して仕様をまとめ、それにたいして日本人を交えて議論をしているという状況はすごいこと

石井氏:

  • 自分は気が長いので、海外の優れたソフトで日本語を美しく表示させたいという思いで、長い時間がかかるが仕様策定に関わっている
  • もう10年くらいすれば解決できるようにがんばっている

村田氏:

  • XMLのおかげでUNICODEは日の目を見た。EPUBのおかげでJLREQが広まる?
  • 英語が苦手な人たち同志で英語で議論するためには、事前にドキュメントで共通認識を得た上で差異を確認していく
質疑応答

Q;リフローに関して4051は向いていないのをJLREQではうまくまとめている(例:行頭禁則)と思うが、JIS X4051についてどう思うか?
小林敏氏:

  • 自分は2回目の改定に主に関わっているだけなので、4051は自身の要望を完全に満たしているわけではない。それをJLREQで反映→例:行末約物
  • 4051はわかりづらいので、JLREQでは説明を簡単にして、図版を多めにして見てわかるようにした
  • JLREQでは日本語組版において一般的かを自分の経験に沿って盛り込んだ


Q:半角と全角の扱いをどうするのか
小林敏氏:JLREQでは結果としての要件を述べただけで、半角と全角を使い分けるというわけではない
石井氏:UNICODE上は全角・半角は存在しない。現時点では組版エンジンが対応できないのでフォントを変えているにすぎず、本来は処理系が対応すべき。将来に期待。OpenTypeの機能を利用できるようになればよい
小林龍生氏:書籍版のあとがきを読んで欲しい。全角か半角かはフォントの字形の問題
アンテナハウス小林氏:グリフとコードの問題を区別する。半角全角はグリフの問題。JLREQはコードに関しては述べていない


Q:組版上の問題はフォントの実装で解決すれば楽になるのでは?
石井氏:

  • 既存のフォントの問題をどう解決するか。フォントを作る方々が意外と組版に詳しくない場合もあり、フォントベンダーにすべて押し付けるのがよいのか?
  • 欧文のカーニングペアなどはフォントデザイナーがフォントごとに決めたものだが、日本語の組版仕様とは別のもの

石野氏:欧文でもフォント情報だけではハイフネーションなどは対応できない
小野氏:フォントにどこまで期待するのか
小林龍生氏:既存フォントのシームレスな継承という意味では、フォントだけでの解決は難しい


Q:JLREQはどうやって始まったのか
小林龍生氏:書籍版のあとがきに書いた。2005年のUNICODEカンファレンスで質問に答えられずに、自分が日本語組版をいかに言語化できていないかを思い知った。そこで組版側、実装側のエキスパートが集まって始めた
JLREQはrequirementに徹したのが最大の勝因だと思う


      • -

このブログでも組版系の内容の解説ではしばしば引用しているJLREQですが、まずは作成に関わった関係者の皆さんに感謝と敬意を表したいと思います。私自身も組版に詳しいわけではないですしまだ読みこなしてるわけでもないですが、ここまで詳細かつわかりやすい資料が(Web版なら)無料で読むことができるのはまさに「不滅の業績」だと思います。

その一方でアンテナハウスの小林氏の発言のように、誰もが仕様を読むことができるようになった時点で海外との条件差がなくなりつつあるわけで、それはそれで大変な状況とも言えるのではないかと思います。これを危機ととらえるかチャンスととらえるか(もしくは気にしないか)が後になって大きな差になるのかもしれません。


W3C技術ノート 日本語組版処理の要件

W3C技術ノート 日本語組版処理の要件

CSSで行取りを表現するには

行取りって何?

JLREQこと「日本語組版の要件(http://www.w3.org/TR/2011/WD-jlreq-20111129/ja/)」には下記のように書かれています。

見出しを配置する行送り方向の領域設定で,基本版面で設定した行位置を基準にして設定する方法が行取りである.この場合,見出しの行送り方向に占める領域は,“行の幅×行数+行間×(行数−1)”となる.しかし,見た目には,ページ(又は段)の途中に見出しを配置する場合は,その領域の前及び後ろの行間が加わり,ページ(又は段)の先頭に見出しを配置する場合は,その領域の後ろの行間が加わった大きさとなる.
4.1.6 行取りの処理例

行取りの例


JLREQの該当ページにも図版でいくつかの例が示されていますので、それを見ればどういうものか分かると思います。要するに見出し部分の送り方向のサイズを本文の複数行分に正確に指定することで、各行をきれいにそろえようということです。特にMulti-column Layoutで段組みを表現する場合、その中に見出しがあった場合に行取りを正しく指定しないと、段ごとの行がそろわなくなってしまいます。


ふぞろいな段組みの例(左右の行がそろっていない)

CSSの指定方法

サンプルとして下記のようなhtmlを組んでみます。

<section>
<h1>行送り方向の見出しの占める領域(行取り)</h1>
<p>各ページで行を配置していく場合,基本版面で設定した行位置にそろった方が望ましい.そこで,行送り方向の見出しの占める領域は,基本版面で設定した行位置を基準にして設定する方法が行われている.</p>
</section>

さらにCSSの指定がこちら

section {
	width:20em;
	margin:0;
	padding:0;
}
p {
	font-size:1em;
	line-height:2em;
	margin:0;
	padding:0:
}
h1{
	font-size: 1.5em;
	line-height: 1.333em;
	color: #008800;
	margin:0.333em 0 0.333em 0;
	padding:0.333em 0em 0.333em 0em;
}

これを表示させるとこうなります(グリッドは画像処理で追加しています)

CSS指定のポイント

以前「InDesignとCSSの行組版の違い」でまとめたように、いわゆる行間(line-heightからfont-sizeを引いた値――これをリーディング(leading)と呼ぶ)が文字の後(ヨコ書きなら下、タテ書きなら左)につくのではなく、この半分の値(half-leading)が文字の前後(ヨコ書きなら上下、タテ書きなら左右)に追加されます。

組版で行取りをする場合に、行送り方向のサイズは「本文の基準文字サイズ×行数+行間」で表せますが、CSSの場合はこれに加えてhalf-leading×2が追加されることになります。
上記のCSSではhalf-leadingをmarginで指定し、(本文の基準文字サイズ×行数+行間)をfont-size,line-height,paddingの組み合わせで指定しています。こうすることで背景を指定した場合でも行取り領域にのみ反映させることが可能です。

《h1のline-height》

今回の例では本文と同じ行送りを指定したい(文字サイズが大きくなっているので結果的に行間は狭くなっている)ので、指定する数値は[pのline-height:2em]÷[h1のfont-size:1.5em]=1.333…emとなります。

《h1のmargin》

本文のhalf-leadingと同じサイズにするので、([pのline-height:2em]ー[pのfont-size:1em])÷2=0.5em(本文文字サイズ基準) になります。指定の際には[h1のfont-size:1.5em]で割って0.333…emとなり、それをmargin-top, margin-bottomにそれぞれ指定します。

《h1のpadding》

・見出しが1行に収まる場合=2行取り
この場合のサイズ(本文の基準文字サイズ×行数+行間)は、[pのfont-size:1em]×2+[pのline-height:2em]ー[pのfont-size:1em]=3emとなります。
この中に見出し1行分を収めるので、paddingは(3emー[h1のline-height:2em(本文文字サイズ基準)]÷2)=0.5em(本文文字サイズ基準) になります。指定の際には[h1のfont-size:1.5em]で割って0.333…emとなります。

・見出しが2行になる場合=3行取り
この場合のサイズ(本文の基準文字サイズ×行数+行間)は、[pのfont-size:1em]×3+([pのline-height:2em]ー[pのfont-size:1em])×2=5emとなります。
この中に見出し2行分を収めるので、paddingは(5emー[h1のline-height:2em(本文文字サイズ基準)]×2)=0.5em(本文文字サイズ基準) になります。指定の際には[h1のfont-size:1.5em]で割って0.333…emとなります。


この例では2行取りの場合も3行取りの場合もpaddingの数値が同じになっていますが、font-size, line-heightの組み合わせによってはそれぞれ個別に指定する必要が出てくると思います。


そろった段組みの例(左右の行の高さがそろっている)

rem指定使うとすごく便利!

先日見かけたこちらの記事によると、サイズ指定にremという単位があるそうです。これはルート要素の文字サイズを基準にしたサイズとなります。


これを使用するとかなり指定が楽になります。見出しの文字サイズを本文の文字サイズより大きくした場合、em指定だと、それに合わせてline-height, margin, paddingの数値も計算しなくてはならないのですが、rem指定なら本文の文字サイズを基準にできるので、いちいち計算する必要がありません。

remで指定した場合
p {
	font-size:1rem;
	line-height:2rem;
	margin:0;
	padding:0:
}
h1{
	font-size: 1.5rem;
	line-height: 2rem;
	color: #008800;
	margin:0.5rem 0 0.5rem 0;
	padding:0.5rem 0 0.5rem 0
}

『デザインのひきだし』の押し入れ展

特殊印刷・加工を扱っている雑誌「デザインのひきだし」の展示会やってるってので見に行ってきました。展示会っても本屋の1コーナーですけど。

『デザインのひきだし』の押し入れ展、開催中!

『デザインのひきだし』の押し入れ展
場所:青山ブックセンター本店 デザイン書コーナー近くの壁面
日程:2012年2月28日(火)〜3月16日(金)
   10:00 〜 22:00(最終日は撤収のため、19時頃まで)
   無休(休館日がある場合は青山ブックセンターのホームページ上でお知らせ)
入場料:もちろん無料

活版で作った表紙


それで刷った表紙

ブッシュ抜きの抜き型

トムソン抜きの抜き型。トムソンって名前は聞いたことあるし、抜き型データも作ったことあるけど実物は初めて見た。

レーザーカット。刃を使ったカット機ではさすがにこんな複雑なのは無理。

箔押し用の版

小口印刷(本の側面に印刷する)ための版と転写用パット。こういうのできれば実際の印刷しているところの映像がみてみたかった。

紙+ホロフィルム+4C+白+ニス×2……のUVインクジェット校正

最新号の表紙で使われてるレンチキュラー。けっこうなめらか。実際のサンプルもらえるので、なくなる前にもらいにいくとよいと思います。



特に何も言われなかったけど撮影してよかったのかな…?

このブログでは電子書籍ネタが多いのですが、私自身は仕事的にはこちらよりなので、どれも興味深く見ました。「デザインのひきだし」も創刊以来全号持っていますし。…でももったいなくて袋すら開けてない号も多いのですが*1

こういう特殊印刷・加工は電子書籍では絶対再現できないものなので、そういう意味でも印刷会社が電子化に対抗できるひとつの方向ではあると思います。*2

ついでに言えば本誌を電子書籍化してくれることを熱望しています。資料的に有用な記事が多いのですが、いろんなサンプルがついているためにけっこう読みづらいんですよね。それにサンプルがあるのが最大の特徴なので、内容を電子書籍化してもうまく棲み分けできて売り上げが減ることはないんじゃないかと思うのですが…。

*1:青焼きの表紙なんて放っておくとどんどん褪せてくるのでは?

*2:うちの会社はそういうのとは違いますが

eBookジャーナル

eBookジャーナル Vol.7 (マイナビムック)

eBookジャーナル Vol.7 (マイナビムック)

創刊当時のキャンペーンで、定期購読をするとfujisan.co.jpでの電子版が無料になるというので、Vol.2から定期購読していました(Vol.1は本屋で買った)。もともと隔月発行だったのが途中から季刊になったのでちょっと心配していたらVol.7で休刊だそうです。
(実は定期購読の更新を申し込んだ翌日に休刊の案内が届いた…)

そんなわけで実質1年ちょっとの期間で終わってしまった(電子書籍元年を超えられなかった)eBookジャーナルですが、各号の特集を見てみると、

Vol.1(2010/11/22発売)
  • どうなる!どうする!? 日本の電子出版
  • ついに登場! Adobe Digital Publishing Suite
Vol.2(2011/01/22発売)
  • 電子書籍ストア大研究
  • DRMの真実
  • 電子出版契約において、今考えるべきこと
Vol.3(2011/03/22発売)
  • 2011年 電子書籍リーダー端末の主役はどれだ!
  • いまおさえておきたいiOSアプリ&Androidアプリの作りかた
  • 電子出版ビジネス成功のヒント
Vol.4(2011/5/23発売)
  • 電子出版成功の方程式
  • EPUB3.0早わかり講座
  • InDesign CS5.5+ADPS QuarkXPress+ App Studio アプリ&EPUB制作ガイド
Vol.5(2011/07/22発売)
  • 事例に学ぶ電子出版のビジネスモデル
  • 電子書籍フォーマット総復習!〜フォーマットによるメリット・デメリットと読み方・作り方〜
Vol.6(2011/10/22発売)
Vol.7(2012/01/23発売)

こうしてみると、ストア、端末、フォーマットくらいしかネタがないのかとツッコミたくなりますが、事実そうなのでしょう。「電子出版ビジネスを成功に導く総合誌」というコピーにも現れているように、対象を電子出版、しかも電子書籍や電子雑誌にしぼりすぎていたのかもしれません。

最後になってVol.7ではチラシやカタログ、学習教材などの事例の紹介もされていましたが、今のところは電子出版よりもこちらのほうが成功事例も多いんじゃないかと思います。もう少し対象の幅を広げればいろいろと展開が見えたのかもしれません。

やはり電子出版市場が予想ほど立ち上がらなかったのが敗因なのでしょうかね。個人的にはもうちょっとがんばってほしかったところですが…。


電子書籍業界相関図」としてプラットフォームやストアの相関図が毎号掲載されていたのですが、紹介サイトにVol.2とVol.7の図が掲載されていましたので画像へのリンク貼っておきます。

Vol.2
http://book.mycom.co.jp/user/sample_pc/978-4-8399-3819-2/eBJ0201_800.jpg
Vol.7
http://book.mycom.co.jp/user/sample_pc/978-4-8399-4200-7/eBJ0705_800.jpg

こうしてみると細かく増えてはいるけど全体としてはパッとしないというか、似たようなのばっかり増えてもしょうがないというか…。

ウェブレイアウトの教科書

ウェブレイアウトの教科書 PC・スマートフォン・タブレット時代の標準デザイン

ウェブレイアウトの教科書 PC・スマートフォン・タブレット時代の標準デザイン

著者の境祐司氏は何度かセミナーでお話を聞く機会があり、その内容や公開されるプレゼン資料の情報量に毎回圧倒されます。その境氏による、これからのウェブレイアウトデザインの方向性を解説した本で、具体的なhtmlやcssテクニックはあまり書かれていません。

私自身はウェブデザインには詳しくないのですが、電子書籍ではマルチデバイス環境を考慮しなければならないでしょうし、そういう点でも勉強になりました。

ただ、デザイン思想というかレイアウト方法に関していろんなキーワードが出てきて、なんとなく聞いたことはあってもそれぞれがどう違うのか混乱しそうになります。整理する意味でも、紹介されている用語をリストアップしてみます。これで正解なのかどうかも今ひとつ不安なのですが…。

プリント・レプリカ
雑誌などページレイアウトされたものをそのまま再現したもの。固定レイアウトを拡大・縮小して表示。PDFや画像。
アダプティブ・ウェブデザイン
マルチデバイス、マルチスクリーンに対応させるための設計思想。あらゆる閲覧環境で視認性、可読性を保証するが、同じ見映えになることは考慮しない。
リキッドレイアウト(liquid layout)
リフロー処理の特性を生かしたレイアウト手法。
フルードレイアウト(fluid layout)
リキッドレイアウトと同義。…と言っていいのかな?
フィックスドレイアウト(fixed layout)
ボックス幅のサイズをすべてpxで指定。マルチデバイスには対応できない。
エラスティックレイアウト(elastic layout)
ボックス幅のサイズをすべてemで指定。文字サイズを変更しなければレイアウトは固定される。文字サイズを変更すればレイアウト全体が拡大縮小される。
ハイブリッドレイアウト(hybrid layout)
フィックスドレイアウトもしくはエラスティックレイアウトとリキッドレイアウトを組み合わせたレイアウト。サイドバー幅はemやpxで指定し、コンテンツ領域の幅は%で指定する。そうするとウインドウサイズを変えてもサイドバーの幅は変化しない。
レスポンシブ・ウェブデザイン(responsive web design)
イーサン・マルコッテ氏による造語。広義のアダプティブ・ウェブデザインに含まれる。
One Web Flexible
ひとつのウェブサイトで多種多様な環境に適応させる設計思想。

世の中のウェブデザイナーはこういうのを理解して仕事しているのでしょうか…大変だなぁ。