TidBITS: Apple News for the Rest of Us  TidBITS#1101/31-Oct-2011

今週の私たちは Apple から出たさまざまのアップデートでてんやわんやの状態だった。まずは高速化された MacBook Pro の各機種と、ごく手短な説明のみを付けて出されたいろいろのファームウェアアップデートについて紹介する。それから Michael Cohen が最近の Apple TV ソフトウェアアップデートにまつわる混乱について解説し、Jeff Carlson が Lion で新しく登場したオートセーブ機能が書類の複製を以前より困難にし、トラブルを生む可能性を秘めていると指摘する。最後に Michael の特集記事では、私たちが Take Control 電子ブックを出版する際に Pages を使って EPUB ファイル版を制作しているやり方を詳しく考察する。今週注目すべきソフトウェアリリースは、 iPhoto '11 9.2.1、PDFpen と PDFpenPro 5.6、TextExpander 3.3.4、KeyCue 6.0 だ。

記事:

----------------- 本号の TidBITS のスポンサーは: ------------------

---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----


静かな MacBook Pro アップデートでより高速な CPU へ

  文: Adam C. Engst <ace@tidbits.com>
  訳: 柳下 知昭 <tyagishi@gmail.com>

アップルから言及されるにはあまりにもマイナーなアップデートで、MacBook Pro 製品群全体が少し速くなった CPU と少し大きくなったハードドライブのオプションといくつかのよりがっしりしたグラフィックプロセッサが塔載された。

当然、これらの変更はマイナーな変更であり、公式ベンチマークが出ない間は、これらの新しい CPU やグラフィックプロセッサで毎日のタスクが実際どれくらい速くなるのかを知る方法はない。新しく MacBook Pro の購入を予定しているならば、これら新規モデルであることを確認して購入する価値がある。価格とその他オプションは、変更されていない。

コメントリンク12596 この記事について | Tweet リンク12596


Apple、幾つかのハードウェア関連のアップデートをリリース

  文: Adam C. Engst <ace@tidbits.com>
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

我々はいつもなら Apple のハードウェア関連のアップデートは個別に扱うのだが、今回は数も多くそして明らかにされた詳細も極めて少ないので、全部一緒に纏めることとした。ファームウェアのアップデートについては、一旦アップデートを始めたらそれを中断しないように注意されたい、何故ならばそうすることで自分の Mac を石にしてしまう可能性があるからである。一般論として、我々はファームウェアや他のハードウェア関連のアップデートはやった方が良いとお勧めしている;Software Update が正しいものをインストールする一番良い方法である、何故ならばあなたの持っている Mac のモデル名を正確に知るのはたやすいことではないからである。

コメントリンク12591 この記事について | Tweet リンク12591


Apple TV 4.4.2 アップデートでリセットのイライラ?

  文: Michael E. Cohen <lymond@mac.com>
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

比較的順調な iCloud の導入とは違って (ここで順調と言っているのは MobileMe 投入時の混乱に比べてという意味である - "MobileMe、よろめきながらも、ついに立ち上がる" 12 July 2008 参照)、第二世代 Apple TV 用ソフトウェアに対する Apple のバージョン 4.4 は、他の機能に加えて iCloud コンパチ性を提供するべく意図されたものであるが、Apple の最近提供されたソフトウェアの中ではより星回りの悪いものの一つとなった。念のため言っておくと、これは Apple TV (第二世代) だけに関係するもので、初代のそして今やもうサポートされない Apple TV ではない。

要約すると:12 October 2011 に Apple はアップデート 4.4 を Apple TV ソフトウェアに対して出した。このアップデートでは、通常のセキュリティ対応に加えて、加入者に対する National Hockey League ストリーミングのサポート、Wall Street Journal ニュースと解説、幾つかのスライドショーテーマ、Netflix 字幕表示のサポート、iOS 5 の AirPlay Streaming 機能のサポート、そして iCloud Photo Streams へのアクセスが提供された。

一週間後の 18 October に Apple はアップデート 4.4.1 をリリースし、アップデート 4.4 を完了するために Apple TV ユニットを iTunes に接続しなければならなかった一部のユーザーの問題に対応しようとした。しかしながら、ユーザーの中にはこの 4.4.1 アップデートで Apple TV が機能しなくなった人も出た。Apple はこのアップデートをすぐに取り下げそして翌日に再リリースした。

それから 24 October に Apple はアップデート 4.4.2 をリリースした。そのリリースノートには次の様に記述している、"Apple TV 機器でソフトウェアバージョン 4.4 及び 4.4.1 がのっているものはそれより後のバージョンへのアップデートに問題がある。"

これで一件落着? 答えは、はいでもありいいえでもある。4.4 や 4.4.1 をインストールしようとしなかった人達には、アップデート 4.4.2 をインストールするのは簡単で Apple TV 上で Settings > General > Update Software と辿り、後はそのアップデートを適用するだけでよい。

しかしながら、もうすでに 4.4 アップデートをインストールしてしまっている早期導入者には、更にもう少しの手順が必要となる:アップデートする前に Settings > General > Reset > Reset All Settings と辿り、そしてその後に 4.4.2 アップデートをインストールする。この Apple TV の設定を手動でリセットしなかった場合は、4.4.2 アップデーターがそれをしてくれるので、その後で再度インストールを試みなければならない。

これは世界最悪の事態とまではいかないが、Apple TV ユニットが Wi-Fi 経由でインターネットにつながっているのであれば、この強制リセットをすることは Apple TV の所有者はリセットが済んだらアップデートを試みる前に自分の Wi-Fi 情報を入力してやらなければならないことを意味する。更に、このリセットで Apple TV 上に保存された Home Sharing 情報も全て消されてしまうので、iOS 機器上の Remote アプリによって提供されるより簡便なキーボードを使う代わりにスクリーン上のキーボードでこれらの情報を入力しなければならない。

このリセットはその他の沢山の情報も再入力されなければならないことを意味する、例を挙げれば Apple TV に付けた名前、時間帯設定、Netflix の様な娯楽サービス、Major League Baseball の様なスポーツサービス、Home Sharing, そして iCloud といったものに対する全ての ID とパスワード等である。

多くの Apple アップデートについては、"自分でやってくれる" というのがユーザー経験をまあまあ表していると思う。しかし Apple TV アップデート 4.4.2 に関しては "あなたがやらねば" の方がより実態に近いであろう。

コメントリンク12600 この記事について | Tweet リンク12600


Lion の“複製”コマンドの問題点

  文: Jeff Carlson <jeffc@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Mac OS X Lion で新たに登場したオートセーブ機能は、特に経験の少ないユーザーたちにとっては、このオペレーティングシステム改訂における目玉機能の一つと言える。この機能に対応したアプリケーションでは、Command-S を押す(あるいはマウスを使って File > Save (保存) を選ぶ)ことを覚えている必要がなくなるからだ。Lion が、自動的かつ継続的に、すべての変更をディスクに保存してくれる。オートセーブ機能は、バージョン機能と対になって働く。バージョン機能は書類の過去の草稿の一部または全部を復元できる手段を提供する。

