【EPUB】Adobe Digital Editionsではルビにrp要素があると1文字目だけしかルビを表示しない場合がある

鎌田です。

ルビを、ルビの表示に対応していないブラウザへのフォールバックに用いるrp要素を用いた書き方をすると、Digital Editionsでは親文字1文字目だけ表示し、2文字目以降表示されない場合があります。
rp要素を取った、ルビの書き方にすれば、正しく表示されます。

【EPUB】Kindle Preview版では横書きだが、実機では縦書きになる

鎌田です。
EpubをKindle Preview版で変換し、mobiファイルで確認しています。
デバイスをKindlre Touchにすると縦書きになりますが、それ以外のデバイスでは横書きになっています。

不安だったので、問合せしたところ、Amazonから購入したものは、どのデバイスでも縦書きになるということです。
安心しましたが、リーディングシステムによって見え方が異なる現在のEpubで、さらに制作環境と本番環境でも見え方が異なるというのは、本当に困ったことです。

先の投稿で、①がKindleで制作環境では縦で表示されますが、実機では横になります。各リーディングシステムで同じ見え方になるEpubを作るのは不可能なのでしょうか。

【EPUB】Adobe Digital Editionsでは①が横に寝る

鎌田です。
EPUBの校正で、Adobe Digital Editionsを使用しているのは、先に書いた通りです。しかし、ここでも問題が発生しました。
丸数字①②などが縦書きで横になってしまいました。
そこで、縦中横タグをいれて、正しく表示させるよう回避しました。
これで、Digital Editions、kobo、Readium、Kindle Previewで問題なしと思っていたのですが、
mobiファイルAmazonにアップロードすると、丸数字が寝ているとの連絡が入りました。
Preview版と実機では表示が異なるようです。
さて、どうしようかと考え中です。

ここら辺のリーディングシステムでの表現の違いについての詳しい事は、次のURLが参考になります。
http://blog.cas-ub.com/?p=3524

下記画像は縦中横タグを入れない、素のテキストで表示させた場合です。

Digital Editions（K.K以外が横になってます）

Readium（縦になっています）

Kindle Previews（丸数字が縦、それ以外はK.Kを除き横になってます）

iBooks(3.01)（K.K以外は横になってる。飛行機、メール、チョキが携帯フォントだ！）

【EPUB】AdobeDigitalEditionsはライブラリに登録するとプリントできる

鎌田です

制作したEPUBを底本と検品するためには、EPUBをプリントする必要があります。
ところが、縦書きでプリントできるリーディングシステムがなかなか見つかりませんでした。
Google ChromeのReadiumで縦書きでプリントできたのですが、上下微妙に文字が欠けます。

DigitalEditionsは1.8Previewで縦書きをサポートしましたが、プリントメニューがグレイになり、選択できませんでした。
Previewリリース版なので、未対応なのかなと思っていましたが、たまたま、ライブラリに登録しているファイルを表示すると、プリントメニューが有効になっていました。「えっ？」と思い、もしかしてライブラリにあればプリントできるのか？　と思い、プリントできなかったEPUBをライブラリに登録すると、メニューが有効になりました。

【EPUB】楽天koboの日本語フォントでの表現は4種類

鎌田です

楽天koboにはモリサワのリュウミンとゴシックMB101が利用出来ます。
2書体だけだなと思っていたら、CSSでfont-weight:boldの指定が可能でした。
つまり、表現として4種類が可能です。

ただし、bold指定をすると文字揃えを行うとboldで太らせた分が揃わなくなります。
特に目次など、字下げを揃えてキレイに表現する箇所でboldを使うと、デコボコしてしまいます。
弊社では、目次ではbold指定は禁止にしています。

【EPUB】iBooks3になっています

ファーストインプレッション
iBooks3で、
1) 日本語縦書き表示で、右から左に正しくページめくりができるようになった。
2) ページのめくり方に、スクロールが追加された。
3) 対応フォントが増えました。日本語だけでなく、中国語のepubなら中国語フォントが利用できます。

【EPUB】楽天koboのepubファイル名称は〜kepub.epubにする

鎌田です。
今日は、iPad miniの発表や、Amazon Kindleの発表もありました。
電子書籍の本当の元年は今年なのだと思います。

さて、この5ヶ月間、電子書籍制作にどっぷり浸かっています。
こんな事がありました！、こんな事で苦労してたんですというのを、ご報告していきます。

楽天koboのepubファイル名は〜kepub.epubにする。
今では常識ですが、出版社様からこの情報を貰うまでは、epub拡張子で作り、日本語表示がおかしくなるのに悩みました。
epub拡張子のままでも、日本語表示します。ただ、文字間が空き、句読点がズレます。
この微妙なズレを、制作の仕方が悪いのだと思い、数時間いろいろと調べまくって、作り直して、と闘ってました。
出版社様からkepub.epubにしてくださいと教えていただき、なーんだそうだったのかとなった次第です。
epubの制作を依頼されたのがkoboオープンの2週間前、直ぐにepub作って、直ぐに納品しなくてはいけませんでした。
出版社様も弊社もkoboルールを知らなかったので、大変焦って調べていました。

日付計算の落とし穴　(その２)

前回の「日付計算の落とし穴」の続きです。
それでは、翌月の末日を取得したい場合にはどうすれば良いか？
という話ですが、以下のようにすれば良いことが分かります。

実行環境：PHP version 5.2.6

[php]

<?php

