‘サロゲートペア’ タグのついている投稿

EPUB用IVS/サロゲートペア文字チェッカーを作ってみた

2013/05/07

 前回のエントリで書かせていただいた通り、現状IVS/サロゲートペア文字はビューアの表示でトラブルになるケースが多いため、EPUB3データの中にIVS/サロゲートペア文字が混入していないかどうかチェックするためのチェッカーを作ってみました。また、三分スペース(THREE-PER-EM SPACE/U+2004)などのJIS X0213に符号位置割り当てのないスペース文字が一部のリーディングシステムで文字化けするとのお話がありましたので、こちらのチェックもできるようにいたしました(ある方よりご要望をいただいたため機能を追加しました)。
 引数としてEPUBファイルのパスを与えてやると内容をチェックしてログを出力するだけの簡単なものですが、制作の役に立てていただければ幸いです。

 Mac、Winともに使用することは可能ですが、環境によってはモジュールの追加インストールが必要になるかも知れません。私の環境ではWindowsのActivePerl環境にMinGWモジュールを追加インストールする必要がありました(コマンドプロンプトで「ppm install MinGW」と入力)。

use utf8;

#Encodeモジュールをインポート

use Encode qw/encode decode/;

use File::Basename qw/basename dirname/;

use Archive::Zip;

use Archive::Extract;

use File::Path;

#引数1で指定したepubファイルを取得

$epubFilePath = $ARGV[0];

$epubFilePath = decode(‘UTF-8’, $epubFilePath);

my $epubFileName = basename $epubFilePath;

###################チェック用一時epubファイルのパスを取得###################

my $epubpackage = Archive::Zip->new();

die unless $epubpackage->read($epubFilePath) == Archive::Zip::AZ_OK;

#パスリスト変数の定義

my @xhtmlfilePaths;

my @files = $epubpackage->members();

foreach my $file (@files) {

push(@xhtmlfilePaths,$file->fileName) if ($file->fileName =~ /^(.*?)\.xhtml$/);

}

###################チェック用一時ファイル解凍処理###################

my $uniqueFolderPath = ‘/tmp/’ . $epubFileName;

#同一フォルダが存在したら連番をつける処理

my $mynum = 1;

if (-d $uniqueFolderPath){

while (-d $uniqueFolderPath){

$uniqueFolderPath = (‘/tmp/’ . $epubFileName . ‘_’ . $mynum);

$mynum++;

}

}

#解凍実行

my $epubArchive = Archive::Extract->new(archive => $epubFilePath,type => ‘zip’) or die;

$epubArchive->extract(to => $uniqueFolderPath);

###################文字チェック処理###################

#ログ出力用変数定義

our $finalSarrogatePairOutputLog = “”;

our $finalIVSOutputLog = “”;

our $finalIrregularSpaceOutputLog = “”;

#各xhtmlファイルを展開

foreach $myXhtmlfilePath (@xhtmlfilePaths){

&eachFileProceed($myXhtmlfilePath);

}

###################ログにタイトル部分を合成###################

if ($finalSarrogatePairOutputLog eq “”){

$finalSarrogatePairOutputLog = ‘##SarrogatePair Character Check Result : ‘ . “\r\n” . ‘OK! Not Any SarrogatePair Characters in EPUB File!’;

} else {

$finalSarrogatePairOutputLog = ‘##SarrogatePair Character Check Result : ‘ . “\r\n” . $finalSarrogatePairOutputLog;

}

if ($finalIVSOutputLog eq “”){

$finalIVSOutputLog = ‘##Unicode IVS Character Check Result : ‘ . “\r\n” . ‘OK! Not Any Unicode IVS Characters in EPUB File!’;

} else {

$finalIVSOutputLog = ‘##Unicode IVS Character Check Result : ‘ . “\r\n” . $finalIVSOutputLog;

}

if ($finalIrregularSpaceOutputLog eq “”){

$finalIrregularSpaceOutputLog = ‘##Irregular Space Character Check Result : ‘ . “\r\n” . ‘OK! Not Any Irregular Space Characters in EPUB File!’;

} else {

$finalIrregularSpaceOutputLog = ‘##Irregular Space Character Check Result : ‘ . “\r\n” . $finalIrregularSpaceOutputLog;

}

###################チェック用一時ファイルの削除###################

rmtree($uniqueFolderPath);

###################ログ出力###################

my $logOutputPath = (dirname $epubFilePath) . ‘/EpubTotalDataCheck.log’;

$logOutputPath = encode(‘UTF-8’, $logOutputPath);

open(OUT,”>> $logOutputPath”);