しかしながら、この機能によって犠牲となってしまったのが、長年来の“Save As (別名で保存)”コマンドだ。従来、このコマンドを使えば元の書類と同じ内容を持つ新たなファイルを作成してそのファイルで作業を続けることができた。ところがこれからは、“別名で保存”の代わりに、複製してから保存する、という面倒な手順を踏まなければならないことになった。私は憤慨のあまり Twitter にこんなメッセージを書き込んだ:「Apple よ、まったくもう、“別名で保存”は今まで完璧に動作していたんだ。なのにこの、Lion の“複製を作ってからその後で保存する”というやり方にはもううんざりだよ。」

これに対して、賛成する声が多くの人たちから届いた。(まだ Lion にアップグレードしていない理由の一つがこれだと言っていた人たちもいた。)また何人かの人たちは、私が「パワーユーザー」であって“保存”と“別名で保存”の違いが分からない普通の Mac ユーザーを知らないからそんなことが言えるのだ、と私を非難した。Lion のオートセーブは、全体的に言えば素晴らしい機能であって、定期的に保存するのを忘れたために人々が作業の成果を失ってしまうのを防止してくれるであろう。けれども、以下で説明するように、この新しい挙動は同時に、あなたが達成しようとしているその結果を、長年実証済みの信頼ある“別名で保存”コマンドと同程度に混乱を呼ぶものへ、そして場合によっては“別名で保存”コマンドよりももっと大きな混乱を呼ぶものへと、転化させてしまうのだ。

“別名で保存”の代わりにオートセーブを Lion が提供できるためには、個々のプログラムがそれに対応する改訂を受けなければならない。だから、あなたが従来から使ってきたソフトウェアにはオートセーブが出てこない。Apple 製のソフトウェアで書類の管理を行なうものであり、Lion 用にアップデート済みのものにおいては、オートセーブが機能する。

オートセーブの動作の仕組み -- オートセーブの背後にあるアイデアは、ユーザーたちには書類を保存することについて一切心配する必要があるべきでない、ということだ。iOS においては、あなたが何かのアプリでした作業はすべて、あなたが別のプログラムに切り替えようともそのデバイスをスリープさせようとも、どんな場合にも保たれていることが期待される。戻った時には、書類がその前の状態と正確に同じ状態になっていることをあなたは当てにしている。それこそが、オートセーブ機能の提供するものだ。プログラムがクラッシュしても、あなたがプログラムを終了させても、あるいはあなたがコンピュータをシステム終了させても、その後あなたがそのアプリケーションに戻った際には、書類が正確に元通りの状態になっている。

この機能に対応しているアプリケーションで書類が開かれた際には、新しいバージョンが保存される。また、一時間に一回ずつ新しいバージョンが作られ、変更を含んだ書類が開いている状態でプログラムを終了させた際にもその書類の新しいバージョンが作られる。(あなたに保存をさせる代わりにバージョンの保存が行なわれるのだが、実際の保存作業ははるかにもっと頻繁に起こる。)また、あなたが File > Save a Version (バージョンを保存) メニューを選べば手動で新しいバージョンを保存させることもできる。この点については次のセクションで述べる。このことが、複製を作成することに関係しているからだ。

以前に削除してしまった段落を使いたい、あるいはさっき施した変更を取り消したいと思った場合には、バージョン機能を使って以前の状態の草稿を取り出すことができる。

File > Revert Document (書類を復帰) メニューを選んでから Browse All Versions (すべてのバージョンをブラウズ) ボタンをクリックしよう。あるいは、タイトルバーの書類の名前の上にポインタをかざすと小さな下向きの三角形が出るので、それをクリックして出るドロップダウンメニューから Browse All Versions (すべてのバージョンをブラウズ) を選んでもよい。すると、バージョン機能を用いて以前のすべての草稿を見ることができ、好きなものをコピーしてペーストすることも、あるいは書類全体を以前のバージョンに丸ごと復帰させることもできる。

Image

Mac OS X 10.6 Snow Leopard やそれ以前では、そして、まだ Lion のオートセーブ機能に対応していない大多数のアプリケーションでは、これと同様のバージョン管理をするためによく用いられている方法がある。File > Save As (別名で保存) を選ぶと“保存”ダイアログが出るので、そこで新たなファイル名を選ぶ。多くの場合においてはその際にファイルのフォーマットを変更することもできる。いったん保存をすれば、あなたは作成したばかりの新しい書類で作業をしていることになるので、そのファイルの前回のバージョンはそのまま、それが最後に保存された時点の状態で触られずに保存されていることになる。

この“別名で保存”のやり方の利点は、改訂履歴を名前によって簡単に管理できることだ。さらに、たとえ現在作業中の書類が壊れてしまっても、ちゃんと戻れるところが一つ、五つ、あるいは十個、残されている。このやり方の欠点は、ファイルの改訂履歴がたくさんになると、すぐにフォルダが多数のファイルで混雑してしまうことだ。

(私は長年 Dropbox も依存して使ってきた。Dropbox は私が手で保存をする度に私が何もせずともファイルへの変更を自動的に保存して、古いバージョンはウェブのインターフェイス経由でダウンロードできるようにしている。)

Lion のバージョン機能は、すべてのものを一つのきちんとした集合体の中へ押し込めている。あなたはたった一つの書類だけで作業をし、Time Machine 風のインターフェイスを使って過去に保存されたすべてのバージョンにアクセスできる。けれども、まさにそのきちんとしたところが、あなたが書類の別バージョンを保存してそれを作業の新たな出発点としたいと思った瞬間、もろくも崩れ落ちてしまう。

“複製”にまつわる混乱 -- オートセーブ機能とバージョン機能のやり方は、一つのマスター書類を保持したい場合にはうまく働く。けれども、バラバラの複数の書類を必要とするような状況もある。例えばあなたが就職活動中で、いくつかのバージョンの履歴書を必要としたとしよう。個々のバージョンには、それぞれ特定のスキルや過去の就職歴が強調されている。そのような場合、バージョン機能を使っていろいろな改訂版の間を行き来するのは実用的でないので、既存の書類をもとに新規の書類を作りたいと考えるのは自然だろう。

Lion における新しい挙動を利用しているアプリケーション、例えば Pages や TextEdit で作業しているならば、File > Duplicate (複製) を選ぶことになる。そうすると、新たなウィンドウが開いて、あなたの書類と同じ内容を含み、元のファイルと同じ名前になっている。

もしもあなたがしばらく以前からコンピュータを使っていて、手で保存するのに慣れていたなら、あなたは Command-S を押すか File > Save (保存) を選ぶかしてファイルを保存しようとするかもしれない。すると、そのプログラムは“保存”ダイアログを表示して、そこでファイルに新たな名前を付けられるようにする。あるいは、あなたが既存の名前のままにすれば、そのファイル名の末尾に "copy" という単語が添付される。