print("2012/01/29の一か月後→".GetNextMonth_Fixed("2012/01/29")."<br>");
print("2012/01/31の一か月後→".GetNextMonth_Fixed("2012/01/31")."<br>");
print("2012/02/29の一か月後→".GetNextMonth_Fixed("2012/02/29")."<br>");
print("2012/03/31の一か月後→".GetNextMonth_Fixed("2012/03/31")."<br>");
print("2012/04/30の一か月後→".GetNextMonth_Fixed("2012/04/30")."<br>");
print("2012/05/31の一か月後→".GetNextMonth_Fixed("2012/05/31")."<br>");
print("2012/06/30の一か月後→".GetNextMonth_Fixed("2012/06/30")."<br>");
print("2012/07/31の一か月後→".GetNextMonth_Fixed("2012/07/31")."<br>");
print("2012/08/31の一か月後→".GetNextMonth_Fixed("2012/08/31")."<br>");
print("2012/09/30の一か月後→".GetNextMonth_Fixed("2012/09/30")."<br>");
print("2012/10/31の一か月後→".GetNextMonth_Fixed("2012/10/31")."<br>");
print("2012/11/30の一か月後→".GetNextMonth_Fixed("2012/11/30")."<br>");
print("2012/12/31の一か月後→".GetNextMonth_Fixed("2012/12/31")."<br>");

function GetNextMonth_Fixed($pDate){
$wkTimeStamp = strtotime(‘+2 month’,strtotime(date("Ym01",strtotime($pDate))));
$wkTimeStamp = strtotime(‘-1 day’,$wkTimeStamp);
$wkDate = date("Y",$wkTimeStamp)."/".date("m",$wkTimeStamp)."/".date("d",$wkTimeStamp);
return $wkDate;
}

?>

[/php]

一旦、当月の１日に遡る
↓
２カ月後の日付を取得する
↓
１日前の日付を取得する

という手順を踏むことで、翌月の末日を取得することができました。

出力結果：

2012/01/29の一か月後→2012/02/29
2012/01/31の一か月後→2012/02/29
2012/02/29の一か月後→2012/03/31
2012/03/31の一か月後→2012/04/30
2012/04/30の一か月後→2012/05/31
2012/05/31の一か月後→2012/06/30
2012/06/30の一か月後→2012/07/31
2012/07/31の一か月後→2012/08/31
2012/08/31の一か月後→2012/09/30
2012/09/30の一か月後→2012/10/31
2012/10/31の一か月後→2012/11/30
2012/11/30の一か月後→2012/12/31
2012/12/31の一か月後→2013/01/31

今後もPHPについてのTipsがあれば、
備忘録を兼ねて投稿しようと思います。

はじめの一歩！　ホウ・レン・ソウ

先日maro氏が「開発完了からはじまるお仕事」という記事を書かれてたので
私も全体的な仕事はじまりのマナーというか意識をふりかえってみます。

オペレーターから、デザインや多言語などのちょっと変わったお仕事や
他社さんへ出向してディレクションしたり、CTEで一回り年月が経ち（恐ろしい！）
ここ何年かは開発メンバーの進行管理のお仕事が中心です。

DTP開発はお客様依頼での自動組版やテキスト抽出等が
メインだと思われがちですが、社内の効率化や事故防止という観点で、
日常使えるスクリプト作成やプラグイン開発も多いです。

しかし弊社社内でも一番先に相談してくれれば、
もっと省力化やアドバイスができたのにもったいないなぁ〜　
と後から情報を聞いて残念に思う話が多々あります。

お客様はいつまでに、どんなものを最終的に納品希望されているのか。
ただシンプルに、これだけにすぎないのですが、
聞けない、確認できない、先を想定できない人が意外と多いです。

・最終的な納品物がどんなものか？　【仕様の確認】
・納品するための作業、やるべきタスクリスト【ワークフローの確立】
・どれくらい人や時間がかかるか？【逆算スケジュールの必要性】　

そこで、打ち合わせや必要な物の準備がはじまります。
これはDTP開発だけでなく、どんなお仕事にも通じる事かと思います。
（この【3つのポイント】の詳細についてはまた次回に…）

前置きが長くなりましたが、今回は仕事の基本として
誰しも耳にした事があるはずの「# ホウ（報告）レン（連絡）ソウ（相談）」
こちらについても自発的に実行できている人は少ないです。

ホウ・レン・ソウは、仕事上で必要なコミニケーションの要約です。
会社に属している限り、仕事は一人で完結するものではありません。
タイミングや伝えるポイント、相手の性格によっても違ってくるので、
「忙しそうだな〜」「どうせダメだろう」という自己判断や
面倒くさいから後回しにしたら忘れたと、なかなか徹底できないのかもしれませんが…　
日々のホウ・レン・ソウは自分の効率化や保守にもつながります。
お客様に対しては信用問題になりかねますので、素早く返信も基本です。

・いただいた電話やメールを1日以上放置していませんか？
・同じミスや作業を繰り返していませんか？　変更情報が共有されてますか？
・お客様や関係者から「○○の件、どうなってますか？」と
　問い合わせが度々ありませんか？　その内容を確認していますか？

長くなりましたが、仕事を円滑にするはじめの一歩！として
聞かれる前に自分からホウ・レン・ソウを心がけてみるだけで、
お仕事の流れが変わってくるかもしれません。（U）

Continue reading »

kobo、epubやってます

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

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

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

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

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