‘外字’ タグのついている投稿

EPUBの外字画像の使用事例について

2016/11/10

 JEPAの村田真さんよりEPUB Accessibility 1.0絡みで現状のEPUBでの「外字画像」の使用事例を知りたいとのお話をいただきましたので、私の知る限りで書いてみます。何人かの方にもお話をお聞きし、参考とさせていただきました。

 どういった種類の外字かをわかりやすくするために、各種文字集合規格のマップを作成し、各外字がどこに位置するかを以下に図示しました。解説の番号に対応しています。併せてご参照ください。

外字の分布

画像内で使用している文字関連の専門用語をまとめて記述しておきます。

  • Unicode:1991年にバージョン1.0が出版された国際的な符号化文字集合の規格。世界中の文字を単一の文字集合で表記することを目的としている。2016年6月にUnicode9.0が出版されている。詳しくはこちら
  • JIS X 0208:1978年に最初に制定された日本の符号化文字集合の規格。改訂年度によって「JIS78」「JIS83」「JIS90」などと呼称される。JIS第2水準までの漢字をサポートしている。詳しくはこちら。これとセットで運用された符号化方式がShift_JIS
  • JIS X 0213:2000年に最初に制定された日本の符号化文字集合の規格。改訂年度によって「JIS2000」「JIS2004」などと呼称される。最新版は「JIS2013」。JIS第4水準までの漢字をサポートしている。詳しくはこちら
  • Adobe-Japan1-6:アドビシステムズ社によって制定された符号化文字集合の規格。商用日本語OpenTypeフォントの採用している文字集合規格のデファクトスタンダードである。実際に販売されているフォントのうち、「Pr6」「Pr6N」という名前が付いているものがこの規格のもの。「N」はデフォルトの字形をJIS2004の例示字形に対応させたものを指す。内包する文字数の異なる下位規格としてAdobe-Japan1-5(Pr5/Pr5N)、Adobe-Japan1-4(Pro/ProN)、Adobe-Japan1-3(Std/StdN)などがある。詳しくはこちら
  • Unicode IVS:異体字セレクタ。親文字(漢字)と、Unicodeの第14面(追加特殊用途面)に収録された異体字表示文字を組み合わせることで、漢字の微細な字形差を表現できるようにするためのもの。これにより例えばAdobe-Japan1-6の包含している字形の再現が電子書籍やWebで期待できるようになる。詳しくはこちら
  • 基本多言語面:Unicodeの0面。もともとはここに全ての文字を収録する計画だったが、足りなくなったために桁(面)を増やした経緯がある。詳しくはこちら
  • 追加漢字面:Unicodeの2面。CJK統合漢字拡張や補助漢字などの文字が収録されている。詳しくはこちら

特定の文字集合規格で表現できない文字を「外字画像」にしているもの

❶ Adobe-Japan1-6にしかない文字の外字化

Adobe-Japan1-6にしかない文字の例

Adobe-Japan1-6にしかない文字の例

 Adobe-Japan1-6の文字は、そのほとんどがCMapによってUnicodeと紐付けられていますが、ごく一部Adobe-Japan1-6にしか収録されておらず、Unicodeと紐付いていないために実質的にInDesign等のDTPアプリ内でしか使えない文字(参照:CID/GID番号のみしか割り当てられていない記号類)があります。これは外字画像にする以外の方策はありません。

(追記)事例画像には一部既にUnicode符号化済の文字を含んでいます。

❷ 中国語の人名など日本語フォントで現状表示できない字形を表示するための外字化

日本語と中国語のフォントで字形が違う例

日本語と中国語のフォントで字形が違う例

 簡体/繁体中国語の人名など、現状日本語フォントで表現できない字形を表現するために外字画像を使用しているケースです。これはUnicodeの符号位置としてはAdobe-Japan1-6内のものが多数含まれると思われますが、その場合でも日本語と中国語では符合位置が同じでも割り当てられている字形(グリフ)が微妙に違うことがあるため、外字画像にせざるを得ない場合があります。学術書などでは厳密な字形の再現が要求されるケースも当然出てくるため、そういったケースでは現状では外字画像にすることになります。

 将来的にEPUB内での部分言語指定を各RSがサポートし、デバイスが対応する各国語のフォントを搭載すればテキスト化できるかと思われます。