この一連の流れで私が最初に直面した問題は、複製してからその後に保存するという、二段階のステップになってしまったということだ。以前の別名で保存のやり方は一段階で済んだ。別名で保存する従来のやり方に慣れた人にとっては、煩わしい余分の作業が増えたことになる。それに、いったん書類を複製した後は、それを保存する必要があるのかないのか見ただけでは分からない。

けれどももっと大きな問題点がある。それは、オートセーブの世界で、いったい保存なんかする必要があるのか、という問題だ。実は、保存する必要はない。その新規の書類で、そのまま編集作業を続けてもよい。しかしながら、ここで物事はますます混乱してくる。特に、経験の少ないユーザーほどそれは深刻だ。

Pages の中で、私はテスト用の書類を作り、その複製を作って、File > Save を選ばずにそのまま編集作業を続けた。Apple の言うところによれば、Lion は「作業の手が止まったときにデータを保存し、作業をずっと続けている場合は、5 分ごとに保存をする」のだという。私はテキストを追加したり編集したり、写真を挿入したりして、いつもと同じように時々は作業の手を止めて、他のアプリケーション (Safari、Twitterrific、Mail) に切り替えたりした。

この間、私は一度も保存をしたり書類を改名したりするように促されなかったし、書類のタイトルバーにあるオートセーブ/バージョンのインジケータが書類の状態を "Edited (編集済み)" と表示することもなかった。私の知る限り、この書類が保存された兆候は一切無かった。

次に、私はもっと劇的なテストを試みた。そのまま、そのアプリケーションを終了したのだ。もしも Lion がこの書類をオートセーブしていなかったならば、私は即座にすべての作業の成果を失ってしまうだろう。思い出して頂きたいが、Apple はユーザーが保存については何も心配せずに済むようにしたいのであって、そのためにオペレーティングシステムやアプリケーションが必要となる作業をすべてこなしてくれるはずなのだ。

そこで Pages をもう一度開くと、あの複製が再び現われた。これは、Lion の再開機能のお陰だ。なぜなら、私はアプリケーションを終了する前にあらかじめこの書類を閉じず、私が編集したものをそのままにしていたからだ。ああ、よかった! それでもやはり、Lion はいくつか妙なところを示していた。

まず、私は複製を作成した時点よりも以前の段階の編集状態へ復帰することができなかった。Undo (取り消し) の履歴は失われていたし、ファイルが保存されなかったのでバージョンも一切作成されていなかった。これは理解できないでもない。なぜなら、これのような量子力学的な不確定性の下にはない普通の書類であっても、書類を開いたままアプリケーションを終了すれば Undo 履歴は失われるからだ。

けれども極めつけの状況はこうだ: もしも、私がそのファイルを誰かに送ろうとしたら、あるいはそのファイルを iCloud にアップロードして私の iPad でも作業できるようにしようと思ったら、どうなるだろうか? Finder の中にはそのファイルは _存在していない_。まだこれは正式に保存をされていないので、この複製は見たところ、大多数のユーザーにはアクセスできないどこかの場所に、一時的なコピーとして置かれているだけのようだ。

ではどうすれば解決できるのか? そのためには、ファイルを閉じるか、あるいは File > Save (保存) を選んで“保存”ダイアログを出し、新しい名前をそのファイルに付けてそれを置くべきフォルダを指定するのだ。ということは、これはそもそも初めから Save As (別名で保存) を選ぶことができた場合と全く同じ手順ではないか。

もちろん、複製をする別の方法や、テンプレート (ひな形) のようなファイルを使って処理する方法も引き続き使える。ファイルを Finder の中で選択してから File > Duplicate (複製、Command-D) でファイルの複製を作り、その複製を改名してからそれを開けばよい。あるいは、日常的に複製したいファイルについては、そのファイルを Finder で選択してから File > Get Info (情報を見る、Command-I) を選び、Stationery Pad (ひな形) チェックボックスをチェックしておけば、その後 Finder でそのファイルをダブルクリックすれば自動的に(ファイル名の末尾に "copy" という単語が添付された)複製が元のファイルと同じフォルダの中に作られ、その複製が開かれて編集できるようになる。

確かに、一つの書類で作業をしている最中に、まずそれを複製してからあとでそれを保存するということが概念的に意味を成すのは認めよう。しかし、その複製の作成と、そのディスクへの保存との間に、いったいなぜ時間的な遅延を作らなければならないのか? いったいなぜ、Duplicate (複製) コマンドが新しいウィンドウを開くとともに、自動的に、素早く、その書類をどのように保存するかユーザーに選ばせることをしないのか?

いや実は、私は答を知っている: その理由は、iOS がそういう風にはなっていないからだ。iOS では、ファイル名は後付けだ。それにおそらく、将来のバージョンの Mac OS X は単一アプリケーションのモードで動作し、Finder などなくなるのではなかろうか。そこでは、私たちはファイルなどというものを扱う必要がなくなるのかもしれない。まだ、私たちはその段階にまで到達していない。Mac OS X は、まだまだファイルシステムという構造にあまりにも頼り切っている。けれども Lion は、オートセーブによって、その方向へと大きく一歩を踏み出そうとしているのだ。

コメントリンク12593 この記事について | Tweet リンク12593


Take Control は EPUB を Pages で作成

  文: Michael E. Cohen <lymond@mac.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

遠い、遠い昔に(正確に言えば、2003 年に)Adam Engst と Tonya Engst の二人が、Take Control シリーズというアイデアを思い付いた。「電子ブックがメイン」のシリーズにするという考え方が中心にあったので、原稿の執筆やフォーマットの際には最初から電子ブックとして読まれることを念頭に置いて作業が組み立てられた。もちろん、出来上がったものを印刷することも可能であったが、本自体はあくまでもスクリーン上で読まれるためにデザインされた。初期の時代、Take Control ブックの著者たちは Mac で Microsoft Word X を使って原稿を書いていた。

Word を選択する理由は明らかであった、最初のテンプレートを作成したのは Tonya で、彼女は Word の高度な機能を使いこなすことのできる有能なユーザーであるとともに、Windows 2003 用の Word で Adobe Acrobat Pro プラグインを使えばクリック可能なウェブ URL や、内部相互参照リンク、ブックマークなどをすべて含んだ PDF ファイルが書き出せることを知っていた。ただしそれは、仕様に合致した原稿を著者たちが書くことができればの話ではあったが。当時は、PDF のみが唯一、電子ブックの標準として広く使われていた。そして「電子ブックがメイン」のシリーズであれば、ホットリンクやブックマークなどが必須の機能であった。(そのことは今も変わらない。)

