この情報は、米国アドビシステムズ社が提供しているブログ記事をもとにローカライズし、作成したものです。

Androidデバイス向けの Folio を作成する際には、デザイン的な要素の検討を行う前にAndroidプラットフォームについていくつかのポイントを抑えておく必要があります。例えば、デバイスには様々なサイズや寸法のものがあること。そして、これらのデバイス上で Folio がどのように表示されるかについて、あらかじめ挙動を把握しておくことも重要です。

(この情報は 2012年10月現在のものです。今後、Androidプラットフォームに変更があった場合は、更新する予定です。)

Android タブレットと iOS デバイスの違い

iOS と Android では、Folio の見え方にいくつかの重要な違いがあることに注意してください。

スケーリング

iOS のアプリでは、画面いっぱいにフィットするように記事がスケールアップされます。例えば 1024×768 の Folio は、2048×1536 の iPad HD ディスプレイにフィットするようにスケールアップして表示されます。一方の Android の場合、アプリは記事を一切スケールアップしません。したがって、1024×600 の Folio を 1280×800 のデバイスで表示した場合は、四方に黒帯が表示されます。また、iPad アプリでは縦横比が 4:3 の Folio しか表示できませんが、Android タブレットではあらゆるサイズのFolioを表示することができます。

この例は 1024×600 の Folio を 1280×800 の Nexus 7 で表示したものです。コンテンツをスケールアップする代わりに、黒帯が表示されています。

Android タブレットのアプリで記事をスケールダウンすることは可能ですが、表示性能の観点から記事をスケールダウンするようなことは避けるのが一般的です。

非対応のインタラクティブオーバーレイ機能

Android アプリはパノラマ、PDF 形式の Folio およびインラインビデオに対応していません。また、HTML 形式の記事と Web コンテンツについても注意が必要です。iPad での動作がスムーズな HTML コンテンツでも、Android タブレットでは表示がスムーズに行われなかったり、応答がなかったりすることがあります。こちらの TechNote(英語)を参考にして下さい。

Create HTML articles | Android viewers | Digital Publishing Suite

システムバー

Android タブレットの多くは、システムのナビゲーションバーが Folio の表示領域にはみ出すため、記事が意図せずスケールされる原因になります。これを避ける方法については後ほど解説することにします。システムバーについては、デバイスごとにその大きさが異なる点もさらに事態を複雑にしています。例えば、Motorola Xoom や Galaxy Tab の 10.1 インチデバイスには 48 ピクセルのシステムバーが装備されていますが、Google Nexus 7 の場合は横置きで75ピクセル、縦置きで 64 ピクセルのシステムバーが表示されます。

なお、Kindle Fire のアプリにはシステムバーが表示されません。また、Froyo(OS 2.2)を採用する Android タブレットにもシステムバーは表示されません。

Nexus 7 インチの Folio ビューにはシステムバーが表示されますが、Kindle Fire の Folio ビューには表示されません。

 

非対応のデバイス

iOS については、すべての iPad および iPhone デバイスがサポート対象です。Android については、画面サイズが Large および XLarge のデバイスがサポート対象になります。Smal lまたは Normal の Android デバイスを使用するユーザーが Google Play の Android ストアにアクセスしても、DPS アプリは表示されません。

Folioと記事の縦横比の一致

iOS と Android のアプリに共通する重要なポイントとして、Folio と記事の縦横比を必ず同じにしなければならないことが挙げられます(Smooth Scrolling の記事を除く)。つまり、1024×768 の記事を 1024×600 の Folio に追加することはできません。しかし、仮に記事が 480×320 の場合は、縦横比が同じ 3:2 の1200×800 の Folio に追加することができます。Android アプリ自体がコンテンツを拡大表示することはありませんが、DPS ツールは Folio のサイズと一致するようにソースファイルの記事をスケールすることができます。このコンテンツをスケールする機能を利用すれば、後ほど解説するとおり、単一のソースを使い回すという便利な手法が活用できます。

Android オペレーティングシステム

DPS アプリは Android OS 2.2(Froyo)とそれ以降に対応しています。OS 3.x(Honeycomb)からは、すべてのアプリケーションの最下部にシステムバーが表示されるようになっています。最新の Android タブレットには OS 4.0(Ice Cream Sandwich)または OS 4.1(Jelly Bean)が採用されています。

なお、Kindle Fire には、Android OS のカスタマイズ版が採用されています。第1世代の Kindle Fire(1024×600 SD)にはカスタマイズ版の Froyo が、そしてより新しい Kindle Fire(1280×800 HD)と今後登場するモデル(1920×1200 HD)には修正版の Ice Cream Sandwich が採用されています。Amazon のタブレットについては注目すべき事柄があります。それは Amazon のタブレットに表示されるシステムバーが Folio のデザイン領域に影響を及ぼさないということです。1024×600 の Folio を Fire SD で表示する場合でも、1280×800 の Folio を Fire HD で表示する場合でも、記事はスケールされることがありません。記事が表示されている場合、ユーザーはライブラリに戻り、システムバーのボタンをタップすることでアプリの終了を指示することができます。