❸ Adobe-Japan1-6内の異体字の字形を保つための外字化

 InDesignなどのDTPアプリ内では使用できるものの、テキスト化するとGSUBの情報が消えてしまうために字形を維持できなくなる文字の字形を保持するために外字画像としているケースです。

 典型的なのはJIS90字形を保持するために外字画像としているケースです(参照:JIS90字形とJIS2004字形で変化する文字の一覧)。この問題は古くはJIS78→JIS83の字形変化の問題、いわゆる「新JIS旧JIS問題」にまで遡る話ですので、割に根は深いと思います。

段落スタイルで印刷標準字体を指定

段落スタイルで印刷標準字体を指定

 また、EPUBのビューアに搭載されているフォントは現状ほとんどがJIS2004字形の「Pr6N」などのフォントであるにも関わらず、JIS2004字形を外字化してしまっているケースもあるようです。おそらく元の印刷データでJIS90字形基準のフォント(Pro/Pr5/Pr6)が使用されており、InDesignなどDTPアプリの機能でJIS2004字形のグリフを割り当てていた(「印刷標準字体」を段落スタイルで割り当てるなど)ケースで電子化の際に字形の維持を図ったものと思われますが、これは明白に意味がないためやめた方がよいと思われます。

 将来的にUnicode IVSが標準的に使用できるようになれば微細な字形の再現はテキストで可能になるはずですが、まだIVSを付加した文字が縦組み時に横転してしまう実装のビューアがあったりするなどRS側の状況が不安定なこと、InDesignデータから字形情報を保持したままUnicode IVSのテキスト化することが技術的に難しいことなどから、厳密に字形を保持するには当分は外字画像化が必要になるでしょう。

 ただ、このあたりの文字はもともとがJISの「包摂」範囲で、本来は規格内に双方の字形を含んでおり、JIS2000からJIS2004では「例示字形」が変わっただけです。微細な字形差に留まるケースが大半ですので、人名などどうしてもやむを得ない場合以外はテキスト化を許容した方がよいと考えています。

 なお、このあたりの話は以前に私のブログで書いておりますので、併せてご参照ください。Unicode IVSに関してはこちら。WindowsやMacも既にOSレベルでのUnicode IVS対応は済んでいますので、あとはInDesignなどDTPアプリの対応待ちという印象です。

❹ JIS X 0213内だがUnicodeの基本多言語面外の文字の外字化

 JIS X 0213内の文字で、少数ですがUnicodeで基本多言語面(BMP)外のCJK統合漢字拡張Bのエリアに割り振られた漢字が存在します。特に注意が必要なのは「𠮟」(U+20B9F)および「𠮷」(U+20BB7)です。
 「𠮟」はJIS第3水準漢字ですが、類似の文字にJIS第1水準の「叱」(U+53F1)があるため、通常はこちらで代用可能でしょう。ただ、「𠮟」の方が常用漢字とされたため(参照)、厳密に常用漢字の使用を求めた結果、外字画像となっているケースはあるかも知れません。

 また「𠮷」は人名に用いられる漢字ですので、厳密な字形の再現が求められるケースはそれなりにありそうに思います。例えば元首相の「𠮷田茂」氏の「𠮷」がこの字形です。通称「ツチヨシ」と呼ばれる、割に一般的な人名の異体字です。

 基本多言語面(BMP)外の文字は、展開するために内部的に2つの符号位置を必要とする処理となる(サロゲートペア)ため、長く表示に問題のある状態が続いていました。具体的にはついこの間までWebkit系のエンジンを用いるRSで縦書き時に正常に文字が表示されないなどの問題がありましたので、現状市場に出ているEPUBにはこれを回避するための外字画像を含むものが多数あるものと思われます。

 2016年11月現在では、EPUBのサイドロードに対応しているメジャーどころのRSで正常に表示ができておりますのでほぼ問題は無くなったと考えていますが、サイドロード非対応のRSも数多く存在しますので、完全な確認は私も取れておりません。