(残念なことに、Mac 版の Word は、今日に至ってもまだ、リンクやブックマークを含んだ PDF を生成することができない。そう、確かに、Mac に焦点を置いた Take Control シリーズが Windows ソフトウェアを使って PDF に書き出されていた点には少なからず皮肉を感じざるを得ない。私たちが Word での制作作業を完全に止めたのは今年に入ってからであった。そのことはさておき、Tonya は実際 Mac 版の Word を使って PDF を書き出していた。彼女はそれを使って、Windows 生成の PDF のちょっと不細工な見栄えの可視レイヤーを置き換えていた。つまり、リンクやブックマークは Windows 版からのものを利用し、それを Mac 版で作ったより見栄えの良い PDF と合わせていたのだ。)

また、Word は長年、書籍出版業界では事実上の標準として使われてきた。つまり、Take Control の筆者たちは全員 Word を持っていて、Word の使い方を知っていた。Word は多過ぎると思えるよりさらに輪をかけたほど多くのフォーマット機能を提供していて、著者たちも、少し手引きを受けさえすれば、配布されるべき最終版の PDF ファイルに非常に近い状態の原稿を作成することができた。言い替えれば、彼らは自分たちのレイアウトの中に直接文章を書き込むことができたので、普通ならば彼らの原稿を最終的なレイアウトの中に流し込んで成形仕上げをするために必要な余分の制作作業を省くことができた。特に役に立ったのが Word の高度な作表フォーマット機能で、いろいろな図表やヒントの強調表示など、読者の目を引くビジュアルな要素のためのグリッドを作表機能によって作っていた。

当時の状況 -- シリーズ発足当時の時代、PDF が(今日と同様)出版される Take Control ブックの主要なフォーマットであった。けれどもそれから数年も経たないうちに、オンデマンドの印刷本も私たちは提供し始めた。(印刷本は PDF から生成されたが、その際 Apago の PDF Enhancer を使って物理的な本のサイズに合うように縮小されている。)そして 2009 年後半に至り、私たちは他に二種類の電子ブックフォーマットでの出版さえも開始した。EPUB 版と、Mobipocket 版だ。ただし、圧倒的多数の読者については、今も変わらず PDF が第一のフォーマットだ。

これは決して驚くべきことではなかった。オンデマンドの印刷本は PDF 版に比べて大幅に価格が高く、顧客の手に届くのも PDF 版をダウンロードするよりずっと時間がかかる。私たちが提供する PDF 以外の二つの電子ブックフォーマットについては、それらの市場が非常に小さかった。なぜなら、電子ブックリーダーを所有していた、あるいは使ったことのあった、人々の数が少なかったからだ。

結果として、私たちは PDF を制作することにエネルギーの大部分を注ぎ込み、電子ブックの他のバージョンの制作は私たちの再販パートナーである O'Reilly Media に委託することにした。それらのバージョンへの需要が低かったので、電子ブックの PDF 版が出版されてから他のフォーマットが入手可能になるまでに若干の遅延があるように見えてもそれほど苦情は多くなかった。

けれどもその後、Kindle が Mobipocket フォーマットとともに登場し、沈滞していた電子ブック市場に活気を吹き込んだ。そして、Kindle の後に、iPad が続いた。iPad が登場すると、即座に Take Control 電子ブックの読者の多くにそれは重要な意味を持った。もちろん iPad 上で PDF を読むための良い選択肢はたくさんあったけれども、EPUB フォーマットの電子ブックが、例えば Apple の iBookstore で販売されるものをはじめとして、iPad 使用体験の根本的な構成要素となりつつあった。

けれども私たちは依然として Microsoft Word を使って原稿を準備していたし、私たちと Word との関係は当時非常に微妙なものであった。Word は私たちにとって根本的に重要な機能、つまりリンクやブックマークを長い原稿に追加できる能力を持っていたし、その他にも都合の良い機能を多数備えていた。と同時に、何と言うか、壊れやすくもあった。それに、たいていの場合私たちは出版前には非常に時間に追われていて、出来る限り素早く電子ブックを仕上げる必要に迫られていたので、何か問題に出くわす度に一つ一つ Microsoft と協力しながらゆっくり問題の原因を追求したりするような余裕は全く無かった。不愉快なごたごたをすっかり省いて言えば、例えば 100 ページ以上の Word 書類に、膨大な数の変更追跡やコメントが付いていれば、必ずしもその書類はいつも行儀良く振る舞うとは限らない。それに加えて、私たちの電子ブックに必須の内部相互参照リンクは壊れやすく、作成したり修正したりするのに非常な忍耐を必要とした。リンクをチェックしたり修正したりするためだけに膨大な労力が費やされていた。

その一方で、iPad や、モバイルな電子ブック読書に対する興味が世の中に盛り上がるにつれて、私たちは EPUB 版の制作を外部委託してその結果タイムラグが生じるのは多くの読者にとって不都合になりつつあると考えるようになった。さらに、外部委託をするということは、私たちの本の EPUB 版の最終的な見栄えや手触りの仕上げを他者の手に渡してしまうことを意味していた。けれども、長い長い期間にわたって、私たちは Word に代わることのできるまともな代替手段を見つけられずにいた。PDF を生成することができ、執筆と編集のために十分豊かな機能を備えた環境であって、文章を書きつつ私たちが欲するフォーマットでそれを表示させることができ、かつ EPUB を生成することもできる、そういうものを私たちは探していた。

Pages が登場 -- iPad のリリースから数ヵ月経って、Apple は同社のプロダクティビティ・ソフトウェアの Mac 用スイート iWork にマイナーなアップデートをリリースしたが、その中にはワードプロセッサ Pages のアップデートも含まれていた。そして、_この_ アップデートに含まれていたのが、Pages 書類を EPUB フォーマットで書き出せる機能であった。(2010 年 8 月 27 日の記事“iWork 9.0.4 にて Pages が EPUB をサポート”参照。)この改訂された Pages をじっくりと使って試してみた結果、Adam はこの Pages が Take Control ブックのための Word 原稿を読み込み、きちんとした PDF と、信頼性ある EPUB 版の両方ともを、そこから書き出せることを確認した。私たちの心の中には鐘の音が鳴り響き、脳裏には輝かしい電球が明るく灯った。

Tonya は副プロジェクトとして、これまで Take Control 原稿の中で用いられてきた Word の段落スタイルや文字スタイルの複雑な寄せ集めを、Pages における同等なものへと変換する作業を始めた。この大変な作業の目的は二つあった。Pages 原稿から PDF 形式の Take Control ブックを作成した場合に望ましい見栄えと感触が得られるかどうかの確認と、満足できる EPUB 版を同じ原稿から作成するのが最小限の努力でできるかどうかを見ることだ。ここで「満足できる」というのは、見栄えの面でも、ナビゲーションのし易さについても、既に顧客の手に渡っているものと少なくとも同程度に良いもの、という意味だ。

