前回、PDFのデバイスカラースペースの3種類について説明しました。これらはその名前にある通りデバイスに依存したカラーの表現方法でした。そのため同じRGB値、あるいはCMYK値でも、デバイスが異なると違って見えることになります。同じ写真を2つの違うプリンタで印刷したり、同じ番組を違うテレビで見たり、といった身近なところでも経験することが多いかと思います。PDFの場合にあてはめれば、何か文書を作成してPDF化し、他の人にそのPDFを送って参照してもらうような場合に、作成した人が見ている画面と、送った先の人が見ている画面（あるいは印刷した紙）では別の色が表示されている、という現象になります。

このあたりを解決する、つまり異なるデバイス間で、同じカラー指定に対して同じ出力を行うことを目的としたカラースペースがCIEベースのカラースペースとなります。同じ出力といっても、当然ながら「そのデバイスの制限範囲内で」という制限がつきます。ディスプレイにしてもプリンタにしても、デバイスによって可能な色の再現範囲は異なりますので、その中で、指定に近い出力を得る（カラー値やカラースペースをどう調整しても、モノクロプリンタでカラー写真を印刷はできませんし）ことが目標となります。

前回記載したPDFで定義されている CIEベースカラースペース として、CalGray、CalRGB、Labおよび ICCBased の4種類を記載しました。これらのカラースペースの内容、指定されたカラー値を再現する方法の説明となるわけですが、PDFの仕様以前に、色とは何か、という非常にやっかいな説明が必要となってしまいます。わかる範囲で少し説明を試みてみたいと思います（デバイスカラースペースは、光の3原色、あるいは、プリンタのインクというような身近なところから、なんとなく理解できそうなので、色とは、などという説明抜きでなんとなく説明できましたが）。