❺ JIS X 0213外だがAdobe-Japan1-6内の文字の外字化

 そう数は多くありませんが、Adobe-Japan1-6には含まれるものの、JIS X 0213には含まれない文字が存在します。漢字では例えば「髙」(U+9AD9)がそれに当たります。通称「ハシゴダカ」と呼ばれるかなり一般的な人名の異体字です。この文字はJIS X 0213としては通常の「高」に包摂されると見なされたため、独自の符号位置を与えられませんでしたが、Unicodeでは日本以外からの要望によって収録され、結果的に使えるようになったために広く使われているという経緯があるようです。

 また、記号類が多く含まれ、例えば「㈠」「㈳」「㈪」「⑴」「⒜」などがあります。これらはかなり一般的に印刷物で使用されている文字です。特に縦書きの文章でよく見かけます。

 「髙」や「㈠」「㈳」「㈪」「⑴」「⒜」といったような文字に関しては、現状メジャーどころのほぼ全てのビューアで文字の表示が可能になっているようですので、現状そこまで神経質に外字画像にする必要はないと考えています。

 (追記)一部、日本語フォントとしてIPAフォントを採用しているRSがあり、IPAフォントにはJIS X 0213までのグリフしか収録されていないため、外字化せざるを得なくなるという話もあるようです。

❻ XMDF/.bookのデータを変換した影響での外字化

 過去に作られたXMDFや.bookをEPUBに変換したケースで、XMDFや.bookが符号化方式としてShift_JIS(文字集合はJIS X 0208)を用いていたために、使用できなかったJIS第3水準、第4水準の漢字が外字画像になっているケースがあります(正確にはXMDFはバージョン3でUnicodeに対応したが、ほとんど普及していない)。XMDF/.book由来以外にも、処理プログラムの一部にShift_JISベースのものを用いているケースで同様の事例はありそうです。

 文字としては既にテキスト化可能であっても、過去に制作して既に市場流通しているものに再度手を加えるには当然ながら相応のコストが見込まれますので、まだしばらくはこういったものも市場に残りそうです。

縦書き絡みの「外字画像」

❼ 縦書き時に3桁以上の英文字/4桁以上の数字を縦中横で挿入するための外字化

InDesignでは等幅4分字形が使える

InDesignでは等幅4分字形が使える

 現状、EPUBで縦中横指定で表示対応可能な英文字/数字の桁数はRSによって大きな差がありますが(参考:項目3-1)、各RSの最小公倍数としては英文字2桁、数字3桁が最大値で、それ以上は外字としないと横転表示されてしまうRSが出てしまいます。このため、3桁以上の英文字/4桁以上の数字の縦中横組版の再現のために外字としているケースがあります。

 通常例えば数字なら3桁あればほとんど組版の問題はなく、4桁の縦中横は相当なレアケースではありますが、Adobe-Japan1-6には等幅4分字形のグリフが収録されていたりもしますので、まったくのゼロではありません。そういったケースでは外字画像を利用することになります。

 将来的にRSが3桁以上の英文字/4桁以上の数字の縦中横表示をサポートすれば、テキストで表現することができるようになるでしょう。

❽ 化学式のようなものを縦中横で挿入するための外字化

 化学式のように上付き/下付き文字を含むものを縦中横で挿入するために外字画像としているケースがあります。「H2O」のように3桁以上になるケースも多くあるため、複合的な要因で外字化せざるを得ません。

 将来的にRSがこういったものの縦中横表示をサポートすれば、テキストで表現することができるようになるでしょう。

❾ 一部記号類の正立/横転指定にRSが対応していないための回避措置としての外字化

Kindleでは時計数字は必ず正立する

Kindleでは時計数字は必ず正立する

 一部記号類の正立/横転指定にRSが対応していないために縦書き時に外字にせざるを得ないケースがあります。一例としてはKindleでの時計数字(Ⅰ、Ⅱ、Ⅲ・・・)の挙動があります。Kindleでは時計数字は必ず縦書きで正立する文字として扱われ、明示的に横転の指定(text-orientation: sideways)を行っても正立してしまいます。このため、例えば欧文との混植を行って欧文内に時計数字を含めるようなケースでは、横転させて表示するために外字とせざるを得ません。こういった文字は時計数字以外にも複数あります。(参考:KADOKAWA-EPUB PORTALでダウンロードできる資料内の「20150123-文字の向き確認用【全頁版】.pdf」)

 EPUB/Webにおける縦書き時の文字の向きの挙動のデフォルト値については、UTR #50で一応の標準化がされ決着がついているのですが、まだRSレベルでの差異はあり、また(過去のドキュメントとの互換性を考えれば簡単に変えられないのは当然ですが)InDesignやWordのデフォルト値とUTR #50の間にも差があります(参考)。このため、当分ある程度RSの挙動に差異が残るのは仕方ない部分はあると考えています。

 ただ、デフォルト値はともかく明示的に横転を指定しても正立してしまう挙動はちょっと困ります。Kindleは他の記号類を見る限りtext-orientationの指定自体には対応しているので、一部の文字のみ指定が効かない挙動を早く修正して欲しいところです。

