カテゴリー別アーカイブ: PDF のあれこれ

Google Chrome開発者版(86)でタグ付きPDFを出力[8/4修正]

[8/4追記]社内で「Chrome出力ではなくAcrobat Readerの対応外のタグ使用によって表示が壊れている可能性がある」と指摘を受けました。記事内での表現を修正します。

当初の記事タイトルは「タグ付きPDFがGoogle Chromeのデフォルトに?」だったのですが、現状としては「今後Google Chromeでタグ付きPDF出力が可能になるかもしれない」あたりのようです。

今回使用した環境は次になります。

  • Windows 10 Home 1909
  • Google Chrome バージョン: 86.0.4221.0(Official Build)canary (64 ビット)
  • Acrobat Reader DC – Japansese (20.009.20074)
  • 検証に使用したページ*https://www.w3.org/TR/xsl11/

2020年8月リリースのGoogle Chrome 85から、タグ付きPDFの出力がサポートされます[1]。関連する情報発信自体は以前からあったようですが、実際にリリースされるこのタイミングで俄かに活気づいているようです。活気づいてますよね?

早速Google Chromeをサイトからダウンロードしてみましたが、バージョンを確認すると2020年8月3日時点では84のようです。Google ChromeにはCanaryバージョンがあるのでこちらをダウンロード。試験運用版ですので、同様に検証される方はくれぐれも自己責任でお願いします。(84でもExperimentalの設定として「Export Tagged PDF」を有効化できます。)

バージョンを確認。86……86ですね。85ではありませんが、検証には問題ないでしょう

この後Chrome 84でのtagged PDF出力も確認しましたが、同様の結果になりました。

タグ付きPDFとは

ざっくりとまとめると「タグ付きPDFは、内部に文書構造を指定するタグを付与したPDFのこと」になります。
通常PDFは印刷物のデジタル表現、つまり視覚的な表現として文書構造が見られればよいわけですが、
PDF内部のデータを別の目的で使うときにこの情報だけでは不足することがあります。
別の目的としては、データの読み上げ、PDFから他形式への再変換などがあります。

また、PDFをHTMLのようにリフローで表示したいときにも、タグを用いることで文書の表示順序などを壊さないようにできます。
「HTMLのように」と書きましたが、このタグ付きPDFで設定できるタグの多くはHTMLでのタグと類似したものになります。

概要は[2][3]、詳細は[4][5]をご覧ください。

新ビューアは今のところリフロー表示に対応していないらしい

Canaryだと、PDF出力オプションの他に「PDF Viewer Update」オプションがあるんですね。

chrome://flags/#pdf-viewer-update

これを有効化すると、84ではExperimentalのオプションである「PDF Two-up View」もついでに使えるようになります。

ウインドウ画面と表示をフィットさせる場合に上下と左右どちらを優先するか、回転表示、PDF注釈の表示のオンオフ、アウトライン表示など、色々改善がされていることがわかります。とはいえ、全体的なPDFの表示機能についてはまだまだ頑張ってほしいところです。

さて、タグ付きPDF対応と聞いて真っ先に期待してしまうであろうリフロー表示ですが、とりあえず86の新ビューアではできないようです。
「タグ付きPDFの出力」と「PDFのリフロー表示」は重なる部分もあるものの別の話なので、そういうこともありますね。
今回の新バージョンについて、ChromiumのブログにChrome Accessibilityのリーダーからコメントがあります。improving Chrome’s built-in PDF reader to better consume tagged PDFsとあるので、それなりに可能性はあるのではないでしょうか。
> While this is an important milestone, we’re not done. Future work includes both improving the quality of generated tagged PDFs, and also improving Chrome’s built-in PDF reader to better consume tagged PDFs.

タグ付きPDFをChromeで出力する

本題のタグ付きPDF出力です。Experimentalな設定で次を指定するとタグ付きPDFが出力できるようになるとあります。

chrome://flags/#export-tagged-pdf

では、PDFを出力してみます。*のページを「PDFで保存」します。さて、本来はこれをAcrobat Readerで開いてみて「おおー」となる予定だったのですが、「表示」「折り返し」を有効にしたAcrobat Readerでのリフロー表示がうまくいってないようです。