Android タブレットのシステムバーを除去したり、ソースファイルに安全な領域を確保できたりすれば良いのですが、実際にはそのようにできないのが残念です。

Android タブレットで人気の高いサイズ

2012 年 10 月の時点で、Android タブレットのサイズは 1024×600、1280×800、1920×1200 の 3 つに集約されつつあります。

1024×600 デバイスの代表例は、Samsung Galaxy Tab 7 インチ、Kindle Fire 7 インチ SD および Acer Iconia Tab です。

1280×800 デバイスとしては、Samsung Galaxy Tab 10.1、Samsung Galaxy Tab 8.9、Motorola Xoom、Nexus 7、Kindle Fire 7 インチ HD、Sony Tablet S などがあります。XLarge SD サイズの 1280×800 デバイス(Xoom など)には、Folio ビューで 48 ピクセルのシステムバーが表示され、Large HD のデバイス(Nexus 7 など)には縦置きビューで 75 ピクセル、横置きビューで 64 ピクセルのシステムバーがそれぞれ表示されます。繰り返しになりますが、Kindle Fire の Folio ビューにはシステムバーが表示されません。

最新の XLarge デバイスで HD コンテンツを表示したいと考えるメーカーは、1920×1200 の寸法を採用する傾向にあります。例えば、最近発表された Kindle Fire 8.9 インチの HD デバイスは 1920×1200 の寸法を採用しています。Asus Transformer Pad Infinity と Acer Iconia Tab も 1920×1200 の XLarge スクリーンを搭載しています。これらのデバイスについては、残念ながら実機を試す機会がなかったため、システムバーのサイズを確認するには至っていません。(情報をお持ちの方はコメントを投稿してください。)

また、2560×1600 の Android タブレットが近々登場するという話もあります。つまり我々は、常に動き回るターゲットを追っているのと同じような状態にあるのです。

筆者が知る限り、1024×768 の解像度を採用するAndroid機種は普及していません。

Folio のレンディションのサイズ

DPSツールを使用すれば、個々のアプリでデバイスの寸法に最適なFolioが表示されるように、Folioの様々なレンディションを作成することができます。レンディションの概念に馴染みがない場合は、Folioのレンディションについてのこちらの記事を確認してから、続きを読むようにしてください。

では、Android タブレット用のFolioのサイズはどの程度にすれば良いのでしょうか。また、Folioが最も簡単に作成できるのはどの方法なのでしょうか。これらの質問に手短に答えられれば最高ですが、残念なことに、ここではコンテンツのデザイン、レンディションの作成にかけられる時間、iOS用のFolio制作においてどのようなFolio制作経験があるかといった、複数の要素によって回答が異なります。では、いくつかのワークフローシナリオについて見てみることにしましょう。

レンディションの使い分け

シナリオの解説を始める前に、まずは出版者が基本的なレンディションを作成する際に混乱しがちな、システムバー関連の問題を取り上げます。仮に、読者が1024×600と1280×800の2つのレンディションを作成するとします。Kindle Fireデバイスでは、すべてが意図通りに動作します。SD タブレット(Kindle Fire)では1024×600のレンディションが表示され、HD タブレット(Kindle Fire HD)では1280×800のレンディションが表示されます。

では、XoomやNexus 7などのAndroidデバイスではどうでしょうか。1280×800のこれらのデバイスでは、1280×800のレンディションではなく、1024×600のレンディションが表示されます。これは、システムバーの影響で1280×800のレンディションが縮小表示され、パフォーマンスが低下するのを防ぐために、縮小表示の必要がない大きさのFolioをアプリが選択するからです。

このため筆者は、以下のシナリオを参考に、あらかじめシステムバーの影響を考慮した特別なレンディションを作成することを推奨しています。

シナリオ1:流用

既に iPad 用に 1024×768 の Folio を作成していたとします。そして今回、この Folio を Android タブレットにも提供したいとしましょう。この考え方で問題はないのでしょうか。仮に Android 非対応の機能(パノラマ、PDF 形式の Folio、インラインビデオおよび一部の HTML コンテンツ)を避けることができ、しかも搭載するインタラクティビティが単純で、アプリが Folio をスケールダウンしても処理能力に余裕があるような場合は、上記の考え方でも問題ありません。この場合は 4:3 のコンテンツを 16:10 または 16:9 のデバイスに表示するだけなので、レターボックス(上下の黒帯)または(および)ピラーボックス(左右の黒帯)が表示されることになります。たいていの場合、Folioが素人っぽく見えるという欠点があります。