❿ Kindleが縦書き時に一部文字の字形を誤って置換表示してしまうため回避措置としての外字化

右:Kindle/左:iBooksの表示結果

右:Kindle/左:iBooksの表示結果

 Kindleで縦書き時にダブルクォート(「“」U+201C 「”」U+201D)をダブルミニュート(ノノカギ/「〝」U+301D 「〟」U+301F)に強制置換して表示する挙動があるため、回避措置として外字としているケースがあります。行頭字下げなどの挙動を見る限りでは、どうやら字形のみを置き換えて表示しているようです。

 縦書きでダブルクォートの代わりにダブルミニュートを用いるというのは組版のルールとしては間違っていませんが、あくまで制作者が判断して行うべき措置で、RSが勝手に強制置換をしてしまうのは困ります。例えば縦書きの文中に欧文をダブルクォートで包んで表示したいようなケースでは、ダブルクォートは欧文の一部なので横転したダブルクォートとして表示させたいのですが、Kindleはこれも強制的にダブルミニュートにしてしまいます。このため、外字画像にせざるを得なくなります。

 なお、二重引用符には他にU+0022の「"」があり、こちらは問題なく表示できます。外字とせずこちらを使用しているケースもあるでしょう。

文字を分離禁止にするための「外字画像」

⓫ 一部記号を分離禁止で表示させるための外字化

繰り返し記号の使用例

繰り返し記号の使用例

 二倍ダーシ(U+2014「—」/U+2015「―」/U+2500「─」)や連続する三点リーダー(U+2026「…」)などを改行による分離を禁止して表示させるために、あえて外字画像としているケースがあります。個人的にはこれはやや神経質すぎだと思っていますが、二倍ダーシなどについてはもともと活版印刷の時代には通常のダーシとは違う約物として存在していたなどという話もあるようですので、そういった影響がずっと尾を引いているのかも知れません。

 このほか、古い文献で多く見られる繰り返し記号にも2つの文字を組み合わせて用いる前提のものがあり(U+3033「〳」+ U+3035「〵」/U+3034「〴」+ U+3035「〵」)、これを確実に分離させずに表示させるために画像とするケースがあるようです。
 現状多くの出版社は一般的にはそこまで厳密な記号類の分離禁止を求めていないと思われますが、学術書などで厳密な組版の再現を求められるケースでは外字にせざるを得ないという判断はあり得るでしょう。

 これらはいずれCSSでの特定の文字の分離禁止指定がほぼ全てのRSで効くようになればテキストで表現できるものと思います。

RS側の組版再現が現状不完全なための「外字画像」

⓬ 合字の組版再現のための外字化

InDesignで使える合字の例

InDesignで使える合字の例

 現状、多くのRSではまだ、DTPアプリ内では合字(リガチャ)として表示できるものが分離して表示されてしまう挙動が見られます。このため、組版再現のために外字とせざるを得ないケースがあります。

 具体的には通常濁点や半濁点を付けないカナ文字にU+309Bの合成用濁点やU+309Cの合成用半濁点を付けて特殊な表現を行うケース(例:「あ゛あ゛あ゛あ゛あ゛」)や、英語以外の欧文でアクセント組み合わせ済みのグリフを持たない文字へアクセント類を付加したいケースが考えられます。

 これらのケースはいずれほぼ全てのRSで合字の組版再現が可能になってくればテキストで表現できるものと思います。

⓭ 数式組版の再現のための外字化

 現状、多くのRSではまだ、MathMLによる数式の表示再現はできていません。また、MathJaxなどもJavaScriptを使用できないRSが多数ありますので使用できません。このため、数式の組版を再現するために外字もしくは画像として挿入しているケースがあります。

 いずれほぼ全てのRSがMathML等に対応すればテキストで表現できるようになっていくものと思われます。

⓮ 日本語での斜体を再現するための外字化

InDesignの斜体機能

InDesignの斜体機能

 EPUBでは文字に対して「font-style:italic」を指定することでイタリック体として表示されますが、日本語の部分に対する指定は斜体になるRSとならないRSがあります。

 日本語にはイタリック体はないからこれが正しいという意見もあるようなのですが、斜体自体は写植の時代からあった機能であり、DTPでもこれを引き継いで実際の印刷物の中で使われている以上、場合によってはどうしても再現しなければならないケースは出てきます。このため、外字もしくはブロックごと画像としています。

 いずれほぼ全てのRSが日本語の斜体指定に対応すればテキストで表現できるようになっていくものと思われます。