大多数の Take Control ブックにはおよそ 12 種類のカスタム文字スタイルと、60 近くのカスタム段落スタイルとが含まれているので、考慮すべきスタイルは非常にたくさんあった。その上、作表に関係するレイアウトはすべて捨てざるを得なかった。なぜなら Page の作表機能は Word に多数ある細かな工夫に比べればずっと単純なものであり、また EPUB フォーマットにおいては表自体があまり意味を持たないからだ。(この点についてはすぐ後で触れる。)そればかりでなく、Pages と Word には多数の共通点がある一方で、それぞれのコンテンツモデルにはいくつか微妙な(いくつかは非常にはっきりした)違いがあった。さらに状況の複雑さに輪をかけたのが EPUB のコンテンツモデルそのものに内在する限界で、PDF で可能なものに比べれば制限が多かった。

EPUB のコンテンツモデルにおける制限事項を処理するのは、決して楽な仕事ではない。これに比較すれば PDF のコンテンツモデルはパワフルで複雑なものであり、他にもいろいろ配慮がなされているが、特に印刷された状態に出来る限り近い状態でその書類がスクリーン上に表示できるようにデザインされている。ある意味では、PDF というものは印刷とピクセルの交差点に立っているとも言える。スクリーン上の PDF (例えば一冊の Take Control ブック) は、同じ書類の印刷版と全く同じに見えるべきものだ。同じフォント、カラー、レイアウトの特性を持ち、ページ区切りも同じになっている。

他方、EPUB フォーマットは、各種のポータブルなデジタル機器の上で読み易い形で書類を呈示できるようにデザインされているので、EPUB を読むためのソフトウェアがその時それを読んでいるデバイスの特性に従うようにスクリーン上の書類のレイアウトや見栄えを調節するようになっている。EPUB を一つのデバイスで読む際のフォント、レイアウト、ページ区切りなどを、他のデバイスで読んだ場合と同一にするようにこのフォーマットは作られていない。そのデバイスと、そのデバイスを使っているユーザーとが、EPUB 本の見栄えの多くの部分をコントロールする。本のデザインに十分な注意と労力さえ注ぎ込めば、EPUB 本を印刷版の本とよく似た見栄えに近づけることは可能だけれど、完璧に両者が同じになるということはあり得ないし、二つのリーダーで同じ本を読んだ場合にその両者が読者の目に全く同じに見えるという保証もない。ここが、PDF との大きな違いだ。

EPUB フォーマットに制限事項があることを反映して、Pages から書き出した EPUB 書類には Pages 自体が備えているフォーマッティング機能のうち一部しか反映させることができない。EPUB に書き出す際、Pages は、例えば縁取りのあるテキストボックス、テキストやグラフィックスのフローティング要素、その他さまざまのものを無視してしまう。

そこで、Tonya は Take Control 用のスタイルを Word から Pages へ変換しなければならなかったのみならず、PDF としても、また(例えば iPad 上の iBooks アプリのような)EPUB リーダーが再現できるビジュアル特性のみに限定しても、いずれの場合にも魅力的な見栄えとなるようなものに、それらのスタイルを改良したものを作らねばならなかった。さまざまの試行錯誤の実験を重ね、個々のスタイルの目的を考え直すことによって、最終的に Tonya は同じ Pages ファイルをもととして PDF の電子ブックと EPUB の電子ブックを作るために必要な一連のスタイルを工夫することができた。このプロジェクトは何週間にもわたり、作業時間は述べ 40 時間にもなったという。(ただしここで言い添えておきたいが、Tonya が作り上げたこの当初のスタイルはその後も進化を続けている。Pages がどのように EPUB を作成するかについて私たちの理解が深まるにつれ、Tonya のスタイルも改良されつつあるのだ。)

電子ブックのビジュアルな見栄えについて考え直すだけでなく、Tonya と Adam は自分たちが電子ブックの最重要機能と見なしているものについてもどのようにするかを決めなければならなかった。つまり、内部相互参照のためのホットリンクや、ウェブへのホットリンク、そしてブックマークリストだ。Word の中で内部相互参照のホットリンクを作成するのは、少々信頼性に欠けている上に、Hyperlink ダイアログを介した面倒な作業が必要であった。Microsoft は、数々のバージョンの Word を通じて一度も Hyperlink ダイアログに大きなアップデートを施してくれなかったからだ。著者によっては、その種のリンクを入れるために自前の自動化ツールを開発した人さえいたし、Tonya は結局多くの電子ブックで内部リンクを手で入れる羽目になった。その際彼女は力仕事のいくつかに Keyboard Maestro のマクロを利用していた。少なくとも、Windows 用の Word で Adobe Acrobat PDF プラグインは信頼性あるブックマーク作成をしてくれた。

幸いにも、Pages には内部相互参照リンクやウェブ URL を作成できる機能が内蔵されていて、使ってみるとこれが非常に信頼性が高いことが分かった。ところが、Take Control の誰も、その機能を自動化する良い方法を思い付けなかった。その結果、Link Inspector を使う作業は思った以上に手仕事の多いものになってしまった。それでも、少なくとも、いったんリンクを設定すれば、その後もそれがずっとそのまま使えるという点は信頼できた。

Pages から書き出した PDF に関して私たちは二つの問題点に遭遇した。第一に、リンクとなるテキストの一つごとに、Pages は二つずつの PDF リンクを作成し、その二つを重ねて配置する。読者にとってこの二つの機能的な意味は同じだ。どちらをクリックしても、リンクとして働く。けれども問題は、クリックした際に読者の目に何が _見える_ かだ。PDF 中のリンクは、クリックした際にそのリンクのまわりにボックスを表示するか、またはリンクのまわりのスクリーンの色を反転するか、どちらかだ。いずれの場合も、クリックしたリンクがリンクのテキスト全体を覆わないことが多いのが気に障る。幸いなことに、Acrobat Pro ですべてのリンクを選択してそれらの強調時スタイルを "none" に設定することが簡単にできる。そうすると、リンクがクリックされてもビジュアルにそのことを示すものは何も現われない。どちらかといえばこの方がマシだが、Apple にはこの残念なバグをぜひとも次の Pages 改訂版で修正してくれるよう願いたい。

第二に、Pages から書き出した PDF には、書類の章節の見出しに付随したブックマークがなくなっている。このことは私たちもひどく困った。出版の最後の段階になってすべての章とすべての節の表題にいちいち手仕事でブックマークを付けなければならないなんて、想像しただけでも大変な作業だったからだ。Adam が最初に思い付いた対策は Smile の PDFpen Pro を使う方法だった。PDFpen Pro には選択されたテキストから素早くブックマークを作成できるツールがある。でも、これでもまだまだ手間がかかり過ぎるということで、結局私たちはその後もっと良い方法に落ち着いた。Debenu 製の Acrobat プラグイン、 Aerialist X Pro を使う方法だ。これは高度な PDF 操作機能をいくつか提供していて、その中の一つの機能が、テキストをスキャンして特定のフォントとフォントサイズを持つものを探し出し、その結果から自動的にブックマークの階層的セットを作成する、というものであった。(同じ作業に使える別のツール PDFOutlinerも、あなたの予算さえ許せば一見の価値があるだろう。)

切り替えを果たす -- EPUB を作成するために使うスタイルのセットを揃えただけではワークフローが出来たとは言えない。まず第一に、私たちはスタイルについて説明したガイドラインと説明書とを著者たちのために作る必要があった。また、必要なスタイルをすべて含んだテンプレート書類も作って、著者たちがそれをもとに Pages での作業を開始できるようにしておかなければならなかった。

もちろん、そういう説明書とテンプレートを用意することは、必要となる作業のほんの一部でしかない。それ以外にも、Take Control 著者たちが、これまで使ってきた作業用ツールである Word、ほとんどの人たちが長年かけて使い慣れ、生産的に仕事ができるようになったソフトウェアから全く異なるツールへと切り替えられるように手助けをしなければならなかった。けれども何人かの著者たちは、もう何年も前から Word 以外のツールへ切り替えようと事あるごとに私たちに言い続けてきていた。ぴったりした代替手段は彼らも思い付けなかったのだけれども。ことに Joe Kissell は、Word を離れることを強く主張した。彼が書いてきた本の数々を考えればそれも当然のことかもしれない。(現在は Nisus Writer Pro も EPUB 書き出しができるようになり、これはその他にも多数の歓迎すべき機能を備えているので、Joe は Nisus Writer Pro を Pages の代わりに使えないかどうか、調べているところだ。)

それよりもっと大きな課題は、既存の原稿のコレクションをどうやって Word から Pages へ変換するのかという問題だった。結局のところ、Take Control ブックの多くは既存の Take Control ブックのアップデートや改訂版なのだから。これらの Word 原稿を単純に Pages へ読み込んでも役に立たない。元々の Word におけるスタイルは Word から PDF 出力を制作するように作られているので、EPUB と PDF の双方に使えるように作られた Pages のスタイルへ何らかの方法で置き換えなければならない。

それに加えて、Pages への移行に際し、Tonya はこの機会を利用して Word スタイルのセットを合理化することにした。長年の間に膨大な集合体と化していたスタイルの集まりを、Pages の Styles ドロワの中で一貫した名前を持ちきちんと整理された一連のスタイルへと変えたのだった。その結果として、Word 版の Take Control 原稿の中で使われているスタイルの大多数を、Pages の中で同等の働きをするけれども違った名前の付いた新しいスタイルへと手作業で置き換えなければならなくなった。

このスタイル変換の工程には、あらゆる種類の落とし穴が待ち受けていた。例えば、項目が番号あるいは黒点で始まる箇条書きスタイルを Word 原稿で使っていたが、その際私たちは Word の自動番号付け機能や自動黒点付け機能を使っていなかった。なぜなら、私たちはその機能が気に入らなかったからだ。この機能は必要以上に役に立とうとし過ぎて、私たちがどの書体を適用したいかについてあまりにも頻繁に誤った推測をした。けれども、それに相当する Pages のスタイルの方は、うまく働いて私たちの制作作業のスピードアップに貢献し、正確な番号を付ける助けになった。ところが、自動生成の黒点や番号を用いるということは、Word 原稿を Pages へと変換する作業の中にたくさんの検索・置換の工程が入り込み、私たちが Word 原稿の中に手作業で書き込んだ多数の番号や黒点を全部削除してから、Pages における同等の機能が自動生成する番号や黒点を設定したりチェックしたりといった処理が必要となった。

その他にも、Word のスタイルと Pages のスタイルとの間には細心の注意が必要な相違点がたくさんあって、それぞれ作業を施す必要があった。Tonya には、この変換を実行するための手順を書き留めた一覧表を開発する必要があることが分かった。すべてを書き留めておけば、あらゆる手順を暗記している必要もなくなり、たった一人の人だけがやり方を知っているという事態に陥るおそれもなくなるからだ。

この手順書は、現在のところ 30 個の大きなステップから成っている。それに加えて、多数のサブステップや注意書きも含まれる。当初この書類にはさらにもっと多数のステップがあって、Word 書類をいったん HTML フォーマットにする工程や、内部相互参照リンクを十分にクリーンアップして Pages で動作できるようにするための極めて複雑な BBEdit text factory も含まれていた。けれどもその後時間の経過とともに、Tonya は Word でのリンク(ここにはいくつか奇妙な点があって、Pages で働くようにする作業を困難にしていた)をすべて捨て去り、リンクを Pages の中で作り直すようにしようと決断した。つまり、リンクに関しては、書類を一から作り直そうと決めた訳だ。リンクの自動再設定の作業をせずに済むようになったことで、標準的な原稿を Word から Pages へ変換する作業は、あらゆるステップを経てから結果の再確認をする段階まで含め、一つの原稿あたりおよそ 2 時間で済むようになった。ごく短時間とは言えないが、膨大な長時間という訳でもない。なにしろ、本を著述して編集するためにかかる時間に比べれば微々たるものだ!

本を制作する -- でも、実際に Pages 原稿から PDF と EPUB の電子ブックを制作する作業は、Word 書類をそれと同等の働きをする Pages 書類へ変換する作業に比べればずっと困難の少ない仕事だ。

現在のところ、最終的な編集を受けた原稿(PDF 版と EPUB 版双方に同じものを使う)に施すべき作業はおよぞ 15 個のステップから成っている。いずれのステップも特に難しいものではないが、中には時間のかかるものもある。(例えば、原稿に含まれているリンクを、内部参照のリンクも外部のサイトへのリンクも一つ一つすべてチェックするというステップがあるが、リンクの数の多い原稿の場合にはこのステップの実行に一・二時間かかることもある。でも、ありがたいことに、このステップは一度実行すれば十分のようだ。リンクの動作が EPUB 版か PDF 版のどちらか片方でチェックできれば、もう片方の電子ブックでも必ず動作するからだ。)

いったんこれらのステップの実行が済めば、その書類の流れは二つに分岐する。一つは PDF を作る流れで、もう一つは EPUB を作る。制作作業のワークフローで流れの分岐をできるだけ最終段階に近いところに持ってくることにより、電子ブックの双方の版が同一の内容を含んでいることに、かなりの自信が持てるようになる。通常、コンテンツに含まれるタイプミスなどのマイナーな誤りは、このワークフローの分岐より以前の段階で対処されている。万一分岐のあとでタイプミスが発見されれば、忘れずに二つともの版で修正を施すようにしなければならないが、まあそれは細かいことだ。

EPUB 分岐では、原稿に書き出し操作を施す前の準備として、およそ 10 個のステップを踏む。あるステップでは、原稿に含まれる数十個のスタイルのうち、三つのスタイルに置換を施す。EPUB でより良く機能するスタイルへ修正するためだ。具体的に言えば、Pages の EPUB 書き出し機能は隣り合った複数の段落ブロックに一つのカラー背景を共有させることができないが、私たちの電子ブックでは章の初めの部分やサイドバーでそのような構成が必要となる。そこで、私たちは初行インデントを使う段落スタイルに対して、これらのカラー背景付き段落の直後に空白の部分を置換で挿入するようにしている。また、電子ブックのページマージン設定をしたり (EPUB 書類にはページマージンという概念がなく、EPUB リーダーが独自にマージンを提供する)、目次ページを削除したり (Pages の書き出し機能が独自の EPUB 目次を生成する)、EPUB 版専用に作成した表紙を付けたり、といったこともする。そして最後に、EPUB ファイルを書き出す。