#チェックしたepubファイル名を出力

my $finalFilename = ‘####Checked FileName : ‘ . “\r\n” . $epubFileName;

$finalFilename = encode(‘UTF-8’, $finalFilename);

print OUT $finalFilename . “\r\n\r\n”;

#サロゲートペア文字の有無を出力

$finalSarrogatePairOutputLog = encode(‘UTF-8’, $finalSarrogatePairOutputLog);

print OUT $finalSarrogatePairOutputLog . “\r\n\r\n”;

#Unicode IVS文字の有無を出力

$finalIVSOutputLog = encode(‘UTF-8’, $finalIVSOutputLog);

print OUT $finalIVSOutputLog . “\r\n\r\n”;

#特殊スペース文字の有無を出力

$finalIrregularSpaceOutputLog = encode(‘UTF-8’, $finalIrregularSpaceOutputLog);

print OUT $finalIrregularSpaceOutputLog . “\r\n\r\n”;

close (OUT);

exit;

###################サブルーチン###################

#各xhtmlファイルのチェック

sub eachFileProceed {

my $myXhtmlfilePath = $_[0];

#各xhtmlファイル名を取得

our $xhtmlFileName = basename $myXhtmlfilePath;

my $eachFilePath = ($uniqueFolderPath . “/” . $myXhtmlfilePath);

open(IN,”$eachFilePath”);

#改行コードの統一処理

@myCHECKFILEtxts = ;

$myCHECKFILEtxts = join(“”,@myCHECKFILEtxts);

$myCHECKFILEtxts =~ s@\x0D\x0A@\x0D@g;

$myCHECKFILEtxts =~ s@\x0A@\x0D@g;

$myCHECKFILEtxts = decode(‘UTF-8’, $myCHECKFILEtxts);

@eachLine = split(“\x0D”,$myCHECKFILEtxts);

close (IN);

our $lineNumCount = 1;

#各ファイル内各行にIVS/サロゲートペア文字が含まれているかどうかのチェック

foreach $myLine (@eachLine){

&eachLineProceed($myLine);

$lineNumCount++;

}

}

#各xhtmlファイル内各行のチェック