⓯ 特定のフォントデザインを保持するための外字化

 特定のフォントのデザインをEPUB内で保持するために、外字もしくはブロックごと画像とするケースがあります。これはどちらかと言えば見出しなどをブロックごと画像とするケースの方が多いでしょう。

 現状、日本語のEPUBではゴシック体と明朝体のそれぞれ平体と太字、合計4種類の書体バリエーションしか使えません。モリサワパスポートのようなサブスクリプション契約をもとに多種多様なフォントを自由に使って表現できるDTPの世界とは雲泥の差があります。フォント埋め込みで対処できればよいのですが、現状まだフォント埋め込みに対応していないRSが存在し、また商用フォントのEPUBでの使用ライセンスに目処が立っていません。このため、外字とせざるを得ないケースが出てきます。

 いずれほぼ全てのRSがフォント埋め込みに対応し、商用フォントのライセンスに目処が立ってDTPに近い形で自由にフォントを使えるようになればテキストで表現できるようになっていくものと思われます。

その他

⓰ アイコンなどもともと文字でないものをインライン表示させるための外字化

 その他、もともと文字ではないアイコン類をインラインで表示させるために技術的手段として外字としているケースがあります。これは実用書などでは多々あります。これらはDTPのデータ内でも画像として挿入されていたケースが大半ですので、将来的にも外字として残るものと思います。こういった類のものは「もともと文字ではない」ので仕方がないものと思われます。

 以上、さまざまな外字画像のパターンを挙げてみました。誤解や過剰なこだわりによって外字にしないでもよい文字を外字としてしまっているケースもありますが、多くは現状のEPUBの技術的制約や、印刷物の表現にまだまだ遠く及ばないEPUBの表現力の中でどうにか印刷物に近い表現を実現するためにやむなく外字としていることがおわかりいただけると思います。

 将来を考えればバッドティップスとなりかねない外字はできるだけ使用を控えるべきという意見には私も賛成なのですが、とはいえ「今」電子書籍を購入してくれた読者に不満を持たせるわけにはいきませんので、そこはどうしてもせめぎ合いにはなるかと思います。

 また、書籍の場合、権利そのものは当然著者のものであり、本来的には出版社や制作会社がたとえテキストの細部であれ勝手に改変するわけにはいきません。何らかの形で承諾が必要になります。これは著作権(同一性保持権)が絡む話です。このため、もとが紙の書籍を電子化するケースではどうしても外字とせざると得ないケースは出てきます。

 EPUBの表現の拡充や、RS側の実装の充実によって少しでもテキストで表現できるケースが増えることを願っております。

(2016.11.14)

 コメントをいただき、IPAフォントに関する部分などを追記いたしました。

(2016.11.14)

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日時点) (888)
IVS/サロゲートペア表示テスト用epubファイル (811)

(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追記)

JEPA第11回・12回セミナーまとめ

2012/07/31

 7月24日に飯田橋で行われたおよび、第11回セミナー「EPUB3と文字」および、JEPA第12回セミナー「ISO国際標準と固定レイアウトWS」に参加してまいりました。と申しますか、光栄にもJEPA技術主任の村田真さんにご指名いただき、講師の一人として壇上で話すという人生初の体験をしてまいりました。ご来場いただいたみなさま、ありがとうございます。ということで今回は第11回および第12回セミナーのまとめです。

JEPA第12回セミナー「ISO国際標準と固定レイアウトWS」

 後から急遽開催が決まった関係で、第11回セミナーと12回セミナーが同じ日に行われ、第12回セミナー「ISO国際標準と固定レイアウトWS」の方が早い時間に行われましたので、ここでも第12回セミナーについて先に書こうと思います。第12回セミナーはIDPF理事の小林龍生さんのご挨拶の後、村田真さんのセッション。2本立てで前後に区切って行われました。

