kobo、epubやってます

7月に楽天koboの電子書籍がスタートしたのはご存知だと思います。
CTEでは、そのデータ制作をしています。DTPデータからのepub制作を毎月50冊前後行っています。

制作する書籍は、実用書です。InDesignがほとんどですが、Qxpもあり、他の電子書籍のデータと思われるタグの付いたテキストもあります。
弊社では１年前からモリサワのMCBookを使用して電子書籍制作を行っていました。
MCBookは、epubの書出しができますので、それを利用しています。

koboの仕様が変わったりとか、縦書き時に画像がセンタリングしなかったりとか、
MCBookからのepubが、font-familyの設定に問題があったりとか（今は解決）、
品質管理、校正をどうするとか、限られた予算のなかで何をすべきかなどなど、
いろいろな課題をクリアしています。

また、DTPデータは一定の制作ルールで作られているわけではなく、作り方は、一冊一冊、異なっています。
正しくスタイル定義し、字下げ設定を行っているものも有れば、スペースと改行で調整しているものも有り、品質もバラバラです。
これを効率良く処理するために、制作フローとルールを作ったり、効率良い制作を行うためのマニュアル作りが必要になります。

こうした改善を繰返し、電子書籍制作を進めています。

【InDesign】InDesignのバグ2点

今回は、仕事中に発見したInDesignのバグを2点ご紹介します。
1点は解決方法がありますが、もう1点は解決方法がありません。
もしこれから同じような処理を行う予定の方はご注意下さい。

１　CS5〜限定　bottom right corner optionのバグ＆回避方法

　CS5から、text frameやrectangleの角丸の設定の仕様が変更され、4つの角を別々に制御できるようになりましたが，バグを1点発見しました。4つ角のプロパティは下記の通りです。

・top left corner option 　　　 角のシェイプ左上
・top left corner redius　　　　角のサイズ左上
・top right corner option 　　　角のシェイプ右上
・top right corner redius　　　 角のサイズ右上
・bottom left corner option 　　角のシェイプ左下
・bottom left corner redius　　 角のサイズ左下
・bottom right corner option 　 角のシェイプ右下
・bottom right corner redius　　角のサイズ右下

このうちの、「bottom right corner option」だけが、スクリプトエディタ上に入力することができません。コンパイルできなくなってしまいます。
Adobeのフォーラムを検索したところ、「«property pcO4»」と入力すると、「bottom right corner option」にコンパイルされるようです。
（参照：http://forums.adobe.com/thread/829997）

ですが、このままだとコンパイルのたびに「bottom right corner option」を「«property pcO4»」に打ち直ししなければならず、正直仕事になりません。

そこで、テキストをスクリプトとして評価するという方法でこの現象を回避してみようと思い、下記のルーチンを作成しました。

[applescript]
–bottom right corner optionを取得
on getBottomRightCornerOption(frameID, appName)
set aScript to "
tell application \"" & appName & "\"
tell document 1
tell text frame id " & frameID & "
set bottomRightCornerOption to «property pcO4»
end
end
end" as string
set aResult to run script aScript
return aResult
end getBottomRightCornerOption

–bottom right corner optionを設定
on setBottomRightCornerOption(frameID, bottomRightCornerOption, appName)
set aScript to "
tell application \"" & appName & "\"
tell document 1
tell text frame id " & frameID & "
set «property pcO4» to " & bottomRightCornerOption & "
end
end
end" as string
set aResult to run script aScript
end setBottomRightCornerOption
[/applescript]

上がプロパティの取得用、下が設定用です。
取得用ルーチンに渡すパラメータは、

１　オブジェクトのID
２　アプリケーション名

設定用ルーチンに渡すパラメータは、

１　オブジェクトのID
２　取得用ルーチンで取得した値
３　アプリケーション名

です。アプリケーション名を渡すことにしてあるのは、CS5以降のverでも使用できる可能性を考えてのことです。CS5.5を調べてみたところ、修正されていないようでしたので……。

これで、面倒な作業なしに開発に集中できるようになりました．

２　CS5まで？　anchored object settingsのバグ（回避方法なし）

アンカーオブジェクトのあるプロパティの設定が、GUIからできることとスクリプトからできることが異なる、という現象です。
親文字からの間隔を「カスタム」にすると、アンカー付き位置の「Y基準」を設定できるようになりますが、ポップアップメニューからは下記の列挙値が取得できると思います。