W3Cのページはあまり変なマークアップのHTMLはないはずです。タグ付きPDFは検証した日時でのGoogle ChromeとしてはExperimentalな機能なので、こちらが原因でしょうか。タグ付きPDFとリフロー表示についてはAcrobat Readerの対応状況も関連するので、Chromeの出力が原因ではないかもしれないとの指摘をいただきました。Google Chromeには自分の出力の正しさを証明するためにもPDFリフロー表示に対応してほしいですね。
PDFの内部を確認したい方は、アンテナハウスのデスクトップ製品『
瞬簡PDF 編集 9
』[6]付属の『タグ編集ツール PDFタグエディターVer.2』を使うとよいかもしれません。

他に数件確認してみましたが、ページが上のように壊れることはないものの、「いきなり何もかも上手く出力できる」とはいかないようです。Experimentalな機能なので詳細な検証をすることを避けました。

ちなみに、Chromeでのタグ付きでないPDF出力をAcrobat Readerの折り返し表示したときは、とりあえずは表示されています。

ちなみに、同じWebサイトをAntenna House Formatter V7.0 MR3でタグ付きPDFを出力した場合、折り返し表示でも問題はないようです(フォントサイズや余白、分割アルゴリズムの違いなどがあるので同じ条件にはなっていません。)。

ChromeでのHTMLとタグ付きPDFの補足資料

Chromiumのタグ付きPDF機能開発におけるデザイン資料[7]によればこれはマークアップを元にタグを付与するものなので(AIが何もかもやってくれるような話ではない)、求められるタグを出力できるかはページ製作者次第です。Chromeの開発過程で実際にはどうなったかは確認していませんが(資料中のメーリスやバグトラッカーを確認していけばよさそうです)、DOMツリーと描画用ツリー、そしてARIA属性などを基にした「Accessibility tree」を利用するデザインのようです。


The accessibility tree computed in Blink is another good possibility. The accessibility tree is derived from the DOM and the Layout Tree and also takes accessibility attributes such as ARIA attributes into account.
Chromium Tagged PDF Export Design Doc

We think the accessibility tree is the best fit and that’s the design proposed here.
Chromium Tagged PDF Export Design Doc

つまり出力が完璧だったとして、現在のところ多くのWebページについて実用的かと言われれば疑問の残るところ。残念ながら、ページによってはむしろ不要なノイズだらけになってしまうでしょう。[7]に次のようにありますが、こういった機能を機にアクセシブルなWebページを作ろうという気運が再燃したりすれば幸いです。

正常に出力されるページもあるかもしれませんが、現在Experimentalとある機能ですので、今回はここまでとします。

タグ付きPDFにご興味を持たれた方は、アンテナハウスのPDF製品を是非チェックしてみてください。


if you visit a web page that’s compliant with WCAG accessibility guidelines, then export it as PDF, then open that PDF in Chrome, the PDF in Chrome should have the same level of accessibility, modulo the limitations of a PDF file.Chromium Tagged PDF Export Design Doc

  1. [1] Using Chrome to generate more accessible PDFs – Chromium Blog
  2. [2] タグ付きPDFとはどんなもの
  3. [3] PDFのリフロー表示。タグ付きPDFとタグの付いていないPDFの比較。
  4. [4] 『タグ付きPDF 仕組と制作方法解説』
  5. [5] 『PDFインフラストラクチャ解説』
  6. [6] かんたん操作でPDFを自由自在に編集 瞬簡PDF 編集 9
  7. [7] Chrome Tagged PDF Export – Authors: dmazzoni[at]chromium.org
    November 2019



PDFの色指定(5)CIEベースカラースペース

PDFにおけるCIEベースカラースペースは初回に紹介したように次の4つです。

  • CalGray
  • CalRGB
  • Lab
  • ICCBased

デバイスカラーベースと異なり、出力デバイスに依らず色を指定できます。出力時の処理では内部でXYZの3値による表現に変換され、このXYZがデバイスカラースペースに変換されます。そこからはデバイスカラースペースと同様に処理されます。