前半:EPUB3のデジュール標準化の状況

 EPUBは2012年に急速な伸びを見せ、2013年にもやはり急速に伸びることが見込まれる、という説明からスタート。「デジュール標準」というのはJIS、ISO、IECのような公的な標準化機関によって制定された標準規格とのこと。EPUBはこれまで、IDPFという業界団体が制定した「フォーラム標準」という位置づけで、これをより認知度が高く、公的機関の文書、特に教科書での採用において必要となる「デジュール標準」へ格上げする道筋が整ったとのお話でした。

 デジュール標準化へ至る道には、標準化を希望する団体が複数存在したことや、フォーラムとデジュールの綱引き、EPUB3の基幹技術であるHTML5やCSS3がまだ完全には定まっていない不安定な状態であることなどさまざまな障害があったようですが、これらはほぼクリアの見通しが立ち、2013年中にはデジュール標準化へ向かうようです。

 これによって、今後は政府調達や教育市場でのEPUB採用が期待できるだろうとのことで、すでにデジタル教科書や問題集の標準化も始まっているとのことでした。

後半:Advanced/Hybrid Fixed Layoutsワークショップ報告

 後半はEPUB3固定レイアウトワークショップについての報告です。
 今回は「Advanced/Hybrid Fixed Layouts」とのことで、より高度で、紙のレイアウトを超えるような固定レイアウトに関してのお話でした。

 まず、EPUBのレイアウトの現状確認の中で、より複雑なページテンプレートを用いたリフローに関するお話がありました。これは、Adobeから提案があったものを仮実装したものがIDPFにはあるとのことだったのですが、まだEPUB3のコアモジュールと見なされてはいない状態で、今後どうなるかも不透明とのこと。

 本番のEPUB3固定レイアウトに関しては、まずは現状の各種固定レイアウト方式、固定レイアウト語彙の説明からだったのですが、これはいわば「おさらい」ですので、詳しくは述べません。こちらなどが参考になるかと思います。
 さて、本番セッションですが、

1. 村田真:Three Types of Digital Comics

 コミックの電子化には、
 ・紙→デジタル
 ・デジタル→紙
 ・デジタルのみ、紙を考えない
 この3つの分類があり、3番目のものではそもそもコンテンツとしての語法が大きく変わってくる、とのお話。ちなみに韓国ではすでにもう3番目のパターンがほとんどになっているとのこと。日本でも遠からずデジタル先行になっていくのでしょうか?

2. Aquafadas:Fixed Layout Reading Experience for Comics, Children Books, Table Books

 フランスのAquafadas社の発表内容の紹介で、レイヤによって日本語版のマンガに他社別売の英訳を電子書籍端末上で重ね合わせる、マンガへのアニメーション効果を重ねあわせるといったようなことや、シーンとショットを別レイヤで定義しておくことで、画面の小さな端末でも快適なコミック閲覧ができる、といったような内容でした。
 これは単に技術面のお話だけではなく、訳やエフェクトを他社が制作して読者が端末上で重ね合わせて読める、といったようにビジネスモデルにまで踏み込んでいるあたりがなかなか面白く感じられました。

3. 集英社:Introduction to the OMF format

 OMFとは「Open Manga Format」とのことなのですが、集英社の作成したEPUBの仕様に乗っ取ったマンガ配信フォーマットということのようです。JPEGを並べただけのBasic.opfの他に、Javascriptですべてを記述したAdvanced.opfという仕様があるとのこと。Basic.opfが電子ペーパー端末用、Advanced.opfがiPadのような液晶タブレット用といったような位置づけでしょうか。同一パッケージ内に双方の文書を格納し、デバイス毎にどちらかを選択して読むというような仕様とのこと。

4. Barnes & Noble:Rendition Mapping

 イメージ画像とHTMLによるリフローを使い分けて表示する方式とのことで、イメージの中に対応するHTMLへの情報を埋め込む方式が「Rendition Mapping」とのこと。これはすでにB&Nの端末で使われている方式のようです。ちょっとモリサワの「MCMagazine」に近い印象を受けました。もちろん「MCMagazine」はEPUBではないわけですが。

5. ソニー:EPUB 3 Rendition selection

 ひとつのEPUB文書の中に複数のパッケージ文書を入れ込む仕様のお話でした。EPUBでは複数のパッケージを同一文書に入れ込むことができるとのことなのですが、これにCSSのメディアクエリを組み合わせることで、サイズの異なる端末用に複数のパッケージを入れておき、自動的に切り替えて表示するといったようなことが可能になるようです。これが実現すれば、iPhoneとiPadの双方に同一パッケージで対応できる固定レイアウトEPUB文書が制作できるようになってくるわけで、なかなか期待感があります。もっともその分制作サイドは大変になりそうですが。