・行（ベースライン）
・行（キャップハイト）
・仮想ボディの上
・仮想ボディの中央
・仮想ボディの下
・行（行送りの先頭）
・列枠
・テキストフレーム
・ページマージン
・ページ枠

これらと、AppleScriptの辞書で定義されている列挙値を比較すると、以下のようになります．

・行（ベースライン）　　line baseline
・行（キャップハイト）　capheight
・仮想ボディの上　　　　（値なし）
・仮想ボディの中央　　　（値なし）
・仮想ボディの下　　　　（値なし）
・行（行送りの先頭）　　top of leading
・列枠　　　　　　　　　column edge
・テキストフレーム　　　text frame
・ページマージン　　　　page margins
・ページ枠　　　　　　　page edge
・（値なし）　　　　　　line Xheight
・（値なし）　　　　　　line ascent

このなかで特に困るのが、仮想ボディ関係のプロパティです。大概の自動処理系の作業は、手作業でのデータやテンプレートがまずあって、それにあわせて仕様を設定するということが多いと思いますが、そこでこれらの値が使用されている場合、スクリプトで対応できなくなってしまいます。同じような作業を行う際はご注意ください。

ちなみに、こちらはCS4でも同じ現象が見られますので，それ以前も同様の可能性があります（確認はしていません）．CS5.5では修正されているようです。許されるならば5.5に上げてしまうのも一つの手段かと思われます．

開発完了からはじまるお仕事

プロジェクト管理者としてiOSのアプリケーション開発に従事している今日このごろ。お客様と打ち合わせを行って仕様を決めたり、開発チームと打ち合わせを行って方向性や進捗状況や問題を相談したりと、なかなか「小忙しい」日々を過ごしています。

仕様どおりに開発できていることをお客様に確認いただき、納品状態に到達できれば、開発チームは「おつかれさまでした」ということになるわけですが、プロジェクト管理者はそうもいきません。

魔の「AppStore申請作業」が待っています。

まずは、開発が完了したXcodeのプロジェクトを再度チェックしなくてはなりません。

バンドルIDは合っているのか？　バージョン番号は？　ターゲットのハードウェアは合っているのか？　iPhone専用なのにiPhone/iPad向けユニバーサルアプリ設定になっていると大変です。テスト時には気にもしなかったことが、申請段階になると大問題。

さらに今回大変だったのが……英語向け画面の追加を行ったので、説明文の吟味や追加や調整やら。

ふだんはぞんざいに「いんでー」「ふぉとしょー」「いられー」などと呼ばれているシロモノが、「Adobe InDesign」「Adobe Photoshop」「Adobe Illustrator」などなどと、ちゃんとしたお名前でご紹介しないと大目玉をくらいかねないわけで、AppStore上のアプリ紹介文の再チェックも大変です。

AppStore申請作業は一度ミスると、やりなおすのにも時間がかかります。普段はだいたい５営業日ほど待つと審査してもらえるわけですが、却下（リジェクト）されると（問題解決後に）また待ち行列に並び直す必要が……。

お客様とのお約束の日にAppStoreからダウンロードできる状態を作るため、Appleに却下されないよう細心の注意を払わなくてはなりません。Appleのレビューワーに「この機能が付いているけれど、こういう目的のためであって悪意があるわけじゃないよ〜」などと英語で文章を書いてみたりと、涙ぐましい工夫のかずかずかずかず。

開発のためにコードを書いたり、打ち合わせのためにプレゼン資料を作るのは楽しい仕事ですが、このAppStoreへの申請作業は何回やっても心身ともどもすりへります。

また、このやっかいな作業をさらに困難にしているのが、各種申請画面のそっけないWebインタフェース！！！　アプリ申請用画面もAppleならではのシンプルさが貫かれています。

なるべく画面上に雑多なボタンやメニューを置きたくない……という美学なりはよく分るのですが、何も「他の言語（外国語）の説明追加を行うのに、ポップアップメニューの中を漁らないと分らない」状態にすることはないんじゃないでしょうか。ものによっては、美学なのか不親切なのか……悩ましいところです。

一番困るのが、申請画面で操作を行っても反応がないケース。

「何か間違ったことをしただろうか？」と悩まされることに。まさか、サーバー側が障害で落ちているなんて！　最初に遭遇したときには半日待ってしまいました。

今日も、画面のスナップショットをアップロードしたら、エラー表示に。画面キャプチャのサイズもフォーマットも色空間もみんな合っているのですが、いっこうに受け付けてもらえません。

これって、ワナですか？　それとも、仕様ですか？