CalGrayはグレースペースの要素Aを用います。Aは0.0~1.0の値を取ります。値AをMatrix Aを使用しLMNの3値にデコードします。このLMNをそのままXYZとして使用します。
このMatrix Aを構成する値が、CalGrayに辞書型で格納される、CIEXYZに基づく白の基準値WhitePointと、黒の基準値BlackPointの3つの数値からなる配列と、輝度補正に使うGammaです。WhitePoint以外はオプションで、指定しなければ既定値を使用します。白と黒の基準値は、それぞれdiffuse white point、diffuse black pointと呼ばれるものです。

CalRGBでは入力値が増えます。CalRGBにに格納する辞書型は、GammaがRGBに対応する3値の配列になる他、Matrixというキーで3×3の行列が格納でき、XYZへ変換するときに補正値として用います。

PDFにおけるCIEベースカラースペースでのLabは正しくはCIE LABの方です。辞書型WhitePoint、BlackPointと、Rangeというa*、b*をそれぞれの最大値、最小値で指定する4つの数値の配列を格納しています。

最後にICCBasedカラースペースについてです。ICCカラープロファイルをストリーム型として格納できます。
追加として、サポートしていないデータがあった場合などに代替される設定名の配列Alternateや、ICCプロファイルで記述されているCoulor Componentの数Nを辞書型で格納します。PDF1.7ではICC. 1:2004-10に対応しています。

デバイス依存の色指定を、comformingなPDF writerは、機械的にCIEベースカラースペースに変換するよう要求できるとあります。

ISO 32000-1:2008にはこれらの詳細が数式・図表付きで記述されています。

参考

ISO 32000に準拠するPDFってどんなもの?


PDFの色指定について
デバイスカラースペース
PDFの色指定について(2)
色とは何か
PDFの色指定 (3)CIE1931 CIELuv CIELAB
CIEカラースペース
PDFの色指定(4)
ICCプロファイル

PDFの色指定(4) ICCプロファイル

前回、CIE1931、CIELAB、CIELUVについて触れました。
これらを活用し、様々なデバイスで色について統一的にマネジメントするための仕組みがICCプロファイルです。

International Color Consortium(ICC)[1]は、コンピュータやデジタルカメラ、スキャナ、プリンタなどのデバイス上で統一して色の管理を行うための標準化団体です。ベンダー8社を中心に1993年に設立されました。

ICCプロファイルは基準となるカラースペースの定義と、それに基づく設定の記述によって構成されています。基準となるカラースペースはプロファイル接続空間(PCS)と呼ばれます。これは、CIEXYZやCIELABによるカラースペースに制限を加え、プロファイルに使用しやすいようにしたものです。PCSという共通のカラースペースがあることで、あるデバイスでの色の記述を、そのデバイスのプロファイルを使いPCSの色表現に変換し、それを別のデバイスプロファイルを使って別のデバイス上での色の記述に変換できます。またICCプロファイルには、色の記述をPCSでの色表現に変換するための共通のインターフェースという役割があります。
このインターフェースは、先に挙げたPCSとPCSに色の記述を変換する設定の書式を厳密に定めたもので、構造としては、ヘッダ部、タグのテーブル、タグに紐付いたデータで構成されます。変換アルゴリズムなどの実装については定めていません。

PCSからデバイスの色に変換する際に、そのままではデバイスで対応できない色が含まれる場合があります。そのときに対応していない色をどの色にマッピングするかを定める「レンダリングインテント」と呼ばれるものをICCプロファイルに用意できます。

caption: PCS

ICCプロファイルは、デバイスによって幾つかの種類に分けられます。主に次の3つです。

  • スキャナ、デジタルカメラなどのための入力プロファイル
  •  ディスプレイなどでの表示のためのディスプレイプロファイル
  •  プリンタなどのための出力プロファイル

他の種類もあります。

  • 画像形式での流通のためのカラースペースコンバージョンプロファイル
  • 特定の色のための命名色プロファイル
  • 追加の補正情報を埋め込むためのアブストラクトプロファイル

さらに、プロファイルを組み合わせて1つにした、デバイスリンクプロファイルがあります。

相互に色を変換するための共通の書式であるICCプロファイルについて概要を説明しました。
次回はようやく、PDFのCIEベースカラースペースについての回になる予定です。

[1] http://www.color.org/abouticc.xalter

PDFの色指定について
PDFの色指定の概要・デバイスカラースペース
PDFの色指定について(2)
色とは何か
PDFの色指定 (3)CIE1931 CIELuv CIELAB
CIEカラースペース
PDEの色指定(5)CIEベースカラースペース
PDFのCIEベースカラースペース格納形式と使用のされ方の概略

暗号化されていてもPDFを開くときはご用心

暗号化されているPDFが送られてきてそのパスワードを知っていたら、作成者を信用して PDFを開いた後についつい不用心にPDFViewerの警告を無視していろいろと危ない操作をしてしまうかもしれません。しかし、2019年に、PDFのパスワードを知らないでもパスワードを変えずにPDFを色々と改変できてしまう脆弱性が発見されました(https://pdf-insecurity.org/index.html)

まだ脆弱性に対応していないPDFViewerもあるかもしれないので、外部からもらったファイルには細心の注意を払いましょう。


『Antenna House PDF Tool API』(PDF Tool API)でページ単位に分割してみる(2)

『Antenna House PDF Tool API』(PDF Tool API)は、PDFファイルの情報取得やPDFファイルの加工・編集を行うライブラリです。
PDFに関するさまざまな処理機能を搭載しています。
文書情報やページ数などの情報取得、ページの挿入や削除、透かしの挿入、セキュリティ設定などのファイル加工、ページコンテンツのテキストや画像の削除、画像の最適化(ダウンサンプリング)といったページ編集処理が可能です。

今回は『Antenna House PDF Tool API』(PDF Tool API)を使用して、複数ページのPDFを、1ページ単位に分割しながら、リンク注釈を設定します。
設定されたリンク注釈をクリックすると、前後のページのPDFを呼び出します。

Javaサンプルコード

Javaサンプルコード(ExtractPageAndLink)のダウンロード(ZIP)

入力元PDFから1ページ単位で取り出し、出力先PDFを生成します。
この時、入力PDFの文書情報を、出力先PDFに設定しています。
更に、前後ページのPDFファイルへリンク注釈を設定しています。

入力サンプルPDF(総ページ数3)

pdftool.6.0.sample

出力サンプルPDF(1ページ目)

次ページのPDFファイル(output_page_2.pdf)へのリンク注釈です。

pdftool.6.0.page1

出力サンプルPDF(2ページ目)

前ページのPDFファイル(output_page_1.pdf)へのリンク注釈です。

次ページのPDFファイル(output_page_3.pdf)へのリンク注釈です。

pdftool.6.0.page2

出力サンプルPDF(3ページ目)

前ページのPDFファイル(output_page_2.pdf)へのリンク注釈です。

pdftool.6.0.page3

索引用のPDFファイルを作成して、分割したPDFファイルへリンク注釈を設定するなども可能です。


『Antenna House PDF Tool API』(PDF Tool API)でページ単位に分割してみる(1)

『Antenna House PDF Tool API』(PDF Tool API)は、PDFファイルの情報取得やPDFファイルの加工・編集を行うライブラリです。
PDFに関するさまざまな処理機能を搭載しています。
文書情報やページ数などの情報取得、ページの挿入や削除、透かしの挿入、セキュリティ設定などのファイル加工、ページコンテンツのテキストや画像の削除、画像の最適化(ダウンサンプリング)といったページ編集処理が可能です。

今回は『Antenna House PDF Tool API』(PDF Tool API)を使用して、複数ページのPDFを、1ページ単位に分割してみたいと思います。

Javaサンプルコード

Javaサンプルコード(ExtractPage)のダウンロード(ZIP)

入力元PDFから1ページ単位で取り出し、出力先PDFを生成します。
この時、入力PDFの文書情報を、出力先PDFに設定しています。

入力サンプルPDF(総ページ数3)

pdftool.6.0

出力サンプルPDF(1ページ目)

pdftool.6.0.page1

出力サンプルPDF(2ページ目)

pdftool.6.0.page2

出力サンプルPDF(3ページ目)

pdftool.6.0.page3

入力元PDFが1000ページであれば、出力先PDFは1000ファイルになります。
分割条件を変更すれば10ページ単位や、特定の文字列をキーに、そのページで分割なども可能です。

製品に関するご質問は
sis@antenna.co.jp(SYSTEM担当)
または
oem@antenna.co.jp(OEM担当)
まで、お気軽にお問い合わせください。

評価版のお申込
評価版のお申込ページ

Webページ
https://www.antenna.co.jp/ptl/


「PDF CookBook 第3巻」プリント版発売しました。また、全文をWebで公開しています。

電子の紙PDFを企業向けのシステムの中で編集したり、加工したりする方法を紹介するPDFの料理本シリーズ『PDF CookBook 第3巻』ができあがりました。

PDF CookBook 表紙

本書は、紙版をアマゾンなどからプリントオンデマンドで販売、PDF版(ダウンロード)はアンテナハウスのオンラインストアから販売、HTMLはPDF Tool APIのWebページにて全文を公開しています。

『PDF CookBook 第3巻』ではPDFからテキストを抽出・検索する機能、PDFから画像の抽出・画像の最適化、矩形内のデータ削除と塗りつぶし(墨消し)、フォントの統合・埋め込み、PDFの最適化、PDFにレイヤーを追加する機能など豊富なテーマを扱います。

各機能の解説・役割や目的、見込まれる効果の紹介、PDF Tool APIによるサンプルプログラム、処理実行例を紹介しています。PDFを扱うプログラマーはもちろんですが、企画・営業担当の方でもPDFの豊富な機能や使い方についての知識やアイデアが得られるでしょう。

目次
はじめに
第1章 テキストの抽出・検索
1.1 テキスト抽出
1.1.1 ページから全テキスト抽出
1.1.2 指定矩形からテキストを抽出
1.2 テキスト検索
1.2.1 キーワードの指定による検索
1.2.2 検索オプションの指定:検索対象文字列のオプション
1.2.3 検索オプションの指定:取得順序
1.2.4 検索オプションの指定:同一行とみなす文字の重なり
第2章 画像の抽出・最適化
2.1 画像抽出
2.1.1 画像個数の取得
2.1.2 指定した画像を抽出
2.1.3 出力画像形式の指定
2.1.4 画像の大きさ、解像度を取得
2.2 画像の最適化
2.2.1 カラー画像最適化オプションの取得・指定
2.2.2 グレースケール画像最適化オプションの取得・指定
2.2.3 モノクロ画像最適化オプションの取得・指定
2.2.4 ダウンサンプリング方法の指定
2.2.5 最適化を行う画像の対象とするフィルターの指定
2.2.6 ダウンサンプリングする画素数の指定
2.2.7 ダウンサンプリング率の下限値の指定
2.2.8 ダウンサンプリング対象の画像をPPIで絞り込む
2.2.9 ダウンサンプリング後のPPI を指定する
2.3 JPEG 圧縮
2.3.1 JPEG 圧縮設定
第3章 矩形内のデータ削除
3.1 マスクの特性
3.1.1 マスクの色
3.1.2 マスクの不透明度
3.2 削除する対象
3.2.1 テキスト:矩形内の文字を削除
3.2.2 テキスト:削除時オプションの指定
3.2.3 画像:矩形内の画像データを部分削除
3.2.4 図形:矩形内にパスデータ全体が含まれる場合に削除
3.3 テキスト検索:マスク処理
3.3.1 テキスト検索とマスク処理の組み合わせ
第4章フォントリソース
4.1 フォントの統合と埋め込み
4.1.1 フォントの統合
4.1.2 フォントの埋め込み
第5章 PDF の最適化
5.1 画像の最適化
5.1.1 画像の最適化
5.2 不要なデータの削除
5.2.1 オープンアクションの削除
5.2.2 しおりの削除
5.2.3 注釈・フォームの削除
5.2.4 アーティクルの削除
5.2.5 サムネールの削除
第6章 レイヤー作成
6.1 レイヤーの作成・追加
6.1.1 レイヤーに使用するPDF 文書ページを設定
6.1.2 レイヤーの名前の指定
6.1.3 レイヤーの不透明度の指定
6.1.4 回転角度の設定
6.1.5 レイヤーのZ オーダーの指定
6.1.6 レイヤーの表示/非表示の指定
索引

紙版(プリントオンデマンド)
出版社: アンテナハウスCAS電子出版
発売日:2018年10月下旬(予定)
サイズ:B5判 横組み
ページ数:126ページ
価格(税込):1,728円
ISBN:978-4-900552-64-7
販売店:アマゾン(10月22日発売予定)

デジタル版(PDF)
販売形式:PDF版(DRMなし)
ページ数:126ページ
価格(税込み):864円
販売店:アンテナハウス・オンラインショップ(PDFのダウンロード)

HTML版
Webで全文公開中

シリーズ既刊本紹介ページへのリンク
『PDF CookBook』
『PDF CookBook 第2巻』
『PDF CookBook 第4巻』


『PDF Cook Book』シリーズ PDF Tool APIを使うPDFの料理法 のご紹介

PDFの料理本『PDF CookBook』(4月発売)および『PDF CookBook第2巻』(6月発売)は、PDF Tool API V5のクラスライブラリーを使ってできるPDFの様々な加工法を紹介しています。

『PDF CookBook』
PDFのページ編集(PDFの分割・結合・ページの回転)、ページサイズ、方向および余白の変更、PDFのページにテキスト・画像・PDFを貼り付けなどを中心に解説・活用例とプログラム例を解説しています。詳細はこちらへどうぞ

出版社: アンテナハウスCAS電子出版
発売日:2018年4月
著者:アンテナハウス株式会社
販売形式:プリントオンデマンド版
サイズ:B5判 横組み
ページ数:124ページ
価格(税込):1,728円
ISBN:978-4-900552-60-9
販売店:アマゾン(POD版)(4月6日発売)、その他Web書店で発売予定

販売形式:PDF版(DRMなし)
ページ数:122ページ
価格(税込み):864円
販売店:アンテナハウス・オンラインショップ(PDFのダウンロード)

『PDF CookBook第2巻』
PDFのセキュリィティ(パスワードセキュリティ)、閲覧制限、透かし、しおりなどについて等を中心に解説・活用例とプログラム例を解説しています。詳細はこちらへどうぞ

出版社: アンテナハウスCAS電子出版
発売日:2018年6月中旬
著者:アンテナハウス株式会社
販売形式:プリントオンデマンド版
サイズ:B5判 横組み
ページ数:126ページ
価格(税込):1,728円 6月18日アマゾンで発売になりました。
ISBN:978-4-900552-61-6
販売店:アマゾン(POD版)その他Web書店で発売予定

販売形式:PDF版(DRMなし)
ページ数:126ページ
価格(税込み):864円 6月8日発売
販売店:アンテナハウス・オンラインショップ(PDFのダウンロード)※PDF版のダウンロードは自社ストアのみです。


AH Formatter:PDFから複数行のテキストをコピペしたときに、不要な改行を避けるには。

こんにちは
AH Formatter』サポート担当です。

『AH Formatter』で作成した PDF をビューアで表示して、
テキストをコピー&テキストエディタなどにペースト(以下コピペ)した時に
改行が入ってしまうというお問い合わせをいただくことがあります。

具体的には、
 <fo:block>AH Formatterはアンテナハウス株式会社の製品です。</fo:block>
 <fo:block>最新版は弊社Webサイトからダウンロードできます。</fo:block>

これを組版した結果が以下のような場合
 組版結果
ここを Adobe Acrobat や Adobe Reader からコピペすると
次のようになります。

 AH Formatterはアンテナハウス株式会社
 の製品です。
 最新版は弊社Webサイトからダウンロー
 ドできます。

このように見た目のまま、改行されてしまっていますね。

データ中に改行コードが挿入されているわけではないので
この結果は PDFビューアに依存します。
別の PDFビューアでは

 AH Formatterはアンテナハウス株式会社 の製品です。 最新版は弊社Webサイトからダウンロー ドできます。

こんな風にひとつの連続したテキストでコピペされる場合もあります。
(改行位置に空白が入っています。)

では、”コピペした時に改行されないようにしたい” 場合はどうすればよいのでしょう。

PDFビューアに依存するので一概には言えないのですが
Adobe Acrobat や Adobe Reader の場合には
『AH Formatter』から “タグ付きPDF” として出力すると
次のようにコピペできます。

 AH Formatterはアンテナハウス株式会社の製品です。
 最新版は弊社Webサイトからダウンロードできます。

こうすれば、元のテキストデータと同じように連続したテキストとしてコピペできます。
ただし、ひとつ注意することがあります。
例えば、下記のような場合です。

<fo:block linefeed-treatment=”preserve” >
 XfoObj axfo = null;
 try {
 axfo = new XfoObj();
 ErrDump eDump = new ErrDump();
 axfo.setMessageListener(eDump);
 axfo.setDocumentURI(args[0]);
 axfo.setOutputFilePath(args[1]);
 axfo.setExitLevel(4);
 axfo.execute();
 }
</fo:block>

マニュアルのソースコード説明などでよくあるケースですが、
ひとつの fo:block にまとめて記述して、
linefeed-treatment=”preserve” で改行コードを有効にした場合です。

AH Formatterでの組版結果は以下のようになります。
 組版結果

このような場合、タグ付けしていない PDF では見た目のまま改行してコピペされますが
タグ付きPDF として出力してコピペすると
fo:block内のテキストはひとつの連続したテキストになってしまいます。
したがって、1行ずつ fo:block で分割する必要があります。

 


PDFのレイヤー

PDFには、レイヤーという便利な機能があります。
レイヤーは、PDFの内容をまとめて、表示を切り替えたり印刷を切り替えたりします。 Acrobatでは次のようなダイアログでコントロールします。

layer-dialog

AH Formatter には、このレイヤーを出力する機能があります。
今回は、PDFのレイヤーでの言語指定について取り上げます。

レイヤーで指定した言語は、どのように振る舞うのでしょうか。
仕様では次のように書かれています(PDF 32000-1:2008)。

Language dictionary (Optional) A dictionary specifying the language of the content controlled by this optional content group. It may contain the following two entries:

Lang (required) A text string that specifies a language and possibly a locale (see 14.9.2, “Natural Language Specification”). For example, es-MX represents Mexican Spanish.
Preferred (optional) A name whose values shall be either ON or OFF. Default value: OFF. it shall be used by conforming readers when there is a partial match but no exact match between the system language and the language strings in all usage dictionaries. See 8.11.4.4, “Usage and Usage Application Dictionaries” for more information.

Language については、次のようにも書かれています。

Language: This category shall allow the selection of content based on the language and locale of the application. If an exact match to the language and locale is found among the Lang entries of the optional content groups in the usage application dictionary’s OCGs list, all groups that have exact matches shall receive an ON recommendation. If no exact match is found, but a partial match is found (that is, the language matches but not the locale), all partially matching groups that have Preferred entries with a value of ON shall receive an ON recommendation. All other groups shall receive an OFF recommendation.

PDFに指定されたLanguageは、アプリケーションの言語と地域に基づくと書かれています。アプリケーションとは、PDFのビューア、例えばAcrobatのことです。アプリケーションがレイヤーをサポートしていなければ、もちろん何も起こりません。Acrobatはサポートしています。

PDFに、日本語用のレイヤーと英語用のレイヤーを用意しておけば、アプリケーションの言語によって自動的に一方が表示され、他方が表示されないということができます。では、アプリケーションの言語とは何でしょう。仕様書中でそのことについて書かれている部分はありません。
そこで、どうすれば言語によるコントロールが意図どおりにできるのかを、Acrobatを用いて、試行錯誤を交えながらいろいろ探ってみました。

PDFには、Catalog辞書に言語を明示することができます。これは、文書のプロパティで確認することができます。AH Formatter では、<fo:root> に記述した言語がそこに反映されます。

<fo:root ... xml:lang="ja" ...>

property-dialog

アプリケーションの言語とは、これのことでしょうか。
いいえ、この言語はレイヤーの言語とは関係ありません。
これは、PDFの言語であってアプリケーションの言語ではありません。
アプリケーションの言語とは、Acrobatでは環境設定の言語環境にあるアプリケーションを表示する言語に対応することがわかりました。

lang-env

では、アプリケーションの言語は、具体的にはどう表記されているのでしょうか。14.9.2.2 Language Identifiers には次のような記述があります。

A language identifier shall either be the empty text string, to indicate that the language is unknown, or a Language-Tag as defined in RFC 3066, Tags for the Identification of Languages.

Although language codes are commonly represented using lowercase letters and country codes are commonly represented using uppercase letters, all tags shall be treated as case insensitive.

ざっくり言えば、PDFに書かれるLangの値は、RFC 3066 に従っていて大文字小文字は区別しない、ということです。RFC 3066 の言語コードは ISO 639、国コードは ISO 3166 によります。アプリケーションの言語も、ISO 639 と ISO 3166 で表現されているはずです。
実際にAcrobatでアプリケーションを表示する言語を変更すると、どこにどういう情報が書かれるのかはわかりませんでした。しかし、日本語なら ja とか ja-JP などが設定されると、常識的には予想するでしょう。

Preferredを指定していないと、Langに指定したものとアプリケーションの言語の間では完全一致性が判断されることになっています。そこで、日本語環境のとき、どういう指定をしたら完全一致するのかを調べました。

  • ja ⇒ NG
  • jpn ⇒ NG
  • ja-JP ⇒ NG
  • jpn-JP ⇒ NG
  • jpn-JPN ⇒ NG
  • ja_JP ⇒ NG
  • jpn_JP ⇒ NG
  • jpn_JPN ⇒ NG
  • ja-jp ⇒ OK

結果は、まったく想定外でした。仕様には大文字小文字区別しないと明記してあるし、国コードは大文字で表記するのが普通とも明記されています。これはどういうことでしょうか。Acrobatは仕様どおりに動作しているようには見えません。Acrobatの不具合なんでしょうか。仕様の見落としがあるのでしょうか。

完全一致させるのにこんな試行錯誤した上、それが正しいのかどうか裏づけも取れないのでは、完全一致を使うのは現実的ではない気がします。Preferredを指定すると、かなりあいまいな指定でもマッチします。
日本語は、それを話す国は日本しかないですが、英語やポルトガル語スペイン語などはそんなことはありません。例えば、en-US(米国英語)と en-GB(英国英語)を区別したいこともあるはずです。Preferredでは、それらを区別させることはできませんでした。どちらもすべての en にマッチしてしまうようです。つまり、国コードを明示したいなら、Preferredを指定できないということになります。

次に Preferred な ja と、そうでない ja-jp の指定を混在させたらどうなるか見てみます。
日本語環境ではどちらも表示されそうなものですが、ja-jp の方だけ表示されて、ja は表示されません。完全一致するものが見つかったらそれしか表示されない、ということになっているからのようです。このことは、en-US と en-GB を用意し、両者の共通部分を en として表現したくても、できないということを意味します。

AH Formatter V6.4 では、次のようにレイヤーへの言語指定を行ないます。
実際には重なり合った領域に内容を配置するでしょうから、<fo:block-container> などを利用することになります。

<?xml version="1.0"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
         xmlns:axf="http://www.antennahouse.com/names/XSL/Extensions"
         axf:layer-settings="'Japanese layer' lang 'ja' preferred,
                             'English layer' lang 'en' preferred">
...
<fo:block axf:layer="'Japanese layer'">
こんにちは
</fo:block>
...
<fo:block axf:layer="'English layer'">
Hello
</fo:block>
...

AH Formatter V6.4 MR3 以降を利用してください。

 


Pages: 1 2 3 4 5 Next