6. 富士フイルム:Rendition Mapping for Manga – Fujifilm Proposal

 マンガにおけるRendition Mappingの実際における発表だったようです。見開きのページはひとつの画面として扱わないと表示が破綻してしまうとのこと。確かにページをまたいだ書き文字などを見ると、そのあたりは想像がつきます。

 といったような説明がありました。
 また、論点として、Javascriptを積極的に使ってEPUB3固定レイアウトの記述をすべきかどうか、HTMLやCSSといったWeb技術を表示に多用するとバッテリー消費が激しくなるため、表示には画像を利用するべきではないか(B&N)、規格策定の優先順位をどうすべきかといったことが上がってきたようです。
 今後、年末までに何らかの成果を出すべく規格策定の動きが始まるとのことで、引き続き要注目です。

JEPA第11回セミナー「~EPUB3と文字~」

 IVS技術促進協議会とJEPAの共同開催という形で行われたセミナーでした。IVS(異体字セレクタ)は電子書籍で使用できるテキスト上で人名漢字などで用いられるような漢字の異体字字形を再現するために期待されているテキストの拡張仕様で、今は電子書籍の立ち上がり時期にあたるだけに関心も高く、結局150人を超える参加者が来場されていたようです。

国語施策と漢字コード:小林龍生

 まずはユニコードコンソーシアムのディレクターで、IDPFの理事でもあるIVS技術促進協議会の小林龍生さんから、JIS、ユニコードなどの変遷と今後の問題点についての基本的な説明がありました。
 最初に、字種/字体/字形の説明から。「学」と「學」は同じ字種だが異なる字体で、さらにその下に細かな字形の差異があるとのお話がありました。情報交換の観点から見た場合、符号化は字種のレベルにとどめるのが理想だが、実際には字体レベルでの包摂/統合は不可避で、ただ字形のレベルにまで踏み込むと本当にきりがないとのこと。
 また、そもそもの字形の揺れ問題の発端は、78JISと83JISの改訂に端を発するのではないかという意見を述べておられ、これは現場サイドとしても良くわかるお話です。

 さらに、表外漢字字体表と印刷標準字体の話の絡みで、策定時期の関係でJIS2000の例示字形には表外漢字字体表が反映されなかった経緯についての説明がありました。これにより、JIS2004で168文字の例示字形変更が必要になったとのことです。この168文字の変更には微細なデザイン差の変更も含むとのことで、字体レベルでの変更は100の符号位置に留まるとのこと。この100符号位置の字形をテキスト上で変えるにはIVSが必要になってくるようです。

 ただ、そうした区別が本当に必要かどうかは、検索の利便性などの観点から、利用者は良く考え、最低限に止めるべきなのではないかとのご意見を述べておられ、これは外字の画像化にも通じる論点ですのでとても共感できます。あまりも多様な漢字の字形差全てを電子書籍上で再現しようとすることは、制作コストにも直結してくる大きな問題と思います。

マイクロソフトが実現する新たな文字の世界:田丸健三郎

 マイクロソフトの田丸さんからの、第一世代Shift_JISからJIS2004対応に至るOSの文字コード対応の歴史次期Windows、OfficeでのIVS対応についてのお話でした。
 さらに基本文字+IVSシーケンスで異体字を表現するIVSの基本的な仕組みや、フォントやアプリケーションがIVSに非対応であっても基本文字は表示されることが期待できるために、完全な文字化けと言ったようなことにはならないIVS技術の特色などに関してもひととおりのご説明がありました。
 また、ユニコードの符号化方式(UTF-8/UTF-16)と符号化文字集合(Unicode 6.0 etc)の関係に関しても説明があり、基本的な部分ですがきちんと押さえておく必要はありますのでなかなか面白く聞かせていただきました。

 マイクロソフトのOSにおける日本語文字コードの変遷は、1982年のMS-DOS2.0におけるShift_JISの採用に始まり、Windows3.1でのマイクロソフト標準キャラクタセット(cp932)採用Windows98以降でのユニコード対応へと進み、Windows Vista以降でサロゲートペアを含むJIS2004に対応したという流れとのこと。

 マイクロソフトは次期WindowsではIVS文字の入力にOSレベルで対応するとのことです。デフォルトでIVSが入力できる状態ではなく、チェックボックスをオンにする必要はあるとのことですが、いずれにせよ外部からデータを受け入れる可能性のある印刷会社/制作会社は、今後IVSが使用された原稿の受け入れ体制を整える必要がありそうです。
 また、Officeでの対応に関しては、次期Office製品でIVSに正式対応するだけでなく、Office2007/2010でもデータ互換のためにOffice IVS Add-inによる移行パスが提供されるとのこと。

 今後電子書籍の時代には、編集者・校正者・作業者が同一の文字環境で作業するような環境を構築し、OSやフォントに起因する字形の揺れをあらかじめ抑止することが、スムーズな作業の流れのために最低限必要となってくるように思います。

DTPデータから電子書籍を制作する際の「外字」問題:田嶋 淳

 田丸さんのあとが私のセッションでした。内容的にはこちらのブログに掲載したものと重複する点が多くありますので詳述はしませんが、InDesignのデータからテキストを抜き出した際に起きる字形変化の理由および、どういったパターンの字形変化が存在するのか、今後電子書籍・印刷データ双方の制作環境はどういった方向性を目指すべきかといった点に関していささか拙いながら述べさせていただきました。

 当日配付させていただいた資料を以下からダウンロードいただけますので興味をお持ちの方はご覧いただければ幸いです。また、epubcafeのページにYoutube動画へのリンクもありますので、あわせてご覧下さい。

7/24セミナー配付資料 (1914)

 なお、この内容に関連して、小形克宏さんの制作された技術者・ソフトウェア開発者向けのより詳細な資料が、出版デジタル機構ホームページ内「技術部だより」より、近日中にダウンロード可能になります。

 この外字の問題につきましては、「では現状どうすればよいのか」というご質問を何度かいただいたのですが、ソフトウェアを用いて完全に対処することが難しい以上、最後は目視での校正作業に頼らざるを得ないのが現状です。こうした作業を少しでも軽減するために、InDesignの「代替字形」チェックボックスの活用や、スクリプトを用いて内部文字をチェックすることで対処が必要な文字をある程度洗い出すことは可能ですが、いずれにせよ最終的にきちんとした品質を確保するには全文の目視校正作業が不可欠と思われます。

IVSとのつきあい方:狩野宏樹

 株式会社イワタの狩野宏樹さんのセッションで、現状でのIVS対応フォントの状況OSの対応状況IVSを使用する上での基本的な注意点についてのお話でした。

 IVS対応フォントは、小塚明朝Pr6N小塚ゴシックPr6NがInDesign CS4にバンドル提供されたのを皮切りに、2011年1月にイワタから発売された52書体游明朝体Pr6/Pr6N R筑紫明朝Pr6/Pr6NイワタUDゴシック/イワタUD丸ゴシックなど、現状100フォント以上が利用可能になっているとのことです。

 OSとしてはWindowsは7以降で異体字が表示され、Vistaでは異体字は表示できないもののIVSシーケンスが無視されて基本文字が表示されるため、読み取り自体は可能とのこと。XPではIVSの文字自体が文字化けして表示されてしまうようです。Mac OSは10.6以上で表示に対応、10.7以上ではバンドルフォントのヒラギノProNがIVSに対応しているとのことです。

 また、アプリとしてはInDesignはCS4でIVSに対応していますが、IVS文字を親文字とは別々に選択できてしまう仕様のため、IVS文字だけが残ってしまう危険がある点を指摘されていました。また、IVS文字にルビをかけた場合、直前の文字にルビが存在しない場合、IVS文字が化けてしまうバグが現状で存在するようです。直前の文字に全角スペースのルビを振ることで対処療法として回避は可能ですが、将来的に改善を期待したいところです。

 さらに、IVSは漢字のみにしか使えないものであること、IVSが必要な文字がどれなのか直感的な区別が難しいこと、IVSのコレクションにはAdobe-Japan1以外にHanyo Denshiがあり、双方で異体字の重複があること、IVSでは異体字が表示されない場合でも基本字形は表示され、特に文字化けの警告等は表示されないため、InDesign等で文字変化を発見しにくい危険があることなども指摘されており、このあたりは今後の課題として十分な注意が必要そうです。
 加えて、フォント側として全てのIVS仕様文字への対応が求められるわけではないため、フォントが目的の異体字に対応していなければ基本字形に変化してしまうといった状況が起こり得るとのこと。

 さらには、IVSとGSUBを併用することは避けるべきで、IVSならIVSで統一すべき、とのお話もあり、本格的な運用までにはまだ若干の課題が残っているようです。

(2012.7.31)

プロフィール
Jun Tajima

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

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