シナリオ2:全部作る

このシナリオでは、あらゆる手立てを用いて、画面スペースを最大限に有効活用し、アプリが Folio を縮小表示しないようにします。仮に時間とリソースに制限がない場合は、Android タブレット向けに以下のレンディションを作成するようにします。

  • 1024×600 – Galaxy Tab 7 インチおよび Amazon Fire (SD) に適したレンディションです。
  • 1205×725 – 縦横の両方に対応するこのレンディションは、1280×800 の 7 インチ HD デバイスで 75/64 ピクセルのシステムバーが表示されるものに適しています。1 方向のみ対応するレンディションを作成する場合は、横置きは 1280×736(64 ピクセルのシステムバー)、縦置きは 1205×800(75 ピクセルのシステムバー)のいずれかで作成します。1 つの Folio に 1280×734 と 1205×800 の両方の記事を収録できません。これは Folio と記事の縦横比が必ず一致しなければならないからです。
  • 1232×752 – 縦横の両方に対応するこのレンディションは、1280×800 の 10 インチ SD デバイスで 48 ピクセルのシステムバーが表示されるものに適しています。1 方向のみ対応するレンディションを作成する場合は、横置きは 1280×752、縦置きは 1232×800 のいずれかで作成します。
  • 1280×800 – このレンディションは Kindle Fire 7インチHD に適しています。
  • 1920×1200 – このレンディションは Kindle Fire 8.9 インチ HD に適しています。ソースファイルは 1280×800 の Folio で使用したのと同じものが利用できます。1280×800 と 1920×1200 のデバイスには、どちらも同じ縦横比(8:5)が採用されています。
  • 1820×1100 – このサイズについては筆者も自信がありませんので、1920×1200 のデバイスに対して 100 ピクセルのシステムバーを確保しておきたいと思います。これらのデバイスでは、DPS アプリが正常に動作するかどうかもわかりません。これについては、詳しい情報が入り次第、記事を更新したいと思います。

なお、Android 向けのレンディションと iOS 向けのレンディションを権利付与サーバーの利用などの理由でひとつにまとめなければならない場合は、Folio ごとに 10 種類ものレンディションが必要になることもあります。

現時点でまとめた一覧表を次に示します。

ターゲットサイズ デバイス 双方向 縦置きのみ 横置きのみ
1024×600 Amazon Fire SD、Galaxy Tab 7インチ 1024×600 1024×600 1024×600
1280×800 (Android SD 10インチ) Xoom、Galaxy Tab 10インチ 1232×752 1232×800 1280×752
1280×800 (Android HD 7インチ) Nexus 7インチ 1205×725 1205×800 1280×734
1280×800 (Amazon HD 7インチ) Kindle Fire 7インチHD 1280×800 1280×800 1280×800
1920×1200 (Android HD 10インチ) Asus Transformer Pad Infinity、Acer Iconia Tab ?x? ?x? ?x?
1920×1200 (Amazon HD 10インチ) Kindle Fire 8.9インチHD 1920×1200 1920×1200 1920×1200

シナリオ3:有効な近道

Android アプリ向けには、ひとまず単一方向のデザインだけ手がけることをお勧めします。デザイナーの多くは、Folio のすべての記事を縦置きと横置きの両方のレイアウトで作成する必要はないと考えています。少なくとも、リキッドレイアウト用のコードが設定された HTML 形式の Folio が対応するまでは、この状況が続くでしょう。iPad のような大きめのデバイスは横置きレイアウトにするのが筆者の好みです。縦置きのレイアウトは、iPhone や Kindle Fire といった片手で操作できるデバイスに適しています。いずれにせよ可能であれば、どちらかの向きにデザインを特化し、その向きを使い続けるのがお勧めです。

一部の出版者は一連の既存ソースファイルから複数のレンディションを作成しています。いずれのケースでもコンテンツが画面全体に表示されることはありませんが、それにかなり近い状態にはなります。

仮に、iPhone 向けに 960×640 の縦置き専用レンディションが作成済みであったとします。この 3:2 の縦横比は Android タブレットにも効率良く流用できるかも知れません。同じソースファイルを用いて 1200×800 の縦置き専用レンディションを作成すれば、1280×800 のデバイスに問題なく対応できます。厳密にはソースファイルのバックアップを作成し、一部のフォントサイズやレイアウトを調整しなければならないかも知れませんが、スタート地点としては十分と言えるでしょう。また、別に 1024×600 の Folio レンディションを作成するのもお勧めです。InDesign CS6 には代替レイアウトという新機能が搭載されており、レイアウトの変換を効率良く行えます。