その後は、出力されたものを EPUB リーダーで開いて、目で見て変なところがないか、見栄えのチェックをする。そのために、私たちは iPad 上の iBooks アプリで、横置きと縦置きの両方で、iBooks デフォルトの Palatino フォントを使って本を読む。時には、Firefox で、EPUBReader アドオンを使って抽出検査をしたりすることもある。(2010 年 9 月 10 日の記事“EPUBReader で EPUB を Firefox に表示する”参照。)ワークフロー分岐の後のこれらの作業にかかる時間は通常一時間以下で、その大部分を最後の見栄えのチェック作業が占めている。

いったんそれらのことが全部済めば(そしてもちろん、PDF 版についても同様のステップ数から成る分岐後の作業が済めば)二つの版の電子ブックが私たちの Take Control カタログに追加され販売に供される準備ができたことになる。この最終部分の作業は Adam が担当し、彼が数時間かけて別のコンテンツ管理システムを使って完成させている。

次に来るものは -- 私たちの社内ワークフローと書類のスタイルにさらなる改善を加え磨きをかけることは、常に歩み続ける旅路だ。本というものは、特に Take Control ブックのような技術系の本は、本質的に複雑で、その特定のコンテンツに応じてテンプレートに例外を設けたり調整を施したりする作業が必要となることも珍しくない。結局のところ、テンプレートはコンテンツに奉仕するためにあるのであって、その逆ではないのだから。

それだけではない。私たちはまだ、Mobipocket (Kindle) フォーマットの電子ブックを社内で制作するための良い方法を見つけられないでいる。Amazon が Kindle ブック作成用に出している KindleGen ソフトウェアは、言ってみればブラックボックスであって、フォーマッティングを大量に施した本で私たちが妥当と思えるものを制作するために適用できる方法を、私たちはまだ知らない。だから、Mobipocket 電子ブックについては今もまだ外部委託で O'Reilly に制作を任せている。けれどもいつの日か、EPUB を Mobipocket に変換できる良いコンバータが登場して(あらかじめお断りしておくと、Calibre はそれに該当しない)もしもそれが私たちの望みに合えば、私たちも Mobipocket 版の制作を社内でできるようになるだろう。最近発表された Kindle Format 8 が利用可能になって KindleGen 2 も出れば、状況が変わるということも大いに考えられる。

私たちは Pages で、いくつか思わぬ不満に行き当たった。中でも一番大きいのは、コメントの保持だ。Word では、そのコメントが付随する本文のテキストが削除されたとしても、コメント自体は削除されずそのまま残る。だから、Word では、編集者が単語を一つ選択し、そこにコメントとして「この単語にはミスタイプがあると思います」と書き込んだとすると、著者は容易に問題に気付き、その単語を削除して、正しい単語をタイプできる。けれども Pages では、ミスタイプされた単語を著者が削除した瞬間、コメントも削除されてしまうので、編集者も著者も、あとで編集に問題が残った場合にその変更を施した個所を参照することができなくなる。そこで私たちは、コメントを入れる場所について慎重に注意を払わざるを得なくなった。その上、コメントを選択しても対象となるテキスト部分がハイライトされなくなったので、コメント自体の中に長々と説明を入れなければならなくなった。

もう一つの不満は、Pages の中で原稿をナビゲートする操作に関することだ。Word にはオプションで Navigation パネルを出して、書類のメイン表示領域の左側に、きちんとした目次の形式でサイドバーを表示させることができる。Take Control 関係者の何人かは、これがなくなって非常に困ると苦情を述べた。Tonya はその機能の代替策として、同じ Pages 書類の第二のウィンドウを開いて、そちらで目次の部分を見るか、またはアウトライン表示にしておくという方法を採った。彼女にとっては、狭い部分を編集する最中にも全体像を見られるようにしておくことが極めて重要であるからだ。特に、最終的な電子ブックでユーザーが内部相互参照リンクをクリックする際に、読者によって異なる道筋でリンクを辿ることを考慮するためにはこの機能が必須なのだ。

それでもなお、Pages を採用して、その移行のためにたくさんの仕事が必要となったけれども、それが私たちに好結果として現われつつある。新しい Take Control ブックの制作や既存の本を改訂する作業が以前より素早く、より効率的にできるようになり、EPUB については以前より魅力的な結果が得られるようになった。一生懸命に考え抜いたり調査したりした数十時間の成果としては悪くない。それに、このワードプロセッサの価格は $20 以下なのだから!

コメントリンク12472 この記事について | Tweet リンク12472


TidBITS 監視リスト: 注目のアップデート、2011 年 10 月 31 日

  文: TidBITS Staff <editors@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

iPhoto '11 9.2.1 -- iCloud 対応の iPhoto '11 9.2 が出たばかりだが、もう iPhoto 9.2.1が出た。重要なバグが一つ、3ivxVideoCodec プラグインがインストールされている場合に iPhoto がクラッシュした問題が修正された。それ以外に変更点はないが、もし 3ivxVideoCodec プラグインを使った場合に予期せぬクラッシュに遭遇することのないよう、このアップデートを入手しておくことをお勧めする。(Mac App Store からの新規購入は $14.99、無料アップデート、357.18 MB)

iPhoto '11 9.2.1 へのコメントリンク:

PDFpen と PDFpenPro 5.6 -- Smile の PDF 処理ソフトウェア PDFpen (またはその兄貴分の PDFpenPro) を使って PDF にコメントを入れている人は、PDFpen 5.6 を歓迎するだろう。PDF のメモやコメントに名前を付随させる設定が追加され、匿名でメモやコメントを付けることもできる。これらのオプションのコントロールは PDFpen の Preferences ウィンドウに新設された Editing 環境設定パネルで操作する。また、General 環境設定パネルに新設されたオプションで、あなたのスクリーンの解像度に関係なく実際に印刷されるサイズで書類を表示することもできるようになった。その他の変更点としては、選択の正確度の向上や、回転に関する数多くの問題点の修正などがある。(新規購入 $59.95/$99.95、無料アップデート、41.2 MB)

PDFpen と PDFpenPro 5.6 へのコメントリンク:

TextExpander 3.3.4 -- Smile のテキスト展開ユーティリティ TextExpander への今回のアップデートはバグ修正のみだが、あなたにとって重要な修正が含まれているかもしれない。最も注目すべきは、スニペットや設定を Dropbox 経由でアップデートする際の問題点が TextExpander 3.3.4 で修正されたことと、Dropbox フォルダがあなたのホームフォルダ下にない場合の動作が改善されたことだ。また、キーストロークの組み合わせを使う入力メソッド(日本語や中国語など)での TextExpander の動作方法が今回のアップデートで変更された。その挙動があなたの好みでなければ、ブログ記事にある手順を使って動作方法のリセットができる。ネストされたプレインテキストのスニペットが、それを含むスニペットからフォーマッティングを引き継ぐこともできるようになった。また、さまざまのインターフェイスの表示の問題点や、その他のマイナーなバグも Smile は修正している。(新規購入 $34.95、無料アップデート、5.7 MB)

TextExpander 3.3.4 へのコメントリンク:

KeyCue 6.0 -- Ergonis Software からリリースされたばかりの KeyCue 6.0 を使えば、よく使われている二つの Adobe 製アプリケーションに隠されたキーボードショートカットさえも見つけることができるようになり、また KeyCue のオンスクリーンのキーボードショートカット一覧表にあなた自身がカスタマイズしたショートカット説明を追加することもできるようになった。従来は、KeyCue はメニューに現われるキーボードショートカットすべてを表示していたが、今回は Adobe InDesign と Adobe Photoshop の隠しショートカットを説明したファイルをダウンロードでき、汎用のナビゲーションおよびテキスト編集ショートカットの表も追加できる。Ergonis では今後もさらなるショートカット説明ファイルの作成を予定しているし、あなた自身で説明ファイルを作ることもできる。その他にも、KeyCue 6.0 ではマイナーなバグ修正がいくつか施されている。(新規購入 19.99 ユーロ、最近 2 年間に購入した場合は無料アップグレード、2.0 MB、リリースノート)

KeyCue 6.0. へのコメントリンク:


ExtraBITS、2011 年 10 月 31 日

  文: TidBITS Staff <editors@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

今週は皆さんに紹介したい素晴らしい記事がたくさんある。まずは Mona Simpson による Steve Jobs への追悼文があり、それから噂サイトが本当はどんなにあきれるほど誤ったことを載せているかに関する統計と、カメラで撮影したビデオを iMovie '11 に読み込む方法、iPad の Smart Cover のカラーが変更されたというニュース、Jeff Carlson の登場するポッドキャスト、それに Netflix がどうして 800,000 人もの顧客を失ったかの解説がある。

Mona Simpson が Steve Jobs を追悼 -- Steve Jobs について書かれたものはたくさんあるが、彼の妹である小説家の Mona Simpson が告別式で述べた追悼の言葉ほど、私たちの心に触れるものはない。それは、ほんの少数の人たちの目にのみ触れた Steve Jobs の一面を垣間見ることのできる、とても貴重な輝きを放つ文章だ。

コメントリンク: 12604

私たちはなぜ噂を報道しないか -- 私たち TidBITS は、実際に知られていること(そして有用だと思えること)のみを書くようにしている。それはなぜか? なぜなら、噂の取り引きに加わっても、私たちの生活の中へ必要以上に騒音を加えるだけだからだ。そのことを支持する数字がいくつか、今回発表された。Stupid Apple Rumors サイトが、さまざまの Apple 関係ウェブサイトに載った噂を追跡した結果、全部を総合すれば 75 パーセント以上の割合で噂は誤りだったという。つまり別の言い方をすれば、大体において噂は作り話に過ぎなかったということだ。私たちとしては、自分で話を作り上げるとしてももっとましな筋書きと人物設定にしたいものだと思う。

コメントリンク: 12598

カメラで撮影したビデオを直接 iMovie '11 に読み込み -- iMovie '11 はビデオカメラからならばスムーズにビデオを読み込むことができる。けれども世の中には、デジタルな静止画像カメラでビデオ撮影もできるものがたくさん出回っている。ならば、どうしてこのアプリケーションはそうしたカメラのクリップをもきちんと認識してくれないのか? Macworld 記事で、Jeff Carlson が iPhoto を経由せずに直接ムービーを iMovie に取り込む方法を明かす。

コメントリンク: 12595

iPad 2 用 Smart Cover でカラー変更 -- MacRumors の記事によれば、Apple は iPad 用 Smart Cover のカラーに変更を加えたという。オレンジ色のカバーがなくなって代わりにダークグレイのカラーが加わり、またカバー内側の色が従来どれも同じグレイだったのに対して今回はそれぞれの外側の色にマッチしたものとなった。

コメントリンク: 12597

Dejal Systems の 20 年 -- TidBITS は間もなく 22 周年を迎えようとしているが、他の Mac 関係の会社が同様の記念日を迎えようとしているのも驚くには当たらない。それでも、やはり長い歴史を思えば驚きを禁じ得ない。今回は、つい最近に Mac 用ソフトウェアの製作 20 周年を迎えた Dejal Systems の David Sinclair にお祝いの言葉を贈りたい。その始まりは、1991 年の製品 SndPlayer であった。(彼はこの 10 月末まで、彼のすべての製品に記念の値引きセールをしている。)

コメントリンク: 12594

Jeff Carlson、MacVoices で iPad と iOS 5 を語る -- 二部構成の Chuck Joiner との対談の第一部で、Jeff Carlson は iPad ユーザーが iOS 5 に期待すべき新機能は何か、彼の新刊の電子ブック "Meet the iPad & iOS 5" にどんなことが書かれているかについて語る。(この電子ブックは iBookstore で最近 Top Paid リストの第 3 位にランクされ、一時は Nicholas Sparks の最新作さえ抜いた!)この対談のオーディオのみ版が MacVoices.tv ページにあるリンクからも入手できる。

コメントリンク: 12586

Jeff Carlson、MacVoices で Photoshop Elements 10 を語る -- MacVoices.tv ホストの Chuck Joiner が Jeff Carlson と対談し(二部構成の第二部だ)彼の最新刊の印刷本 "Photoshop Elements 10 for Windows and Mac OS X: Visual QuickStart Guide" を話題にする。このソフトウェアの新機能は何か、デジタル写真のファンという常に変化しつつある人たちに向けて本を仕上げることの難しさについて語る。(この対談のオーディオのみ版が MacVoices.tv ページにあるリンクからも入手できる。)

コメントリンク: 12587

Netflix はなぜ 800,000 人もの顧客を失ったか -- Netflix CEO の Reed Hastings について多くのことを知れば知るほど、ストリーミング (Netflix) と DVD (Qwikster) とのビジネス分離という彼の計画に対してなぜ顧客たちが怒っていたかを彼が根本的に理解していなかったことが見えてくるような気がする。この New York Times の記事の中でさえ、彼の口振りは言い訳がましくて理屈っぽく、人々が夏場の価格上昇で憤慨しているだけではないかと述べたり、Tea Party 運動や「ウォール街を占拠せよ」運動を引き合いに出して国内の怒りっぽい雰囲気のせいにしたりしている。

コメントリンク: 12585


tb_badge_trans-jp2

TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。
告示:書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。

TidBITS ISSN 1090-7017©Copyright 2011 TidBITS: 再使用はCreative Commons ライセンスによります。

Valid XHTML 1.0! , Let iCab smile , Another HTML-lint gateway 日本語版最終更新:2011年 11月 8日 火曜日, S. HOSOKAWA