おおざっぱにいえば、なんらかの光源から発した光が、物体にあたって反射し、人間の目に入り、人間がその物体の色として認識する、ということになります。赤いクルマといっても、太陽光の下で見る場合と、トンネル中の証明で見る場合と違うのは光源の発する光の性質が異なっていることによります。この光ですが、波としての性質を持つ、空中を伝わる振動エネルギーの束と考えることができるようです。波の性質として波長がありますが、高エネルギーの光の波長は短く(たとえば、X線では 1nm）、低エネルギーの光の波長は長く（ラジオの中波は100m～1km）なります。人間の目がとらえることができる可視光の波長は380nm～700nmのきわめて狭い領域ですが、この短波長側の光を紫、長波長側の光を赤として認識します。その外側がそれぞれ紫外線、赤外線と呼んだりします。また、虹などでは紫から赤までを適当に区切って7色と数えたりします。太陽光のような実際の光はいろいろな波長が混在した光です。可視光内で、緑の波長（国際照明委員会の規定では546.1nmだそうです）が多く含まれていれば緑、各波長の光が均等に含まれていると白と認識します。

ちょっと先走って、人間が赤とか紫とか認識すると書きましたが、人の目に入ってきた光は角膜、水晶体を通過して網膜にあたります。網膜上には光に反応する受容体として桿体、錐体というものが存在します。この錐体に可視光内の長波長(赤)に反応するもの、中波長(緑)に反応するもの、短波長(青)に反応するものがあり、それぞれの錐体がどのくらい反応するかで光の色を認識することになります。

色の話になってしまって、PDFのCIEベースカラースペースの話まで進めませんでした。こういう色というものをコンピュータ上でどう表現するか、さらにPDFではどう表現するか、また続きを記載したいと思います。

PDFの色指定について

PDFの色指定の概要・デバイスカラースペース

PDFの色指定 （3）CIE1931 CIELuv CIELAB

CIEカラースペース

PDFの色指定（4）

ICCプロファイル

PDEの色指定（5）CIEベースカラースペース

PDFのCIEベースカラースペース格納形式と使用のされ方の概略

Tweet

今回は PDF/Aの作成方法(準拠レベルA) でAcrobat/Wordが出力したPDF/A-1aの内容、主にタグ部分について少し見てみたいと思います。
レベルAではレベルBが持たない情報である文書の論理構造、言語などの情報を持つ必要がありました。PDFでは、文書の論理構造を表現するためにタグと呼ばれる仕組みを用意しています。
このあたりをつかって元文書がどのように表現されているか、Wordで簡単なサンプル文書を作成して、PDF/A-1aに変換したものを見てみます。

Word文書

章、節、項の部分はWordの組み込みスタイルである「見出し1」～「見出し3」を使用し、
リスト番号を付加したものです。他に、箇条書き、表、画像 などを入れてみました。

Acrobat XIでは 「表示メニュー」の「表示切り替え」-「ナビゲーションパネル」-「タグ」とすることで、ドキュメント内につけられているタグの様子を見ることができます。左側にタグが階層表示され、ここをクリックすると本文内の対応する箇所がハイライト表示されます。
Word 2013で「PDF/A」および「アクセシビリティ用のドキュメント構造タグ」を指定して作成したPDFの場合

このように表示されます。

一方、Word 2013から Acrobat XIのWord用PDFMakerでPDF/A-1aを指定して作成したPDFの場合

となりました。

主なところだけ展開したキャプチャです。似たような構造ですが、タグの名前をはじめとして、細部では若干タグのつけ方も異なっていることがわかります。

PDFMakerでは「見出し1」など、Wordのスタイル名をそのままタグ名に使用しています。これら独自のタグ名をPDF仕様が用意している標準的なタグ名に割り当てる「ロールマップ」という仕組みがPDFに用意されていて、Acrobatでも表示させることができます。

これを参照すると、スタイル名の「見出し1」を標準タグの「H1」に対応づけていることがわかります。

このような形でタグを使用して元文書の論理構造をPDFで表現します。

また、比較のために、Wordの「見出し1」などのスタイルを使わずに、表示だけ似たような形の文書を作成してPDF/A-1a出力してみます。

ここの 章番号 1. 、1.1.1 などはWordのリスト番号ではなく、通常のテキスト入力したものです。
PDF/A-1aに変換した結果のタグを見てみます。

これはWordのPDF保存の場合ですが、このように、こちらでは文書構造を取得するヒントとなるものが存在しないため、単純に〈P〉タグだけで出力されていることがわかります。

以上、簡単なタグ付け内容の参照方法となります。

Tweet

先日、JR東海から2027年度に開業が予定されるリニア新幹線の概要が発表されました。多くのメディアで取り上げられましたので興味を持って見られた方も多かったのではないでしょうか？
弊社の伊那支店がある長野県南部にもリニア新幹線の新駅ができる計画で、地元紙でも大々的に記事が掲載されました。これまで夢としてしか語られなかったことがにわかに現実味を帯びてきたことで、谷あいののどかな地方にこれからどのような風が吹きこむのか、住人としても目が離せない気がします。

閑話休題。

昨年の7月頃に『OCRのよもやま話』という記事を書きました。
今回はその続きということで、OCRにまつわる話題をいくつか追加したいと思います。

OCRと解像度

OCRとは、Optical Character Recognition（あるいはReader）の略で、紙に印刷された文字をイメージスキャナなどで読み取り、画像化された情報から文字情報を抽出する技術であることを以前の記事でご紹介しました。

OCRで文字を正確に取り出すために必要な要素を考えると、おおよそ以下の点が挙げられると思います。

1. 元になる原稿の状態が良好であること（文字が鮮明で、紙に汚れや皺がないなど）
2. 適切な解像度でスキャンされていること
3. OCRソフトが適切な性能であること

このうち、2）の「解像度」について取り上げます。

OCRで使う解像度はスキャナなどで取り込む画像の品質を表すもので、dpi（ディーピーアイ）という単位を使います。これは、1インチ（2.54cm）の間隔にどれだけ物理的な点（画素）が配置されているかを示すもので、同じ大きさの画像で比べた場合は、解像度の値が大きいほど高精細な画像が得られます。

解像度は別の言い方をすると、1インチあたりの画素の密度を表すということができます。密度が濃ければそれだけ細かい描写が可能になります。以下はそれを模式図にしたものですが、文字のサンプルにあるように解像度が小さいと曲線などで滑らかな表現ができなくなります。

解像度

では、実際に異なる解像度でスキャナから取り込んで比較してみましょう。

以下は、スキャナの設定でそれぞれ 200dpi／400dpi に解像度を変更してJPEG形式に保存したデータの一部を示しています。

解像度の違い

ちょっと分かりづらいかも知れませんが、ブラウザの表示倍率をあげて見ていただくと両者の違いが分かります。
以下は、この二つの画像を弊社のOCR変換製品『瞬簡PDF OCR』でテキストファイルに変換した結果です。

変換結果

解像度が200dpiだと文字化けしてしまう箇所が、400dpiでは（完全ではないですが）おおむね正しく認識できていることが確認できます。

そうすると、もっと解像度を高くしてスキャンすれば更に良い結果が出せそうに思えます。ところが、これがさにあらず、なのです。
以下は、スキャナの設定を600dpiにして変換を行った結果です。

600dpiで変換

解像度を上げても、あまり変換結果に影響がないことが確認できるかと思います。
一般にOCR処理では、300～400dpiの範囲が適切なOCR結果を得る解像度だと言われています。それ以上解像度を上げてもファイルサイズが大きくなるばかりで、OCRの変換精度はあまり変わらないか、逆に悪くなってしまう場合もあります。ちなみに今回使用したJPEGデータの場合、400dpiのときのファイルサイズは約1.4MBですが、600dpiでは約2.7MBでした。

OCR処理を使って文字の取り出しを行う際には、スキャンの段階から適切な解像度を設定していただくことでより良い結果が得られます。ご参考にしていただければ幸いです。

※『瞬簡PDF 変換8』、『瞬簡PDF OCR』は製品の体験版を公開しております。是非、お試しください。

Tweet

PDF/UAの紹介の最後になります。

ここまで、ファイルフォーマットの要件、リーダの要件を記載しましたが、最後はAT(Assistive Technology:支援技術）の要件になります。

このATにはPDF/UAを使用するスクリーンリーダや、音声入力をサポートするデバイス、キーボード入力を容易にする装置、点字に変換して印刷するソフトウェアなど広範なソフトウェア、ハードウェアが含まれます。

ATに求めら得る要件とは、大きくは下記となります。

• この仕様に定められた構造型、属性、値をユーザが好む方法で利用、表示できること、論理構造ツリーに属さないアーティファクトを処理する機能があること。
• 準拠リーダが複数の表現方法で表示する場合、ATはユーザの選択する方法でその表現にアクセスすることを可能としなければならない。
  （この複数の表現方法とは、PDFのオプショナルコンテントあるいはレイヤーなどと呼ばれる機能を使用した表現方法のことです）
• ナビゲーション機能として、以下をサポートする必要があります。
  • PageLabel数値ツリーを用いてナビゲーションする機能
  • 構造階層を用いてナビゲーションする機能
  • ドキュメントのアウトライン(Adobe Readerのしおり）を用いてナビゲーションする機能
  • ユーザ指定に応じたズーム機能

PageLabelとは、たとえば、目次部分は小文字のアラビア数字、本文はローマ数字といったページ番号を持つ文書がありますが、PDFでそのような表現をする機能です。ナビゲーションに、このPageLabelや、文書の章・項といった論理構造の階層情報を使用する機能が必要とされます。

ATの要件については、あまり詳細なことは定められていません。

以上、PDF/UAの紹介となりますが、フォーマットの要件部分で、関連仕様に W3Cの Web Content Accessibility Guidelines(WCAG) 2.0 があることを記載しました。
これまで説明したPDF/UAファイルの作成、使用の双方に必要とされる要件は、PDFファイルをW3Cの勧告であるWCAGに沿って利用するために必要とされるPDFの機能の使用方法となります。

PDF/UAの理解には、WCAG 2.0 （およびその関連ドキュメント）で解説される内容を理解する必要があります。
WCAGのW3Cの勧告は下記にありますので、興味のある方は参照ください。
http://www.w3.org/TR/2008/REC-WCAG20-20081211/
（日本語訳）
http://www.jsa.or.jp/stdz/instac/commitee-acc/W3C-WCAG/WCAG20/

Tweet

間があいてしまいましたが、以前のPDF/UAの紹介の続きになります。
PDF/UA(ISO 14289-1)について
PDF/UA(ISO 14289-1)について（２）

今回は、PDF/UAのリーダ側の要件をまとめてみます。

全体としては、ISO 32000-1:2008で定義されているドキュメントの論理構造とアーティファクトを処理する能力を持つこと、および、ATとのインターフェース機能を持つこと、とあります。

AT(Assistive Technologies：W3CのWCAG2.0の邦訳では「支援技術」という用語が使用されていました。)とのインターフェース機能とは、

• 構造タグのタイプ、属性、およびキーの値に対するアクセスの提供およびオプショナルコンテントグループの可視状態を考慮した表示能力
• アーティファクトをATが利用できるようにすること
• ユーザインタフェースが存在する場合、それをATが利用できるようにすること

とあります。
（ここの「アーティファクト」ですが、PDFではドキュメントの著者によるオリジナルのコンテント（リアルコンテント）以外の、ページ付けやレイアウトのために生成されたオブジェクトをアーティファクトと呼んでいます）

以下、PDFの各オブジェクトに対して個別に記載されている要件となります。

テキスト

・論理的な読み込み順番をATデバイスが利用可能であること
・文字コードを適切に処理する能力があること
・自然言語、およびその変更をATデバイスが利用可能であること

表

表のセルが空である場合、その情報をATデバイスが利用可能であること

オプショナルコンテント

オプショナルコンテントを含む場合、複数の表現が選択可能となることがあるが、すべてのオプショナルコンテントを表示する手段を提供し、オプショナルコンテントコンフィギュレーション辞書の階層を表示する手段を提供すること
（このようなドキュメントの例として、多言語ドキュメントで、オプショナルコンテントを使用して、各言語別の表現をサポートしているようなドキュメントがあります）

添付ファイルと埋め込みファイル

• 構造ツリーに存在していない添付ファイルを利用可能とすること
• 埋め込みファイルの名称を表示するためにメカニズムを提供すること

デジタル署名

デジタル署名されていることをユーザに報告し、デジタル署名の証明書属性と有効性の状態を提示できること

アクション

アクションがドキュメントの可視状態を変更する場合、ATがその変更を利用できること

メタデータ

ドキュメントのCatalog辞書のMetadataストリームにおけるすべての要素をATが利用できること

ナビゲーション

論理階層構造やしおりを使用してナビゲートする機能を持つこと

注釈

各注釈の代替え記述をATデバイスに利用可能とすること

フォーム

ウィジェット注釈のテキスト記述をATデバイスに利用可能とすること

マルチメディア

動的にではなくユーザの要求に応じて再生すること

PDF/UAの読み手にはこれらの機能が必要とされています。

Tweet