sub eachLineProceed {

my $myLine = $_[0];

###サロゲートペア文字参照のチェック、ログに追記###

#16進数

while($myLine =~ /&\#x2[0-9A-Z]{4};/ig) {

$matchPlace = pos($myLine);

$finalSarrogatePairOutputLog = ($finalSarrogatePairOutputLog . ‘Caution! SarrogatePairCharacterRefernce at ‘ . ‘ ‘ . ‘FileName:’ . $xhtmlFileName . ‘ ‘ . ‘Line:’ . $lineNumCount . ‘ ‘ . ‘Character:’ . $matchPlace . “\n”)

}

#10進数

while($myLine =~ /&\#(1[0-9]{5});/ig) {

$matchPlace = pos($myLine);

if ($1 >= 131072 && $1 <= 196607) {

$finalSarrogatePairOutputLog = ($finalSarrogatePairOutputLog . ‘Caution! SarrogatePairCharacterRefernce at ‘ . ‘ ‘ . ‘FileName:’ . $xhtmlFileName . ‘ ‘ . ‘Line:’ . $lineNumCount . ‘ ‘ . ‘Character:’ . $matchPlace . “\n”)

}

}

###IVS文字参照のチェック###

#16進数

while($myLine =~ /&\#xE[0-9A-Z]{4};/ig) {

$matchPlace = pos($myLine);

$finalIVSOutputLog = ($finalIVSOutputLog . ‘Caution! UnicodeIVSCharacterRefernce at ‘ . ‘ ‘ . ‘FileName:’ . $xhtmlFileName . ‘ ‘ . ‘Line:’ . $lineNumCount . ‘ ‘ . ‘Character:’ . $matchPlace . “\n”)

}

#10進数

while($myLine =~ /&\#(9[0-9]{5});/ig) {

$matchPlace = pos($myLine);

if ($1 >= 917504 && $1 <= 983039) {

$finalIVSOutputLog = ($finalIVSOutputLog . ‘Caution! UnicodeIVSCharacterRefernce at ‘ . ‘ ‘ . ‘FileName:’ . $xhtmlFileName . ‘ ‘ . ‘Line:’ . $lineNumCount . ‘ ‘ . ‘Character:’ . $matchPlace . “\n”)

}

}

###特殊スペース文字のチェック###

#16進数

while($myLine =~ /&\#x(200[456789ACD]);/ig) {

$matchPlace = pos($myLine);

$finalIrregularSpaceOutputLog = ($finalIrregularSpaceOutputLog . ‘Caution! IrregularSpaceCharactorRefernce at ‘ . ‘ ‘ . ‘FileName:’ . $xhtmlFileName . ‘ ‘ . ‘Line:’ . $lineNumCount . ‘ ‘ . ‘Character:’ . $matchPlace . “\n”)

}

#10進数

while($myLine =~ /&\#(819[6789]|820[01245]);/ig) {

$matchPlace = pos($myLine);

$finalIrregularSpaceOutputLog = ($finalIrregularSpaceOutputLog . ‘Caution! IrregularSpaceCharactorRefernce at ‘ . ‘ ‘ . ‘FileName:’ . $xhtmlFileName . ‘ ‘ . ‘Line:’ . $lineNumCount . ‘ ‘ . ‘Character:’ . $matchPlace . “\n”)

}

#キャラクタごとの処理へ

my @eachchara = split(//,$myLine);

our $CharaNumCount = 1;

foreach $mychara(@eachchara){

&eachCharaProceed($myChara);

$CharaNumCount++;

}

}

#各xhtmlファイル内各行内各キャラクタのチェック

sub eachCharaProceed {

my $myChara = $_[0];

###サロゲートペア文字のチェック###

#サロゲートペア文字の場所をチェック、ログに追記

if ($mychara =~ /[\x{20000}-\x{2FFFF}]/){

$finalSarrogatePairOutputLog = ($finalSarrogatePairOutputLog . ‘Caution! SarrogatePairCharacter at ‘ . ‘ ‘ . ‘FileName:’ . $xhtmlFileName . ‘ ‘ . ‘Line:’ . $lineNumCount . ‘ ‘ . ‘Character:’ . $CharaNumCount . “\n”)

}

###IVS文字のチェック###

#Unicode IVS文字の場所をチェック、ログに追記

if ($mychara =~ /[\x{E0000}-\x{EFFFF}]/){

$finalIVSOutputLog = ($finalIVSOutputLog . ‘Caution! UnicodeIVSCharacter at ‘ . ‘ ‘ . ‘FileName:’ . $xhtmlFileName . ‘ ‘ . ‘Line:’ . $lineNumCount . ‘ ‘ . ‘Character:’ . $CharaNumCount . “\n”)

}

###特殊スペース文字のチェック###

#4分スペースなどの特殊スペース文字が含まれているかどうかのチェック

if ($mychara =~ /[\x{2004}-\x{200A}\x{200C}-\x{200D}]/){

$finalIrregularSpaceOutputLog = ($finalIrregularSpaceOutputLog . ‘Caution! IrregularSpaceCharactor at ‘ . ‘ ‘ . ‘FileName:’ . $xhtmlFileName . ‘ ‘ . ‘Line:’ . $lineNumCount . ‘ ‘ . ‘Character:’ . $CharaNumCount . “\n”)

}

}

 なお、Mac用にはEPUBCheck 3.0を組み込み、同時にログ出力できるようにしたドロップレットを作ってみました。Mac OS X 10.6/10.7/10.8で動作を確認しています。Mac OS X 10.5でも動作自体はしたのですが、Perlの呼び出しでエラーが出ました。Perlのアップデートが必要になると思われます。

実行ログ

実行ログ

 Mac版ドロップレットはIVS/サロゲートペア文字のチェックとEPUBCheckを連続実行しますので、多数のepubファイルをまとめてチェックすると多少の時間がかかります。チェック結果は、epubファイルと同じ場所に出力される「EpubTotalDataCheck.log」で一括確認できます。既に同名のファイルが存在していた場合は末尾に追記します。

チェック完了時にアラートを表示

チェック完了時にアラートを表示

 また、全てのファイルのチェックが完了するとアラートを表示します。バックグラウンドでチェックさせておいても安心です。
 なお、こちらのスクリプトを使用したことにより生じた損害等につきましては、一切責任を負いかねますので、あくまで自己責任にてご使用ください。

 ドロップレットのダウンロードはこちらからどうぞ。

>>EPUB3トータルデータチェッカー1.4.1(Mac用アプリ) ダウンロードはこちら
>>EPUB内特殊文字チェックスクリプト&バッチファイル(Win用) ダウンロードはこちら

 なお、Windowsでは、事前にActiveperl等のperl環境のインストールが必要です。

(2013.5.07)

ご要望をいただき、ログファイルにチェックした日付・時刻を出力する機能を追加いたしました。

(2013.5.09追記)

「電書ちゃんねる」に、epubcheckに関する記事が掲載されたようです。「エラーメッセージ一覧日本語訳」はとても参考になるありがたい資料ですのでぜひ参照することをおすすめします。

(2013.5.23追記)

数値文字参照形式でドキュメント内に挿入されたIVS/サロゲートペア文字、特殊幅スペース文字のチェックに対応させる形でソースコードを修正しました。また、Mac用アプリにつきましては「EPUB3トータルデータチェッカー1.1」にてEpubCheck3.0.1にも対応させました。

(2013.5.29追記)

特殊幅スペース文字として「|」(U+007C)が検出されていた問題を修正しました。ダウンロードコンテンツも同様に修正済みです。

(2013.6.04追記)

EPUB3ビューアのIVS・サロゲートペア対応状況in2013年4月

2013/04/15

 前回のエントリで予告させていただいたように、各EPUB3ビューアのUnicode IVSサロゲートペア文字※1対応の最新状況をチェックしてみました。外部からのEPUB3の取り込みをサポートしていないビューアもありますので完全とはいきませんが、ある程度の参考にはなるのではないかと思います。なお、チェックしたのはこのあたりを参考にしてサロゲートペア303文字、前回のmonokanoさん、NAOIさんの資料を参考にしたIVS文字127文字(Windows8でIVS対応した文字)です。IVS文字、サロゲートペア文字ともにこのテストの文字が全てではありませんので、あらかじめご了承ください。

 各ビューアの画面スクリーンショットを収めたPDF資料をダウンロードできるようにしておきましたので、適宜ご参照いただきながらお読みいただければと思います。また、テストに使用したepubデータも同じくダウンロードできるようにしましたので、お手持ちの端末等で自由にお試しください。
 IVS文字の表示にはビューアだけではなく、フォントの側の対応も必要となりますので、今回のテストでは各ビューア内で選択可能なフォントにそれぞれ切り替え、スクリーンショットを撮っています。添付資料内のフォント名表記は各ビューア内の表記に従いました。

 また、これはあらかじめお断りしておきたいのですが、IVSやサロゲートペアで表すような文字は、一部の学術系書籍および人名漢字以外ではほとんどニーズのないような文字が大半を占めます。従って、これらの文字の現時点での正確な表示をもって各ビューアの品質の絶対評価をしようとは思っておりません。ただ、前回のエントリで述べたように、Windows8のIVS対応によってテキスト内にIVS文字が混入する可能性を否定できなくなりましたので、「IVS文字を適切に無視して親字のみを表示する」実装は期待したく思っています。また、サロゲートペア文字に関しましては、「吉」(20BB7)※2のように、ATOK等の日本語入力システムで無意識に入力可能な文字も存在していますので、少なくともこういった比較的使用頻度の高い文字に関しましては、主要ビューアでの早い段階での表示対応を望みたいと思っています。

Adobe Digital Editions 2.0

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:正しく字形を表示

 Adobeの汎用EPUBビューア、Adobe Digital Editions 2.0です。
 Mac版でサロゲートペア文字の「U+29FCE」(29FCE)が表示出来ていないこと、Windows版でIVS文字の「煕」(242EE E0101)が化けていることを除けば、かなり理想的な対応状況です。「煕」はサロゲートペア文字+IVS異体字の組み合わせですので、化けている理由はそのあたりかもしれません。IVS文字で異体字が表示されず、親字が表示されているものもありますが(6FF9 E0101など)、Unicode IVSで本来求められる「最低限親字を表示し、IVS文字を適切に無視する」という実装になっており、高く評価できます。化けている文字はおそらくフォント側に字形が収録されていないものと思われますので、ビューア側の実装としてはまず合格と言って良いように思います。

iBooks3.1

IVS文字対応 サロゲートペア文字対応
○:親字の字形を表示(iOS6) ◎:正しく字形を表示(iOS6)

 iPad、iPhoneなどのiOS端末で使用できるAppleのEPUB/PDFビューア、iBooksです。
 iOS6.1.3ではおおむねIVS文字は親字が表示されてIVS文字は無視され、サロゲートペア文字は縦横ともにきちんと表示されるというかなり評価できる状態です。フォントに游ゴシック体を選択した場合のみ「丈」(2000B)などいくつかの文字が化けますが、これはフォントに字形が収録されていないためでしょう。
 ただiOS5.1.1の環境ですと、サロゲートペア文字が縦書き時にほとんど表示できず、かろうじて表示できている文字も化けているというような状態になりました。IVS文字も「□」で表示されてしまっています。かなりつらい状態ですが、古い環境ではあり、まあ致し方ないところかと思います。

Himawari Reader Ver3.3.0

IVS文字対応 サロゲートペア文字対応
△:IPAex明朝/ゴシックでは異体字字形を「□」で表示 ○:IPAex明朝/ゴシックでは正しく字形を表示

 Android環境で広く使われている汎用EPUBビューア、Himawari Readerです。
 作者の中野さんより、Himawari Readerは.TTFフォントは全て表示可能だが、公式にはライセンスに従ってIPAex明朝およびIPAexゴシックをオプションアプリ形式で配布している、とのコメントをいただきましたので、今回は「標準フォントセット」およびオプション配布の「IPAex明朝」、「IPAexゴシック」についてテストをしました。
 テスト結果はかなり面白いもので、「標準フォントセット」ではIVS文字がきちんと異体字字形で表示されるもののサロゲートペア文字は全く表示されず、「IPAex明朝」/「IPAexゴシック」ではIVS文字は「□」で表示されてしまうもののサロゲートペア文字はきちんと表示されました。

Kindle PaperWhite ファームウェア5.3.4

IVS文字対応 サロゲートペア文字対応
△:IVS文字を「□」で表示 ◎:ほぼ全ての字形を正しく表示

 Amazonの電子ペーパー端末、Kindle PaperWhiteです。
 なお、kindleに関しましては、epubファイルをkindlegen2.8にてmobiデータに変換し、テストしております。
 IVS文字は全て「□」で表示され、サロゲートペア文字は「艾」(26AFF)および「U+237FF」(237FF)以外はきちんと表示されています。この2文字につきましては、おそらくフォント側に字形がないために表示できていないものと思われます。

Kindle for Android 3.8.2

IVS文字対応 サロゲートペア文字対応
△:IVS文字を「□」で表示 ◎:ほぼ全ての字形を正しく表示

 KindleのAndroid版アプリ、Kindle for Androidです。
 Kindle PaperWhiteとほぼ同様の結果ですが、こちらは「艾」と「U+237FF」を正しく表示できています。おそらくフォントの違いによるものと思われます。

Kinoppy for Android Ver 1.4.2

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:ほぼ全ての字形を正しく表示

 紀伊国屋書店の電子書籍ビューア、KinoppyのAndroid版アプリ、Kinoppy for Androidです。
 IVS文字が異体字字形で表示され、サロゲートペア文字も「丈」(2000B)が消えてしまう以外はきちんと表示出来ています。フォントを「IPAexゴシック」に切り替えた場合のみIVS文字の「齬」(2A61A)が化けるのですが、これはフォントに収録されている字形数の差によるものと思います。

Kinoppy for iOS Ver 1.4.2

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:ほぼ全ての字形を正しく表示

 KinoppyのMac版アプリ、Kinoppy for iOSです。
 Android版アプリと同様にかなり理想に近い対応ですが、サロゲートペア文字の「丈」が消えてしまう以外に、縦書き時に「U+200A2」(200A2)や「U+200A4」(200A4)が横転表示されてしまいました。使用頻度の高い文字はほぼ無いのですが、該当する文字を使用する場合にはCSSで正立を指示する必要がありそうです。

Kinoppy for Windows Ver 1.4.2

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:ほぼ全ての字形を正しく表示

 KinoppyのWindows版アプリです。
 iOS版とほぼ同じ状態です。レンダリングエンジンが同一であることが推測できます。

Kinoppy for Mac Ver 1.4.3

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:全ての字形を正しく表示

 KinoppyのMac版アプリです。
 サロゲートペア文字の「丈」がきちんと表示され、さらに横転してしまっていた文字も正立しています。Mac版のみバージョンが1.4.3ですので、レンダリングエンジンのバージョンアップの結果、きちんと表示出来るようになったと見てよいかもしれません。だとすれば、近い将来iOS版やWindows版のKinoppyでも正常な表示が期待できそうです。

 紀伊國屋書店は今後、学術書・専門書に注力していくのではないかというイメージがありますし、そういった分野ではIVS/サロゲートペア文字の表示に関して実際にニーズがあるでしょう。Amazon等に対する差別化のポイントとしても有効なのではないかと思います。

Kobo Touch ファームウェア2.4.0

IVS文字対応 サロゲートペア文字対応
×:通常の文字まで表示されなくなる ×:通常の文字まで表示されなくなる

 楽天Koboの電子ペーパー端末、Kobo Touchです。
 こちらは組版の確かさには比較的信頼感のある端末だったのですが、IVS/サロゲートペア文字の表示に関しては、各行のIVS/サロゲートペア文字の後ろの文字列がごっそり消えてしまうという結果になりました。これはEPUB3コンテンツにこれらの文字が混入していた場合、完全に可読性が損なわれる「事故」になってしまうことを意味します。Kobo向けコンテンツの制作では、IVS/サロゲートペア文字がコンテンツ内に含まれていないかをきっちりチェックし、外字画像にするなどの対応を取る必要がありそうです。

楽天Kobo Android版 バージョン4.8

IVS文字対応 サロゲートペア文字対応
△:IVS文字を「□」で表示 ◎:全ての字形を正しく表示

 楽天KoboのAndroid版アプリ、楽天Kobo Android版です。
 こちらはIVS文字は「□」で化けて表示され、サロゲートペア文字は正常に表示されるという標準的な結果が出ています。IVS文字は化けてしまいますが、可読性を致命的に損なうわけではありませんので大きな問題にはならないでしょう。
 ただ、koboに限らず「購入した書籍をどの端末でも読むことができる」のが今の多くの電子書籍ストアの売りですので、「kobo touchではきちんと読めないコンテンツがある」時点でストアの魅力を多少なりともスポイルするのは間違いありません。早い段階でのKobo Touchのファームウェア修正を期待します。

Murasaki バージョン2.1

IVS文字対応 サロゲートペア文字対応
△:IVS文字を「□」で表示 △:縦書き時に内容を表示出来ず

 Macで比較的良く使われていると思われる汎用EPUBビューア、Murasakiです。
 こちらはIVS文字が「□」で化けて表示され、サロゲートペア文字を含む縦書きのファイルを表示しようとするとアプリがフリーズしてしまうという結果が出ました。おそらくwebkitのサロゲートペア文字対応の問題に引きずられているものと思うのですが、詳しいことはわかりません。個人的にMurasakiはEPUB制作時のチェック用として多用しているビューアですので、早い段階で修正されることを望みたいです。

Readium Version 0.9(Mac)

IVS文字対応 サロゲートペア文字対応
○:異体字字形まで表示(ただし横転) ×:全て文字化け

 ウェブブラウザ、Google Chrome内で使用できる汎用EPUBビューア、ReadiumをMac版Chrome内で動かした場合です。
 サロゲートペア文字が縦書き時にほとんど化けてしまい、表示できません。また、表示出来ている文字も本来のコード位置とは異なる字形が表示されてしまっています。
 IVS文字に関してはほぼ全ての文字が異体字字形で表示されているのですが、文字が全て横転して表示されてしまっています。また、「煕」(242EE E0101)のみが縦書き時に化けてしまい、横書き時にもIVS文字の部分が化けて表示されてしまっているのですが、これは前述したように「煕」がサロゲートペア文字+IVS文字の組み合わせなことに関係がありそうです。

Readium Version 0.9(Windows)

IVS文字対応 サロゲートペア文字対応
△:IVS文字を「□」で表示、横転 △:縦書き時に直前の文字が消える

 ウェブブラウザ、Google Chrome内で使用できる汎用EPUBビューア、ReadiumをWindows版Chrome内で動かした場合です。
 IVS文字は「□」に化けてしまう他、縦書き時に横転して表示されてしまっています。また、サロゲートペア文字は横書きではきちんと表示されるものの、縦書き時には直前の始めカギ括弧が消えてしまっています。

 Readiumは本来、校正用のビューアとして本命視されていただけに、現在のこの状態は残念です。Readiumプロジェクトは先日、非営利電子書籍規格ライセンス団体「Readiumファウンデーション」として法人化とのニュースがありましたので、今後IVS/サロゲートペア文字の表示を含めてレンダリングエンジンの改善を期待したく思っています。

Reader(Android版)バージョン3.1.2

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:正しく字形を表示

 SONYの電子書籍ストア、ReaderのAndroid版アプリです。
 IVS文字、サロゲートペア文字ともに、テストに使用した文字に関してはほぼ完全な対応でした。ReaderのレンダリングエンジンはベースがAdobeのRMSDKですので、異体字表示対応の優秀さはこれによる部分も大きそうなのですが、Adobe Digital Editions 2.0で文字化けしていた「U+29FCE」(29FCE)もきちんと表示出来ていますので、ある程度独自のカスタマイズがなされているように思われます。

 いかがだったでしょうか? 最初に書いたように、こうした異体字の表示については人名漢字と一部の学術書以外ではほとんどニーズはないように思いますが、各ビューアのレンダリング実装の進捗度が想像できて、個人的にはなかなか楽しい実験でした。

 前回のエントリで書いたように、Windows8が単体でIVS文字の入力に対応した以上は、今後電子書籍制作用の原稿にIVS文字が含まれている可能性をEPUB制作者も想定しなければなりません
 また、サロゲートペア領域の文字の中には、ATOK等で特に意識せずに入力可能な文字がすでに存在しています。

 これらの文字の混入によってコンテンツの可読性が完全に損なわれる「事故」を誘発してしまうことはなんとしても避ける必要があります。今後、制作サイドにはEPUB内のこうした特殊文字を検知し、排除するスキルが必要になるでしょう。また、ビューア開発サイドの方には、「例え特殊文字が含まれていたとしても事故にならない実装」を求めたく思っています。

※1 EPUB3内部で用いられているコードはUTF-8であるため、正確には「サロゲートペア」という用語は不正確で、正確には「追加漢字面(Supplementary Ideographic Plane; SIP)」と表記するのが正しいと思いますが、実際のEPUB3データのハンドリングとしてはビューアでEPUBを展開する際にUTF-16などに展開され、その際の処理で追加漢字面の文字化けが起きると推測されるため、ここではわかりやすさを重視して「サロゲートペア文字」と表記しています。
※2 JISX 0208及びJISX 0213では「吉」に包摂されているため独立した字形として収録されていないが、UnicodeのCJK統合漢字拡張Bには独立した字形が存在するため、実際には入力が可能。

 

資料のダウンロードはこちら
各EPUB3ビューアのIVS・サロゲートペア対応状況(2013年4月17日時点) (899)
IVS/サロゲートペア表示テスト用epubファイル (830)

(2013.4.18)

ご指摘をいただき、技術的な用語を若干修正いたしました。また、Himawari Readerの中野さまより、「Himawari Reader自体は.TTFファイルなら何でもOKで、公式にはライセンスに従ってIPAフォントをオプションアプリ形式で配布している形になる」とのコメントをいただきましたので、表記を修正させていただきました。

(2013.4.18追記)

Android端末の機種によってもフォント表示結果が変わってくるとのご指摘をいただきましたので、機種名を追記しておきます。「Nexus7 Android OS 4.2.2」です。また、Mac環境は「Mac OS X 10.7 Lion」、Windows環境は「Windows7」にてテストしました。

(2013.4.19追記)

印刷データ→電子書籍で外字化が必要な文字のまとめ

2012/05/10

 以前のエントリーでDTPデータ内で使われているOpentypeグリフ字形(Adobe1-6)の一部が、電子書籍では外字画像にしないと表現できない問題について書かせていただきました。出版デジタル機構(pubridge)もいよいよ動き始め、実際に電子書籍を作るための環境づくりに入っている方も多いかと思いますので、印刷用DTPデータ→電子書籍で字形が変わってしまう文字についての現時点でのまとめをあらためて掲載しておきたく思います。電子書籍制作環境づくりのお役に立てていただければ幸いです。なお、検証に使用した環境はMac OS 10.7/InDesign CS5です。InDesign以外のアプリケーションでもAdobe1-6グリフ字形を呼び出せるインターフェースを持ったものであれば同様の字形変化が起きるものと思われます。

確実に外字化が必要になると思われる文字

CID/GID番号のみしか割り当てられていない文字

CID/GIDのみの文字(一部)

CID/GIDのみの文字(一部)

 UNICODE/Shift_JISの双方に文字コードの割り当てがなく、InDesignなど対応アプリケーション内部からのみ呼び出すことができる文字です。囲み数字や丸数字などを中心に、ざっと数えた限りでは約700文字あるようです。これはそもそもUNICODEにもコード割り当てがない文字のため、確実に外字にする必要があります。InDesign内でこれらの文字を選択し、テキストエディタ等にコピー&ペーストすると「1A」という文字に化けます。

合字

任意の合字(一部)

任意の合字(一部)

 複数の文字コードで構成された文字をInDesign等の対応アプリ内でOpenTypeの機能を呼び出して「合字」として表示している文字です。InDesign字形パレットの分類では、「任意の合字(dlig)」「分数(afrc)」「欧文合字(liga)」などがこれにあたります。InDesign内でこれらの文字を選択し、テキストエディタ等にコピー&ペーストすると、内包している複数の文字に展開されて表示されます。

現時点では外字化した方が無難と思われる文字

サロゲートペア領域の文字

サロゲートペア領域の文字(一部)

サロゲートペア領域の文字(一部)

 InDesignの字形パレットの表示でUnicodeのコード番号の表示が「2xxxx」と、先頭に2の付いた5桁になっている文字群です。調べた限りでは303文字あります(参照)。ATOKの文字パレットでは、「CJK統合漢字拡張B」「CJK互換漢字補助」となっています。内部的に2つの文字コードの組み合わせで1つの字形を表示しており(サロゲートペア)、多くのリーディングシステムでは問題なく表示されますが、未対応のリーディングシステムが存在するため現時点では外字化した方が無難と思われます。JIS第3水準・JIS第4水準の文字の他、JIS割り当てのない文字も多数含まれています。使用頻度の高い文字はほとんどありませんが、U+20B9Fの「叱」(印刷標準字体)や、U+20BB7の「吉」(つちよし)などは問題になるかもしれません。全てUnicodeのみに割り当てがある文字のため、ドットブック/XMDFなどではいずれにせよ外字化が必要になりそうです。「EPUB日本語基準研究グループ」のホームページから参照できる、「EPUB3日本語ベーシック基準v1.0」の28ページにこれに関しての記述があります。

外字にするかどうか出版社サイドの判断が必要になる文字

同じ文字コードに2つ以上の字形バリエーションが割り当てられている文字

旧字体(一部)

旧字体(一部)

 旧字体/エキスパート字形/すべての異体字/修飾字形 など、ひとつの文字コードに複数の字形が割り当てられ、InDesignなど対応アプリケーション内部から字形パレット等で呼び出していた文字です。これらに関しては以前のエントリーで詳しく書きましたのでそちらを参照していただければ幸いです。人名・地名等の固有名詞以外では問題になりにくいとは思いますが、一般に字形差がとても微細なため、目で追って確認するのが難しい文字群です。

フォントのバージョンによって字形の変わる可能性がある文字

JIS90字形の文字(一部)

JIS90字形の文字(一部)

 以前のエントリーでも少し触れましたが、Pr6/Pr5などJIS90字形を基準としたフォントを用いて作られたDTPデータを元データとして電子書籍を制作する場合に、JIS規格の例示字形の変化の影響で字形の変わる可能性のある文字が168文字あります(フォントによって変化に差があるようです)。こちらにも字形差が微細なため、目で追って確認するのが難しいものが多く含まれます。一点しんにょう→二点しんにょうへの例示字形変更なども行われたため、人名漢字などで問題になるパターンが多くありそうです。JIS90→JIS2004の例示字形変化について、詳しくはこちらをご参照ください。

ドットブック/XMDFなどで外字化が必要になる可能性のある文字

Shift_JISに割り当てがなく、UNICODEのみで使える文字

Unicodeのみの文字例(色つきのもの)

Unicodeのみの文字例(色つきのもの)

 文字コードがShift_JISのドットブック、Unicodeが仕様上は使えるものの、おそらく既存のリーディングシステムの互換性の問題でShift_JISが使われることが多いと思われるXMDFで外字化が必要になりそうな文字群です(HTMLのように数値文字参照等で表記できるのでしょうか?手元の資料ではちょっとわかりませんでした)。XMDFビルダーではピンク色で表示され、XMDFビルダー内簡易ビューアではゲタ記号に化けて表示されるようです。EPUB3は文字コードがUnicode(UTF-8)のため、外字化しないでそのまま表示できます。

 このほか、「インライン画像として文字を作り、テキスト内に挿入していた文字」や、「外字の表示用に独自OpenTypeフォントを制作して表示していた文字」、「Biblosなどの市販外字フォントを利用していた文字」など、各ドキュメントごとに対応が必要になる場合も当然ありますが、これらは個々に対応するしかないと思われるため詳しくは書きません。以前フォントメーカーの営業の方にお聞きした話では、望ましい字形をDTPアプリケーションソフト内での操作なしで表示するために、フォントメーカーにカスタムフォントを特注して使用している印刷会社もあるとのことです。このような場合、その印刷会社以外の会社でDTPデータから電子書籍化する場合に、全ての文字を目で追って確認する必要が出てくるため校正費用がとても高くつくことが予想できます。可能であれば元DTPデータを制作した会社での電子書籍化が望まれるところです。

 また、出版デジタル機構および緊デジ関係者の方への要望として、特に上述の「基本字形に変化してしまう字形」および「フォントのバージョンによって字形の変わる文字」に関して、どのレベルまでを必ず外字にしなければならないのか(人名・地名のみ外字化するのか、初稿で外字化する文字を確認して指示していただけるのか、あるいは全て外字にするのか)、外字対応のガイドラインを策定し、出版社/制作会社の双方に告知していただきたく思います。

(2012.5.11)

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。

最近のコメント