もうひとつ、1024×600 のソースファイルから始めるケースを考えてみましょう。この場合は大きなレンディションのために新たなソースファイルを作成する代わりに、単一のソースファイルで作業を行い、同じ縦横比を採用する別の大きなFolioに読み込む方法があります。例えば、いったん1152×675 の Folio を作成し、これに 1024×600 の記事を読み込むといった方法です。こうすれば Nexus 7 や Xoom などのタブレットではレターボックスやピラーボックスこそ表示されるものの、見え方としては(理想ではありませんが)耐えうる範囲に収まるものと思われます。次に示すのは、Nexus 7 で 1152×675 の Folio を表示した状態です。

1152×675 の Folio を 1280×800 のデバイスで表示した場合、レターボックスとピラーボックスは表示されるものの意図せず拡大して表示されることはありません。

別の考え方としては、Amazon Fire デバイスを主なターゲット、システムバーが表示される Android タブレットを二次的なターゲットにそれぞれ設定する方法もあります。このワークフローの場合は 1024×600 と1280×800 用のソースファイルを作成し、同じソースファイルを、8:5 の縦横比を持つ 1280×800 と1920×1200 の両方の Folio に使用します。これらのソースファイルから作成する Folio は Kindle Fire で体裁良く表示されるはずです。Android タブレットでスケーリングが起こるのを防ぐには、縦横比が同じで、スケーリングを起こすことがない Folio のレンディションを、同じソースファイルを使用して作成します。例えば、1280×800 で作成したソースファイルなら、1160×725* の Folio にインポートすることができます。このレンディションなら、システムバーが表示される Android タブレットでも使用に耐えうる範囲に収まります。

* 根拠を示すと、1280×800 は 8:5 の縦横比になり、8 と 5 にそれぞれ 145 をかけあわせるとそれぞれ1160 と 725 になります。なお、同じ 1280×800 のソースファイルを 1024×600 のデバイスで使用したい場合は、8 と 5 にそれぞれ 120 をかけると 960×600 になります。この場合、両サイドには 32 ピクセル幅の黒帯が表示されます。

厳密なレンディション

DPS App Builder の v22 リリースには、「7 インチ Android タブレット向けに厳密にレンディション」という新しいオプションが装備されています。このオプションは iOS と Android の両方のアプリケーションで同じタイトルID(アプリケーションアカウントが設定されたAdobe ID)を使用し、7 インチの Android タブレットで 1024×600 または 1280×800のいずれかの Folio が必要なアプリに有効です。このオプションを選択すると、iPhone および iPad に特化するようデザインした Folio(特に PDF 形式の Folio や機能満載の Web コンテンツを含む Folio)が、Kindle デバイスで表示されるのを防止できます。

先ほど、同じタイトル ID を iOS と Android の両方のアプリケーションで使用する話が出ましたが、同じタイトル ID の使用はカスタムの権利付与サーバーを導入している企業のお客様にのみお勧めできる事柄です。権利付与サーバーを導入していれば、iPad で購読を購入したお客様に対し、Android タブレットでも Folio を楽しめるようにするといったことが可能になります。

筆者の経験から言うと、iOS と Android のアプリケーションでは別々のタイトル ID を使用する方が賢明です。弊社が Android ストアと Apple App Store にて公開している DPS Tips を使用する場合、iPad だけで機能するコンテンツ用にダミーの Android 用 Folio を作成するのが面倒になっていました。筆者が作成した最新のバージョンでは、Android 限定の Folio を別のタイトル ID を用いて作成することによって、この問題を解決しています。最新バージョンをダウンロードすれば、ライブラリにダミーバージョンの「Single Edition」Folio が収録されていないことに気付くはずです。

Nook の対応について

Nook には、出版者が自らのアプリケーションを提出することができる、App Store のようなオープンな仕組みがありません。Nook で利用できるアプリケーションを開発・公開したい場合は、Barnes & Noble に直接連絡を取る必要があります。アドビは既に Barnes & Noble に対して SDK を提供しており、この SDK を使用することで、カスタムの DPS アプリケーションを開発し、お客様が権利を持つ Folio にコンテンツを提供できるようにすることも可能です。Barnes & Noble が読者との協働に興味がある場合は、1024×600 の Folio を作成し、これを Folio Producer を使用して.zip ファイルに書き出してから、.zip ファイルを Barnes & Noble に提出します。Barnes & Noble はこの記事の執筆時点で v19 SDK を使用していますが、近々、v21 にバージョンアップする予定のようです。

繰り返しになりますが、Nook 用の DPS アプリケーションをパブリッシュしたい場合は、Barnes & Noble に詳細を問い合わせてください。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー