« 2006年10月 | メイン | 2006年12月 »
2006年11月30日
「書けまっせPDF2」、「アウトライナー」2製品を発表
アンテナハウスは、本日、「書けまっせPDF2」と「アウトライナー」の2製品を12月下旬から発売すると発表しました。
１．「書けまっせPDF2」は、各種の用紙PDFに文字、数字、図形を簡単に書き込むソフトウエアで、いわば電子の紙PDFのための鉛筆に相当します。同名製品のバージョンアップ版ですが、初版をお使いいただいた方々のご意見を頂戴し、フルモデルチェンジに匹敵する大幅な改良を施しました。
【詳細情報】
・ニュースリリース
・製品Webページ
２．「アウトライナー」は、既存PDFに、しおりや目次を簡単に付けて、仕上げるためのソフトウエアです。
【詳細情報】
・ニュースリリース
・製品Webページ
アドビの製品を含めて、PDF関連のソフトは、非常に沢山あります。ただ、日本の国内とりわけ国産ソフトでみますと、どうも、PDF作成用がかなり多くなっていて、作成に加えて多少PDFの加工ができるようになっている程度ではないかという印象を持っています。
また、PDF編集ソフトにしても、アドビのAcrobatが、一種のベンチマークのような存在になっていて、いってみれば、（１）Acrobatでできることができるかどうか？（２）Acrobatよりも安価にできるかどうか？（３）Acrobatと比べ使い勝手はどうか？というような観点での比較が多くなっているように思います。
では、Acrobatという製品は、全てを網羅して、その機能で十分か、といいますと、決してそのようなことはありません。「電子の紙PDFを、本当の紙のように簡単・便利に使いこなしたい。」という観点で考えますと、Acrobatでは、まったく不十分な部分が多いのではないかと思います。
そのあたりを、いくつかの観点で追及していって、要するに「Acrobatでできないことで、より便利なPDFを提唱しよう」というのが、今回、発表しました製品の基本的な開発意図ということになります。
では、実際にどうか、ということにつきまして、続けて、具体的にご紹介してみたいと思っています。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月29日
PDF Reference 1.7の変更点の検討(3)
次に、本文の項レベルでの変化をチェックしてみます。
2章 概要は、2.1節、2.2節とも項レベルの変更はありません。
3章 シンタックスは、3.1節～3.10節までありますが、3.8.1項が変更になっています。
PDF Ref 1.6では、3.8.1 TextStringでした。
PDF Ref 1.7では、3.8.1 String Typesに変更になり、下位に、Text String Type, PDFDocEncoded String, Byte String Type という見出しが新しくできています。
4章 グラフィックスは、変更ありません。
5章 テキストは、変更ありません。
6章 レンダリングは、変更ありません。
7章 透明も変更ありません。
8章 対話機能
8.2.4 コレクションが追加になっています。これは昨日の、PDF1.7の特徴のドキュメントのナビゲーション機能の追加に相当します。
8.7.1 の署名の互換性のPKCS#7にRevocation Informationの見出しが追加。
それから、以前にも言いましたが、8.9節が新設されています。
9章 マルチメディアは、9.5の3次元作品の項がだいぶ強化されています。
10章 ドキュメント交換では
10.7節タグ付きPDFの
10.7.4標準構造属性の下に、印刷フィールド属性という見出しが新設されました。
こうしてみますと、大体、1.2節にPDF 1.7での新機能の説明の内容と同じになっています。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月28日
PDF Reference 1.7の変更点の検討(2)
昨日に続いて、PDF Referernce 1.7 での新機能の紹介です。
1.2.4 ドキュメントのナビゲーション機能
複数の添付ファイルをひとつのウインドウで表示するポータブル・コレクションと呼ぶ機能を追加。これは、電子メールのアーカイブや写真のコレクションなどを提示するのに使えます。
1.2.5 セキュリティ関連機能
電子署名関係の機能を強化しました。
また、後方互換性を実現するため、PDFの消費（利用）アプリケーションが備えているべき項目を要求できるようにしました。
1.2.6 一般機能
様々なプラットフォームの使用を推進するため、指定する文字の符号化を説明するための文字型をより明確に。ファイルのパスの文字列に、プラットフォームの標準のほか、Unicode文字列を使用できるようにしました。
1.4 知的所有権
ここは大幅に書き換わっています。簡潔になりましたが、著作権や特許をアドビが保有していることがはっきりと書いてあります。ただし、特許については、
Adobe desires to encourage implementation of the PDF computer file format on a wide variety of devices and platforms, and for this reason offers certain royalty-free patent licenses to PDF implementors worldwide.
とありますので、世界中のPDFの実装者には無償の特許使用権を提供するとあります。certain （ある一定の）の詳細はこちらです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月27日
PDF Reference 1.7の変更点の検討
次に、PDF Reference 1.7 の変更点について、順次チェックしてみます。
最初に、前書きですが、面白いことに、PDF Referenceには、「A significant number of third-party developers and systems integrators offer customized enhancements and extensions to Adobe’s core family of products. Adobe publishes the PDF specification in order to encourage the development of such third-party applications.」という段落がありましたが、これが、ごっそり削除されています。
つまり、アドビがPDF Referenceを公開する目的として、サードパーディがアドビのコア製品ファミリに対して、機能強化・拡張するのを奨励する、ということが以前は謳われていましたが、その項目が削除されたということです。もう、アドビAcrobatのサードパーティはお役ご免らしいですね。
でも、こういう変更して、日付が2004年11月のままとは？過去に遡って方針変更するてことかな？
この本についての節（1.1About This Book）の、次の段落は、もちろん、残っています。
This book provides a description of the PDF file format and is intended primarily for developers of PDF producer applications that create PDF files directly. It also contains enough information to allow developers to write PDF consumer applications that read existing PDF files and interpret or modify their contents.
この段落が削られたら、その時は、PDF ReferenceがPDF開発者の聖書ではなくなる時です。Microsoftもそうですが、米国のソフトハウスは、基本的な方針転換を平気でやるので、注意しなければならない、と思っています。
1.2節にPDF 1.7での新機能が紹介されています。
1.2.1 3次元の作品の表示機能
オリジナルの3次元作品やJavaScriptを使わずに表示制御ができます。3次元の作品を後で適切に見せるための3次元の見栄えについてのマークアップ注釈ができます。アニメーションの制御ができます。
1.2.2 対話機能について
テクニカル・コミュニケーション(TC)とレビュー向け、リーガル設定向けのマークアップ注釈を強化しました。
具体的には、TC用としては、多角形、折れ線についてのマークアップ注釈で、次元、単位、拡大縮小などを意図する機能を追加、など。
リーガル向けでは、用紙選択、印刷処理、ページ範囲などの印刷特性のためのビューア設定の注釈を追加。
1.2.3 アクセシビリティ
TaggedPDFの次のような強化でページ内容の種類の役割を認識できます。
・フォームフィールドの役割
・表の要約の提供
・ページ全体の背景色などの背景の識別
・ウオーターマークやヘッダ、フッタの識別
（つづく）
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月26日
PDF Reference 1.7 で追加された内容
さて、昨日、PDF Referernceは、1.6から1.7にかけて、64ページ増えただけということを紹介しました。
実際、Planet PDFには、編集者への手紙というタイトルで、「Acrobat 8は近年のもっとも弱いバージョンアップ」という意見が紹介されています。
それについては、2006年09月30日 Acrobat 8とPDFのファイル形式でも、アドビの担当者のブログで紹介しています。
具体的に、PDF Referenceの1.6から1.7で実際にどのあたりが変わったのか、チェックしてみましょう。
まず、章立てですが、これはまったく変わっていません。
節が増えたのは、本文では、8章 Interactive Featuresの8.9 Document Requirements (pp. 751～753)のみです。この節では、PDF 1.7では、PDF作成アプリケーションはPDF作成時に、そのＰＤＦを利用するアプリケーションが、ＰＤＦを正しく処理するために持っていなければならない機能を規定できる、ということを書いてあります。
付録では、D.2 PDFDocEncoding Character Set ( pp. 1001～ 1009)
G.7 Structured Elements That Describe Hierarchical Lists (pp. 1082～ 1090)
のみです。
D2は、 PDFDocEncodingという独自の符号化文字集合です。PDFDocEncodingは、PDF の最初のころからあったと記憶していましたので、おかしいな、と思いましたが、新しく追加されたのは、PDFDocEncodingとUnicodeの対応表ですね。
（ついでに、この表見ていて、先頭のほうの文字が正しく表示されていないことに気がつきました。
PDF ReferenceはFrame Makerで作っているのですが、FrameMakerじゃ無理なんじゃないのかな。）
G.7は、階層リストを表現する構造要素についてのサンプルです。
ですので、新しく追加された節は、実質的に8.9のみでしょう。
なお、ページ数でみますと、9.5 3D Artwork 789が、29ページほど増えていますので、ここが一番分量的には増えているようです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月25日
PDF Reference 1.7が出ています
アドビのホームページにPDF Reference の第6版（PDF 1.7)がアップされています。
PDF Reference, Sixth Edition, version 1.7
今回の版は、総ページ数1310ページ。前版PDF 1.6が1236ページですので64ページの増加となります。
ところがファイルサイズが、PDF 1.6が8.86MB なのに、PDF 1.７は、30.93MBと約3.5倍になっています。
これは、なぜなのかと思い、チェックしてみましたところ、PDF 1.7は、タグ付きPDFになっています。PDF 1.6はタグが付いていません。ですので、このファイルサイズの違いは、ほとんどタグ付きPDFに変更したためと思います。
※タグ付きPDFとは、PDF内部に文書の構造情報を持たせるための情報を付け加えたもの。スクリーン・リーダでPDFの文章を読み上げる順序を正しくすることができますので、PDFのアクセシビリティを実現するための技術として使われます。
PDF Referenceもタグ付きPDFに変更とは、いよいよ、米国ではタグ付きPDFが標準になるということなんでしょう。
アンテナハウスのXSL Formatterも、海外のお客さんから、タグ付きPDF出力機能の要求が頻繁になり、漸く今年の4月のV4.0からタグ付きPDF出力機能をつけたばかりです。このときも、タグ付きPDFを作るとファイルサイズが大きくなるので気になっていたのですが。
ちなみに、XSL Formatterのサンプルページの「XMLからXSL-FOに変換するためのXSLTスタイルシートの作成方法」という７１ページの文書で比較してみますと、次のようになります。
・タグ付きPDFで作成すると： 1,742KB
・タグ付きでないPDFでは ： 871KB
この場合は、大体２倍になっています。ファイルサイズがむやみに大きくなると、ただでさえ、重いPDFがますます重くなって不評になると思うのですが、それを犠牲にしてでもタグ付きにしなければならない時代になるのでしょうね。
タグ付きPDFには、PDF文書が構造情報を含んでいるので、PDFからWordに変換する際、再現性が良くなるだろうというメリットもあります。日本でもタグ付きPDFが普及するまでに、PDFからOfficeへのコンバータもタグを使って変換できる機能を強化しなければならなくなりそうです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月24日
PDFのセキュリティ機能（8）—まとめ
PDFの標準セキュリティ機能について、11月1日から11月19日にかけてお話しました内容をまとめてみました。
仕様書を読みながら、いろいろ書いていくうちに、ブログの連載の最初の方でお話しました内容が少し間違っていることに気が付きましたので、そのあたりも訂正してあります。
もし、皆様のお時間が許すようでしたら、まとめの方をお読みになっていただければと思います。
お恥ずかしいですが、時間もありませんので、ブログの方は訂正していません。書き直すと限りもないことですし。
ところで、本日、24日は、「リッチテキストPDF2 D&D」パッケージ版が、全国一斉発売の日です。こんな感じのパッケージです。どうぞ、よろしくお願いします。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月23日
TextPorter V4.1 をリリース
アンテナハウス株式会は、11月22日から テキスト抽出ソフト「TextPorterV4.1サーバ版」の出荷を開始いたしました。
本製品は、PDFを含む、様々なアプリケーション専用フォーマットのファイルからテキストを抽出するソフトウェアです。
V4.1で新たに抽出対象とした対応ファイルフォーマットは、次の3種類です。
* 一太郎2006
* OutLook2000/2003(*.msg)
* OutLookExpress6(*.eml)
また、V4.1では次の機能を追加しました。
* JIS X0213文字集合の抽出に対応しました。
* 抽出元がテキストファイルの場合、これまでは、抽出対象外としてエラーを返していました。V4.1ではエラーを返さずに指定した文字符号化方式に変換ができるようにしました。
* パス名の長さ制限の解除しました。
（現在256byteまでの制限を解除し、OSがサポートしている長さまで保証）
* ファイルサイズ2GBの制限を解除しました。
（OSがサポートしているサイズまで保証）
* PDFテキスト抽出エンジンを強化致しました。
（さまざまなPDFツールから作成されたPDFに対応しました。さらに安定性を格段と改善致しました。）
特に、PDFにつきましては、PDF 1.6で新しく追加されたAES暗号でセキュリティを設定したファイルからの抽出が、パスワードを入力することで可能になりました。
特に、最近は、PDF作成ソフトの種類が増えていることもあり、今回のバージョンアップでは、PDF抽出エンジンを抜本的に作り変えて、できるだけ多くの種類のPDF作成ソフトで作成したPDFから、安定してテキストを抽出できるようにしたのが特徴です。
■対応OS
(1) 下記の32ビットOS版は出荷中です。
# Microsoft Windows95/98/Me/NT4.0/2000Professional/2000Server/XP/2003Server(32bit)
# Sun SPARC 版Solaris 7/8/9/10 (32bit)
# Linux gcc version 3.2.3 以上（32bit)（動作環境にlibstdc++.so.5が必要）
(2) 64ビットOS版を含む下記のOSにつきましては、今後、順次リリースする予定です。
* Microsoft WindowsNT4.0/2000Professional/2000Server/XP/2003Server(64bit)
* Sun SPARC 版Solaris 7/8/9/10 (64bit)
* Intel版 Solaris 10(64bit)
* Linux gcc version 3.2.3 以上（64bit)（動作環境にlibstdc++.so.5が必要）
* IBM AIX 5L version5.2 (32bit)（動作環境に VAC++6.0ランタイムライブラリが必要）
■お問い合わせ先
エンドユーザ、リセラーのお客様は： sis@antenna.co.jp
OEMのお客様は： oem@antenna.co.jp
■詳細情報
http://www.antenna.co.jp/axx/
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月22日
電子行政とPDF (3)
「オンライン利用促進のための行動計画」の各省庁のデータを見ていまして、もうひとつ気が付いたことは、電子申請の際に、本人認証の手段として、電子署名を要求しているものの利用度合いが少ない、ということです。
逆に、よく使われているものは、ほとんどパスワード認証方式になっています。
昨日の、オンライン化率の高い、上位10位はすべて、パスワード方式の認証方法になっています。それに対して、利用されていないとした、税務、保険・年金、自動車関係の手続きは、すべて本人認証に、電子署名を要求しています。
行動計画に上がっている申請手続きは全部で169項目あります。この中で、私が分類した限りでは、オンラインによる申請で電子署名を必要とするものが134項目、必要としないものが29項目、その他（よく分からないもの含む）が6項目となっています。
それぞれについて、オンラインの利用状況を集計しますと、次の表のようになります。これを見ますと、電子署名を必要とする申請の利用率が非常に低くなっていて、電子署名が大きな障害になっているのではないかと思われます。
| 分類 | 手続きの数 | 年間処理件数 | オンライン利用実績 | オンライン利用率 |
|---|---|---|---|---|
| 電子署名を必要とする申請手続き | 134 | 239,263,300 | 480,647 | 0.2% |
| 電子署名を必要としない | 29 | 342,466,000 | 73,457,230 | 21.4% |
| 両方または不明 | 6 | 78,273,000 | 7,074,572 | 9.0% |
| 合計 | 169 | 660,002,300 | 81,012,449 | 12.3% |
ところで、電子署名を必要としない申請手続きの中では、法務省の「不動産登記に係る登記事項証明書等の交付請求手続等」が年間利用件数2億84百万件と83%を占めているのですが、このオンライン申請の利用は21百万件、利用率7.6%となっています。この利用率を高めさえすれば、電子署名を必要としない手続きは、軽く50%を超えると思います。そうしますと、この対策が目標達成のひとつの鍵になりそうです。
法務省のWebページオンラインによる登記事項証明書の送付請求（不動産登記関係）についてには、その手続きが書いてあります。
ですが、この説明の中に、電子申請の準備には、電子署名が必要と書いてあります。
ご利用方法 事前準備のステップ4
で、ステップ４ 電子署名（デジタル署名）に必要な申請者の電子証明書の取得を見ますと、
不動産登記関係手続、商業・法人登記関係手続、債権譲渡登記関係手続および情報公開関係手続の一部については、電子署名を行うことなく、オンラインによる申請が可能です。
と書いてあります。う～～ん。電子署名が必要なのか必要でないのか、良く分かりませんね。もう少し分かりやすくできないものでしょうか。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月21日
電子行政とPDF (2)
さて、この行政における申請の電子化の状況の表を眺めていまして、幾つか、気が付きました。
１．オンライン化率が高いのは物品の取り扱いに関する許可申請の類である。
手続きがオンラインで行われている比率が高いものを上位から10位を並べますと次のようになります。
| 省庁名 | 対象手続き | 年間平均申請件数 | オンライン利用件数 | 利用率 |
|---|---|---|---|---|
| 財務省 | № 12 輸出申告 | 13,535,000 | 13,359,000 | 98.7% |
| 財務省 | № 11 輸入（納税）申告（輸入許可前引取り承認申請を含む。） | 31,721,000 | 30,898,000 | 97.4% |
| 農林水産省 | № 3 採補数量等の報告 | 231,000 | 215,000 | 93.1% |
| 財務省 | № 10 保税運送（包括）承認 | 767,000 | 700,000 | 91.3% |
| 財務省 | № 3 貨物の積卸しについての書類の呈示 | 1,819,000 | 1,597,000 | 87.8% |
| 農林水産省 | № 2 輸入植物等の検査の申請 | 335,000 | 285,000 | 85.1% |
| 厚生労働省 | № 1 食品等の輸入の届出 | 1,716,000 | 1,425,400 | 83.1% |
| 財務省 | № 6 外国貨物仮陸揚の届出 | 630,000 | 521,000 | 82.7% |
| 財務省 | № 14 積卸コンテナー一覧表の提出 | 203,000 | 151,000 | 74.4% |
| 農林水産省 | № 1 指定検疫物の輸入届出 | 206,000 | 151,000 | 73.3% |
これは、輸出入などの物品の取り扱いを行う企業(業者)と、役所との間でのオンライン化が進んでいることを示しているものと思います。
２．多くの国民に関係が深いと思われる、税務、保険・年金、自動車は、まったくオンライン化が進んでいない。
・財務省の国税電子申告・納税システム（e-Tax)のオンライン化率は0.2%
・厚生労働省電子申請・届出システム（No.2～No.4）のオンライン化率は0.0%
・厚生労働省 労働保険適用徴収・電子申請システムのオンライン化率は0.0%
・厚生労働省 労働保険適用徴収・電子申請システム、厚生労働省電子申請・届出システム（グループ申請）のオンライン化率は0.2%
・厚生労働省電子申請・届出システム（No.10～No.77）のオンライン化率は0.0%
・自動車保有関係手続のワンストップサービスシステムのオンライン化率は0.0%
と、まったく、目を覆いたくなるような惨敗といえるような数字です。この状態ではこれらの申請オンライン・サービスの利用率はどう考えても、2010年に50%達成は無理ではないかと思ってしまいます。
昨日、松下幸之助の「商売は真剣勝負」（PHP文庫）という本を読んでいましたら、最初に立てた目標を達成できない、”こと志に反する”のは、自ら省みて自己認識ができてないからだ、という一文がありました (pp.163 ～169) 。「税務、保険・年金、自動車」関係のオンライン申請のケースでは、目標自体に無理があるか、あるいは、本当に目標が重大ならば、やり方を抜本的に変更しないと目標を達成することができないんじゃないでしょうか。政府は業者に対しては権力を振りかざして強制・指導はできても、一般国民まで強制はできない、ということについて自己認識が足りないのではないでしょうか。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月20日
電子行政とPDF
さて、PDFとは電子の紙、そうなりますと、行政システムの申請書などが紙から電子化される際にも、PDFが大きな役割を果たすことが期待されます。そこで、実際のところ、いま、どんな状況なのかを少し調べてみることにしました。
政府は「ＩＴ新改革戦略」として「世界一便利で効率的な電子行政」をスローガンに掲げています。「利便性・サービス向上が実感できる電子政府・電子自治体を実現するとして、国・地方公共団体に対する申請・届出等手続におけるオンライン利用率を2010年度までに50％以上とするという目標を定めていることはご存知の方も多いと思います。
総務省のホームページに行きますと、「オンライン利用促進のための行動計画」が公開されています。
PDFファイルで、主要な省庁の行動計画が出ています。
この中でまず、各省庁の電子申請に関するシステムとその利用状況がでていますので、私なりに、これをまとめてみました。
| 省庁名 | システム名 | 年間平均申請件数(合計) | 利用実績(合計) | 利用率 |
|---|---|---|---|---|
| 金融庁 | 電子申請・届出システム | 437,000 | 209,000 | 47.8% |
| 総務省 | 総務省電波利用 電子申請・届出システム | 178,000 | 15,989 | 9.0% |
| 総務省 | 行政相談の申出 | 185,000 | 720 | 0.4% |
| 法務省 | オンライン手続のサービス、登記情報提供サービス | 380,078,000 | 28,637,673 | 7.5% |
| 法務省 | 乗員上陸許可支援システム | 1,200,000 | 304,000 | 25.3% |
| 財務省 | ＮＡＣＣＳ、ＣｕＰＥＳ | 50,440,000 | 47,795,200 | 94.8% |
| 財務省 | 国税電子申告・納税システム（e-Tax)ホームページ | 69,234,000 | 148,637 | 0.2% |
| 厚生労働省 | 輸入食品監視支援システム | 1,716,000 | 1,425,400 | 83.1% |
| 厚生労働省 | 厚生労働省電子申請・届出システム（№ 2 就業規則（変更）届出、№ 3 1年単位の変形労働制に関する協定届、 № 4 時間外・休日労働に関する協定届） | 1,303,000 | 376 | 0.0% |
| 厚生労働省 | 労働保険適用徴収・電子申請システム | 4,114,000 | 1,887 | 0.0% |
| 厚生労働省 | 労働保険適用徴収・電子申請システム、厚生労働省電子申請・届出システム（グループ申請） | 486,000 | 796 | 0.2% |
| 厚生労働省 | 厚生労働省電子申請・届出システム（No.10～No.77） | 141,743,800 | 10,620 | 0.0% |
| 農林水産省 | 動物検疫検査手続電算処理システム（ANIPAS） | 206,000 | 151,000 | 73.3% |
| 農林水産省 | 輸入植物検査手続電算処理システム(PQ-NETWORK) | 335,000 | 285,000 | 85.1% |
| 農林水産省 | 漁獲管理情報処理システム | 231,000 | 215,000 | 93.1% |
| 経済産業省 | オンライン手続のサービス（新世代統計システム） | 500,000 | 148,000 | 29.6% |
| 経済産業省 | オンライン手続のサービス（汎用電子申請システム） | 102,000 | 0 | 0.0% |
| 経済産業省 | オンライン手続のサービス（電子出願システム） | 2,400,000 | 1,300,000 | 54.2% |
| 国土交通省 | 特殊車両オンライン申請システム | 127,000 | 7,990 | 6.3% |
| 国土交通省 | 自動車保有関係手続のワンストップサービスシステム | 3,500,000 | 159 | 0.0% |
| 国土交通省 | 汎用受付等システム | 282,500 | 2 | 0.0% |
| 国土交通省 | 港湾ＥＤＩシステム | 1,204,000 | 355,000 | 29.5% |
| 合計 | 660,002,300 | 81,012,449 | 12.3% | |
上の表は中央省庁の主な申請の年間処理件数が出ていますが、これらを合計しますと、1年間に6億6千万件になります。この中で、システムの利用実績（すなわち電子申請処理されているもの）は、8,137万件となります。これは、各省庁の報告にある平成17年の利用実績データを合計したものですが、期間が1年分に満たない項目もあります。そうしますと、ざっくりいって、現在、1年間の申請処理件数の中で、平均15%弱が電子申請を利用して行われているということになります。
※2006/11/20 財務省の数字の転記ミスを発見・訂正。ほんのわずか変更になりました。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月19日
PDFのセキュリティ機能（7）—公開鍵セキュリティ・ハンドラ
PDF Referenceの3.5 暗号化の項には、これまでにお話ししました、パスワード・ベースの標準セキュリティ・ハンドラの他に、3.5.3 公開鍵セキィリティ・ハンドラという、もうひとつのセキュリティハンドラが規定されています。
公開鍵セキィリティ・ハンドラは、公開鍵暗号化技術を使ってPDFにセキュリティをかける方式です。
公開鍵暗号化技術については、いろいろなところで解説されていますが、ざっとまとめて見ますと次のようになると思います。
例えば、AとBの2者間で、公開鍵暗号化方式を使って暗号化通信を行おうというときの順序は、
１．Bは、公開鍵と秘密鍵のペアを用意します。このふたつの鍵は、まったく異なる鍵ですが、一方で暗号化したものは他方の鍵でしか、暗号解除することができないものです。
２．Bは、公開鍵の方をインターネットやメールなどを通じて、公開（Aに渡）します。秘密鍵は、外部に漏れないように保持します。
３．Aは、Bの公開鍵を使って文書を暗号化し、暗号化した文書をBに送信します。
４．Bは、Aから受け取った（暗号化された）文書を、秘密鍵を使って暗号を解除します。
５．うまく暗号が解除できれば、受け取った文書はBの公開鍵で暗号化されたものであることになります。
この通信方式は、電子署名（デジタル署名）とは鍵の使い方が逆になっていることに注意してください。ちなみに、電子署名は、秘密鍵で暗号化したものを相手に渡し、相手は、公開鍵で暗号を解除するものです。
さて、PDFの公開鍵セキィリティ・ハンドラは次のようなことを行うとされています。
(PDF Reference 1.6 pp.104 - 106)
１．PDFの文書コンテンツを暗号化するときに使用する暗号キーの元と、PDFを送信する相手（複数人）のPDFの利用権限（相手によって変えることができます）設定データを用意します。
２．PDFを送信する相手の公開鍵を入手します。複数のときは、公開鍵は相手毎に異なったものになります。
３．１で用意したキーと相手の利用権限設定データを、相手毎に、各人の公開鍵を使って暗号化します。それらの暗号化されたデータをまとめて、受信者データ表として作成します。
４．PDFの暗号化辞書に３で作成した受信者データ表を記録します。
こうして作成した暗号化済PDFを、相手に配信します。
PDFを受け取った相手は、各人の秘密鍵を用いて、受信者データ表の中から暗号キーの元と自分用の利用権限データとを取り出します。この暗号キーの元を使って、PDFの暗号を解いてPDFを閲覧します。この時、自分用の利用権限データが有効になりますので、PDFの配信元が設定した利用権限の範囲内でしかPDFを利用できないことになります。
パスワード方式の標準セキィリティ・ハンドラでは、PDFの受け手によって利用権限を変更することはできないのですが、公開鍵セキィリティ・ハンドラを使うと相手によって利用権限を変えることができます。
なお、PDFの利用権限の設定は、
2006年11月13日
PDFのセキュリティ機能（3）—PDFの利用許可制御で説明しましたものと同じです。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月18日
リッチテキストPDF2 D&D ダウンロード販売サイト追加
今週からリッチテキストPDF2 D&Dのダウンロード販売サイトにベクターに加えて、So-net、Impress、amisoftが追加になりました。
近日中に、楽天、ライブドアでもダウンロード販売する予定です。
また、11月24日（金曜日）には、いよいよ、「リッチテキストPDF2 D&D」パッケージ版を全国のパソコンショップより一斉発売することが決定しました。
「リッチテキストPDF2 D&D」のダウンロード販売サイトのご案内
（11月17日現在）
アンテナハウスは、文書変換一筋20年の経験を生かして、PDFからオフィス文書変換ソフトでは、「いきなりPDF to Data2」や「速攻！PDF to Data」には負けるわけには行きません。なにとぞ、応援、よろしくお願いします。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月17日
Antenna House PDF Driver V3.1 を近くリリース
アンテナハウスでは、PDF Driver V3.1を近くリリースします。PDF Driver V3.1 は、現在、販売しているPDF Driver V3.0に比べて次の点を機能強化しました。
1. 出力PDFにバージョン1.6指定時、AES 暗号化方式を採用します。
2. Web表示用に最適化（リニアライズ）したPDFの出力ができます。
3. 保存先ダイアログを非表示とすることができます。
4. PDF作成時に、空白ページを削除することができます。
AES暗号アルゴリズムについては、昨日、お話しましたが、Antenna House PDF Driver V3.1 では、業界他社に先駆けてPDFの新しい暗号方式であるAESを採用しました。出力PDFのバージョンを1.6に指定し、PDFのオーナーパスワード・ユーザパスワードを設定した場合、AES暗号アルゴリズムでPDFのコンテンツを暗号化します。
第二に、出力するPDFをWeb表示用に最適化（リニアライズ）する機能を追加しました。V3.1からはリニアライズドPDFの出力が既定値になります。PDFをWebで配布する際は、リニアライズされているPDFの方がすばやく内容を確認できますので望ましいと考えます。
海外製のPDFドライバ製品は、多くのものがPDF作成時にリニアライズする機能をもっています。しかし、弊社の調べでは、日本製のPDFドライバには作成するPDFをリニアライズする機能を持っている製品はありませんので、この機能も国産初となります。
第三に、PDFドライバの設定で、保存先フォルダーを予め指定しておくと、それ以降はアプリケーションの印刷メニューからPDFを出力する際に、保存先ダイヤログを表示しないようにできます。これは、特にOEMのお客様から多く寄せられた要望に応えたものです。
最後に、Word、一太郎、ExcelからPDFを作成する際に、空白ページをPDFに出力しないような設定を新設しました。PDF作成時に、ワープロの改ページ機能の関係で、文字が入力されていないページ（空白ページ）ができてしまうことが時々ありますが、このような空白ページをできるだけ作らないようにする機能です。
アンテナハウスPDF Driverは、現在、弊社の製品にバンドルするほか、OEM先の様々なアプリケーションに同梱されて販売しています。評価版もご提供しておりますので、お気軽にoem@antenna.co.jp までお問合せください。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月16日
PDFのセキュリティ機能（6）—AES暗号アルゴリズムの使用
昨日は、PDF 1.6から仕様上、AES（Advanced Encryption Standard)を指定可能になったとお話しました。
AES暗号は、米国が2001年に標準として定めた新しい暗号アルゴリズムです。
AES暗号などによりますと、米国でそれまで使っていた標準暗号方式が、技術進歩により脆弱になったため、世界中から公募した15種類の暗号方式から選択されたもので、最終的にベルギーの研究者が考案したものが採用された、とあります。
従来、PDFで使われていた暗号アルゴリズムRC4は、私企業のプライペートな暗号アルゴリズムであったのに対して、AESは、政府が標準として定めた暗号アルゴリズムであり、仕様書が一般に公開されているのが大きな特徴です。
PDFでも、今後は、AESをサポートするPDF生成ソフト、PDF消費ソフトが増えてくることを期待したいと思います。
Acrobat７のPDFドライバでは、AESが使えませんが、Acrobat７（GUI）では、暗号アルゴリズムとしてAESを設定することができます。
次の図のようにAcrobatでPDFを読んで、セキュリティを設定する際に、互換性のある形式として「Acrobat 7.0およびそれ以降」というカテゴリを選択しますと、AES暗号アルゴリズムを設定することになります。
ただし、注意しなければならないのは、セキュリティ設定時にAESで暗号をかけてしまうと、PDF のリーダソフトの標準セキュリティ・ハンドラがAESに対応していないとファイルを開けなくなることです。
例えば、Adobe Readerの場合、Adobe Reader７では、AES暗号を設定したPDFを開くことができます。
■AES暗号でセキィリティを設定したPDFを、Adobe Reader７で開き、セキュリティ・タブで「詳細情報」を表示
しかし、Adobe Reader6の標準セキュリティ・ハンドラはAES暗号アルゴリズムを内蔵していないため、PDFに正しくない暗号が掛かっている、と誤認してしまいます。
■AES暗号でセキィリティを設定したPDF（上と同じ）を、Adobe Reader6で開こうとするとエラーになってしまいます。
Adobeの製品以外でもPDFを処理する様々な製品があります。現時点では、AES暗号を不用意に使いますと、受け手がPDFの内容を表示することができなくなります。多くのソフトでAES暗号が使えるようになるまでには、少し時間がかかるものと思います。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月15日
PDFのセキュリティ機能（5）—リビジョン４の標準セキュリティ・ハンドラ
次に、標準セキュリティ・ハンドラのリビジョン４について整理してみます。
リビジョン４の標準セキュリティ・ハンドラは、PDF 1.5（Acrobat6）以降で使えます。この標準セキュリティ・ハンドラで追加になっている機能は次の点です。
(１) PDF 1.5の仕様で追加された、暗号フィルター辞書（CryptFilter）機能 — 後述 — を使用できます。
(２) 暗号辞書の中で、PDFの中のストリング、ストリーム、添付ファイルに対して使用する暗号フィルターを個別に指定できます。なお、添付ファイルについてはPDF1.6からとなります。
(３) 暗号辞書の中で、メタデータを暗号化するかどうかを指定できます。なにも指定しないと、メタデータも暗号化しますが、「メタデータは暗号化しない」ようにすることも指定できます。
レビジョン４で追加されたのは、PDFに関するパスワードによるアクセス管理ではなく、むしろPDFコンテンツへの暗号のかけ方をより細かく設定可能にする機能、と言えます。
暗号フィルター辞書とは
暗号フィルター辞書は、PDF 1.5から追加された仕様で、暗号フィルターを定義するものです。その役割は、主に使用する暗号アルゴリスムの指定、暗号フィルターを適用するタイミングを指定などです。
PDFの暗号化では、これまでRC4暗号アルゴリズムを使っていましたが、PDF 1.6から新しい暗号アルゴリズムAES（Advanced Encryption Standard)も使えるようになりました。暗号フィルターで、使用するアルゴリズムをRC4にするかAESにするか指定できます。また、暗号化しないでスルーする暗号フィルターを定義することもできます。
さて、PDF Referenceの仕様上は、上のような機能が追加されていますが、Acrobat７ のPDFドライバで、使用できるようになっているのは、「メタデータを暗号化しない」という機能のみのようです。AES暗号アルゴリズムはもとより、ストリームとストリングで暗号フィルターを切り替えるというような機能も指定できません。
次の図は、Acrobat 7のPDF ドライバのセキュリティ設定のダイヤログですが、「文書メタデータを暗号化しない」のチェック・ボックスが追加されています。
折角追加された、AES暗号アルゴリズムはAdobeのプリンタ・ドライバからは指定することができません。このあたりは、Acrobat 8で変更になるかもしれませんが。
ちなみに、近くリリース予定のAntenn House PDF Driver V3.1では、AES暗号アルゴリズムを指定できるようになっています。もしかすると、PDF Driverに世界で初めてAES暗号アルゴリズムを採用しました！と宣伝できるかもしれないと思いました。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月14日
PDFのセキュリティ機能（4）—Acrobatの実装をチェックする
さて、PDF Referenceでの標準セキュリティ・ハンドラについて記述されている仕様を紹介しましたが、次に実際のプログラムの画面で、どうなっているかをチェックしてみたいと思います。
まず、Adobe Acrobat（プリンタ・ドライバ）でセキュリティ設定をするためのダイヤログを見ます。（このダイヤログは、PDF 1.4レベルで、標準セキュリティ・ハンドラのリビジョン３を選んでいる状態に相当します）。
・「文書を開くときにパスワードが必要」にチェックしますと、ユーザパスワードを設定することになります。そうしますと、PDFを利用する人がパスワードを入れないと文書を開くことができなくなります。
・「文書の印刷および編集とセキュリティ設定にパスワードが必要」は、少々、分かりにくい日本語のようにも思いますが、ここにチェックしますと、昨日、説明しましたオーナーパスワードを設定できることになります。
さて、オーナーパスワード設定の状態では、次の二つのダイヤログに示すように、PDF に次のセキュリティを設定できるようになります。
・印刷許可（次のいづれか） — 許可しない、低解像度、高解像度
・変更を許可（次のいづれか） — ページの挿入、削除、回転
フォームフィールドの入力と署名
注釈の作成、フォームフィールドの入力と署名
ページの抽出を除く全ての操作
・テキスト、画像、およびその他の内容のコピーを有効にする
・スクリーンリーダデバイスのテキストアクセスを有効にする
セキュリティ設定のダイヤログを見ますと、Adobe Acrobatのプリンタ・ドライバでは、PDF Referenceに記載されているすべてのセキュリティ設定パターンは指定できないことが分かります。例えば、PDF Referenceの仕様では、「ページの挿入、削除、回転」と「フォームフィールドの入力と署名」は独立に設定 — 両方NO、どちらか一方のみYes、両方Yesの4通りの設定 —できるはずなのに、このダイヤログのメニューでは、両方Yesの設定は不可能です。
さて、PDFに設定されているセキュリティの状態を確認するには、Adobe ReaderでPDFを開いて、文書のプロパティ「セキュリティ」タブを選択します。そこでセキュリティ設定の詳細を確認することができます。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月13日
PDFのセキュリティ機能（3）—PDFの利用許可制御
さて、今日は、オーナーパスワード（編集パスワード）により設定できるPDFの利用許可制御について、PDF Referenceに記載されている内容を説明します。
PDF作成者は、PDFにオーナーパスワードを設定するとき、PDFを受け取ったユーザがPDFに対して何ができるかを許可できます。PDF利用許可の内容は、PDFに保存される暗号辞書中のフラグのある桁をONにすることで設定します。
標準のセキュリティ・ハンドラには、リビジョン番号２，３，４の３種類があります。PDF Reference 1.6の表3-20 （pp.99-100)に基づいてリビジョン２で設定できる項目を表１、リビジョン３と４で設定できる項目を表２に整理します。
表１．リビジョン２の標準セキュリティ・ハンドラで許可できること
| ビット位置 | ONの時許可 |
|---|---|
| ３ | 印刷を許可する |
| ４ | 内容の変更を許可する |
| ５ | テキストや画像の抽出を許可する |
| ６ | テキスト注釈の追加・変更と対話式フォームフィールドを埋めることを許可する。ビット4がONならば、新しい対話式フォームフィールドを作成したり、変更することも許可する |
表２．リビジョン３、４の標準セキュリティ・ハンドラで制限できること(*は、リビジョン３・４で、リビジョン２に追加されたこと）
| ビット位置 | ONの時許可 |
|---|---|
| ３ | 印刷許可する—さらにビット12がONなら高精度印刷を許可、OFFなら低解像度印刷を許可(*) |
| ４ | 内容の修正を許可する |
| ５ | アクセシビリティ以外の目的でテキストや画像の抽出を許可する(*) |
| ６ | テキスト注釈の追加・変更と対話式フォームフィールドを埋めることを許可する。ビット4がONならば、新しい対話式フォームフィールドを作成したり、変更することも許可する |
| ７ | ビット６が不許可でも、署名を含め対話式フォームフィールドを埋めることを許可する(*) |
| 10 | アクセシビリティの目的（スクリーン・リーダなど）でテキストや画像の抽出を許可する(*) |
| 11 | ビット４（内容の修正）が不許可の時でも、文書の合成を許可する—ページ挿入・ページ回転・ページの削除・しおりの作成・サムネイルの作成(*) |
| 12 | 高精度印刷を許可する |
ちなみに、リビジョン２の標準セキュリティハンドラは40ビットの暗号方式、リビジョン３の標準セキュリティ・ハンドラは、PDFのバージョン1.4から使用可能になった128ビットの暗号方式です。また、バージョン1.5からはリビジョン４の標準セキュリティ・ハンドラが使用可能です。（これらについては、後日、もう少し詳しく説明します）。
ここで分かりますように、リビジョン３・４の標準セキュリティ・ハンドラの方が、リビジョン２よりも詳細な許可設定ができるようになっています。
【注意】上の説明は、あくまで仕様書で規定されている内容であることに注意してください。つまり、皆さんが日ごろご覧になっている実際のプログラムの動きとは違うかもしれない、ということです。すべてのプログラムが、仕様を上の通りに実装しているとは限らないからです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月12日
PDFのセキュリティ機能（2）—暗号辞書とセキュリティ・ハンドラ
さてPDFのセキュリティの方式について、もう少し調べてみます。
１．暗号辞書
PDFに暗号が掛かっているときは、PDFファイルのトレイラに暗号辞書が登録されます。昨日もお話しましたように、PDFを利用するときは、作成ソフトと消費ソフトが異なりますので、お互いに暗号の方式についての情報を交換する必要があり、この交換すべき情報を暗号辞書の内容に設定するようになっています。PDFにこの暗号辞書がないならば、暗号化されていないということを意味します。
２．セキュリティ・ハンドラ
暗号辞書には、セキュリティを処理する方法（セキュリティ・ハンドラ）についての情報を登録できるようになっています。セキュリティ・ハンドラとは、文字通りPDFに対するセキュリティを取り扱うプログラム・モジュールです。
PDF仕様に記載されているセキュリティ・ハンドラには、標準セキュリティ・ハンドラ（3.5.2）と公開鍵セキュリティ・ハンドラ（3.5.3）が規定されています。また、それ以外の独自セキュリティ・ハンドラを使うこともできます。
昨日、パスワード方式と署名方式が使えると言いましたが、それぞれを取り扱うのが標準セキュリティ・ハンドラと、公開鍵セキュリティ・ハンドラに相当します。
３．標準セキュリティ・ハンドラ
パスワード方式で、PDFへのアクセス許可を設定可能とし、それを処理するものです。PDFの仕様では次の2種類のパスワードを設定することができるようになっています。
（１）オーナーパスワード—編集パスワードとも言い、PDFの内容を修正したり、データを取り出したりなどの制限事項を設定します。
（２）ユーザーパスワード—閲覧パスワードとも言い、PDFを表示して読むことができるための閲覧許可を与えます。
PDFを作成する人が、PDF作成時にパスワードを設定します。
もし、ユーザーパスワードが設定されていると、PDFを利用する人が正しいパスワードを入れないと、PDFを表示することができなくなります。
オーナーパスワードが設定されている場合は、パスワードを入力しなくても、制限事項に設定されている範囲でPDFを利用することができますが、それ以外の目的に利用するためには、正しいオーナーパスワードを入力することが求められます。
この制限事項は、セキュリティ・ハンドラのリビジョンによって、具体的に設定できることが違ってきますのでややこしいです。作成するPDFのバージョンによって、設定できる標準セキュリティ・ハンドラのリビジョンが決まってきます。そして、そのPDFを正しく閲覧・処理できるかは、Adobe ReaderなりPDFビューアが内蔵している標準セキュリティ・ハンドラのリビジョンで決まってくるわけです。
標準セキュリティ・ハンドラがなにをなすべきかはPDF Referenceに書いてありますが、あるソフトウエア製品がPDF1.6のパスワード方式セキュリティを正しく処理できるとは、PDF1.6仕様で規定する標準セキュリティ・ハンドラのリビジョン（の機能）を、その製品に実装していることを意味していることになります。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月11日
PDFのセキュリティ機能（1）—概観
さて、話題を変えて、今日から、PDFのセキュリティ機能について整理してみたいと思います。実は、私はセキュリティはあまり詳しくありません。また、PDF Referenceを読みましても、PDFのバージョンが上がるにつれて、セキュリティ機能が追加されたり、既に廃止されたという記述があったり、さらに、カスタムのセキュリティ方式を組み込む機能が説明されているなど、PDF標準のセキュリティの詳細はかなり複雑に入り組んでいます。
このため、開発担当者にいろいろ聞いてもなかなか理解できないのですが、PDF Referenceを参考にしながら、できるだけまとめてみたいと思います。
そんなわけで、もしかすると間違いが含まれているかも知れませんので、間違いにお気づき方のは、お教えいただけるとありがたいです。
まず、PDFの標準では、どのようなセキュリティ方式が使えるか、ということですが、大きく分けると次のようになります。
（１）パスワード方式—これは共通鍵暗号方式と言い、PDFを作成する人と、PDFを利用する人の間で取り決めた共通のパスワードを使って、PDFの内容へのアクセスを制御する方式です。
（２）署名方式—公開鍵暗号方式による電子署名がその代表的なものです。
次に、PDFに標準で用意されている方式ではないと思いますが、サーバを使って、個々のPDFへのアクセスをきめ細かく制御する方式も様々に提供されています。
まず、最初にPDFでは、セキュリティを（1）どうやって実現しているかということと、（2）何ができるのか、ということについて整理してみましょう。
PDFのファイルには、さまざまなテキスト文字列、イメージ、線画などのコンテンツ情報が入っています。そのコンテンツを整理して、ランダムにアクセスするための構造情報があります。
PDFにセキュリティをかける場合は、一定の暗号化アルゴリズムを使ってPDFを暗号化することになりますが、PDFのファイル全体に暗号をかける訳ではありません。通常は、コンテンツになるデータのみに暗号をかけ、構造情報は暗号化しません。こうすることで、暗号が掛かっているPDFファイルを認識して、暗号を解くことができるようになっています。
PDFファイルは、アプリケーションとは独立に流通していますし、PDFを作成する側がいろいろな暗号化方式を使うことができます。PDFファイル全体に暗号をかけてしまうと、PDFビューアが表示したくても、どんな暗号化方式が使われているかということさえも認識できなくなってしまいますので、これは当然なことです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月10日
XPSをチェックする (2) XPSの構造
さて、折角ダウンロードしてインストールしたのだし、今日、もう一度XPSを調べてみようと思います。ところが今日は、XPSビューアが最初のファイルからいきなりブルースクリーンです。
ブルースクリーンのメッセージには、これが2回目なら、ハードウエアかソフトウエアをアンインストールせよ、とあります。仕方ありません。昨日、うまく表示できたファイルの内部を少し見てみましょう。
昨日のファイルは次の図のような4ページものです。
このファイルは、ZIP圧縮形式ですが、内容はそのままXML形式です。ZIP圧縮ファイルの中には、FixedDocumentSecuence.fdseq、[Content_Types].xmlという二つのファイルのほか、フォルダが三つあります。
これは、Microsoft Office2007のOffice Open XML形式の文書保存形式と良く似ていますね。ファイルのパッケージングの方法は共通なんでしょう。
さて、さらにフォルダの中を見ますと、次のような構造になっています。
すぐに気がつきますのは、4ページのそれぞれが別のファイル（1.page～4.pageの４つのファイル）になっているようだ、ということです。
この1.page～4.pageはそれぞれXMLファイルになっていて、各ページのテキスト・コンテンツが入っています。
ちなみに1ページ目（1.page）を取り出して内容をブラウザで表示してみます。
１ページ目の先頭の行は、昨日の画像でありますように「Cocoa & Chocolate」という見出しなのですが、これは、ファイルの中では、1ページ目の最後の方にあります。
2行目は、「The term “Cocoa,” a corruption of “Cacao,” is」という文字列ですが、上の画像では、この部分が、
Glyphs OriginX="26.6666666666667" OriginY="98.2033333333333" FontRenderingEmSize="16" FontUri="/Resources/a7b9593b-a0f7-4049-a7e6-b8107ad481f9.ODTTF" UnicodeString="The term “Cocoa,” a corruption of “Cacao,” is" Indices=";;;,38;;;;;,38;;;;;;;;;,38;;,38;;;;;;;;;;;,38;;;,38;;;;;;;;;,38" Fill="#FF000000"
となっているのが見えます。
ですので、文字列は（この例では）1行単位に区切られていて、文字列の表示開始座標とともに保存されています。また、ファイルの中では、文字列が表示の順序で現れるとは限らない、ということが分かります。この特徴は、PDFファイルと同じです。
それから、この文書には画像が二つあります。この画像は、Resourcesというフォルダの中に入っていることがわかります。それから、上の図でResourcesフォルダの中にはフォントらしきものも入っていることが分かります。
このあたり、PDFと相当に似通っている、といえると思います。XPSはPDFをざっくりXMLで表現したものといっても大筋では間違っていないでしょう。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月09日
XPSをチェックする
Microsoft のAndy Simonsのブログを見てましたら、XPS (XML Paper Specification)がいよいよV1.0になった！と喜びの声が上がっています。
XPS V1.0の仕様書の配布も始まりました。
XML Paper Specification Updated: October 24, 2006 Version 1.0
というわけで、まずは、XPSを体験してみようと思いたち、XPSのビューアとXPSのサンプル文書を落としてみました。
Windows XPで、XPSのビューアを動かすためのプログラムは、ここにあります。
XPSを表示してみるためには、
Microsoft XML Paper Specification Essentials Pack Version 1.0
と、MicrosoftのコアXMLサービスをインストールする必要があります。コアXMLサービスというと高尚に聞こえますが、XMLを読むためのおまじないツールと思えば良いと思います。
Microsoft Core XML Services (MSXML) 6.0
ただ、XPSを表示するだけならばMSXMLパーサをインストールすれば良いようです。インストールファイルはmsxml6.msiです。MSXMLかあ、久しぶりだなあと思いながら。
無事インストールが済みました。
次に、サンプル XPS Documentからサンプル・ファイルを落としてと。。
うん。。表示できますね。次の図は、XPSビューアでサンプルを表示したところです。
と思ったのもつかの間！５つくらいファイルを表示したところ、いきなり、Windowsがいなくなって、ブルースクリーンになってしまいました。Windowsが根こそぎ死んでしまったようです。しょうがないので、電源をむりやり落として再起動。まあ、ソフトがハードを壊すことはないでしょうがねえ。
というわけで、今日は、ここまでにします。これからXPSを試すときは、大事なファイルは全部保存してバックアップとっておかないと危ないですね。ご注意。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月08日
PDF Tool V2.4 MR1 を公開しました。
11月7日夜Antenna House PDF Tool V2.4 MR1を公開しました。
・Antenna House PDF Tool
・評価版のダウンロード
MR1はメンテナンス・リリースの略で、弊社では、仕様を変更しないで、改良や障害の修正をしたリリースについて、MRｘの記号を付けるようにしています。（対象は、システム製品のみ）
このリリースでの改良点は、リニアライズ処理を高速化したことと、障害の修正が主たる内容です。そこで、リニアライズ処理についてデータを少しご紹介します。
最新版のPDF Toolで、PDFのタイプとページ数によるリニアライズ処理の所要時間を計測した結果は次の図のようになっています。
これをご覧いただきますと、画像があまりないテキスト系のPDFでは、10ページ未満であれば1秒未満、100ページで２～３秒、1000ページで20秒程度の処理時間がかかっています。
しかし、画像のみからなるPDFではかなり時間がかかり、1000ページ(1000個）の画像のPDFでは、Windows版では2分30秒程度かかっています。
□データ
| OS | PDF特性 | 10頁 | 100頁 | 1000頁 |
|---|---|---|---|---|
| Windows | テキスト系 | 0.6秒 | 2.2秒 | 22.2秒 |
| 画像系 | 1.7秒 | 15.1秒 | 151.2秒 | |
| Solaris | テキスト系 | 0.9秒 | 3.3秒 | 39.4秒 |
| 画像系 | 1.2秒 | 9.6秒 | 275.5秒 | |
| Linux | テキスト系 | 0.4秒 | 1.6秒 | 20.3秒 |
| 画像系 | 1.2秒 | 9.6秒 | 85.7秒 |
■リニアライズについて
アドビ・リーダでは、「Web表示用に最適化」と表示されています。PDFの内部のデータを並びかえて、Webからダウンロードして表示するのを高速にしたり、PDF内の指定ページの直接表示を可能とするための処理。
下記の記事も参考にしてください。
2006年07月03日 リニアライズドPDFとは
2006年07月04日 リニアライズドPDFの利用方法 バイトサービング
■計測条件
１．PDF
(1) テキスト系
10ページ ファイルサイズ 87.6KB
100ページ ファイルサイズ 547.0KB
1000ページ ファイルサイズ 5.7MB
(2) 画像系
画像のみ（ページ表記にフォントが少しある）のデータ。10ページ ファイルサイズ 1.4MB
同 100ページ ファイルサイズ 13.8MB
同 1000ページ ファイルサイズ 138.0MB
２．使用マシン
(1) Windows
OS： WindowsXP Service Pack 2
CPU： Celeron 2.00GHz
メモリ： 992MB
(2) Solaris 8
使用マシン： Sun Blade100
(3) Redhat Linux 8.0
CPU： Intel Pentium 4 1.40GHz
■ 計測方法
□ ファイルサイズ
Windows のエクスプローラ上に表示される値。Solaris/Linux はサンバで表示される値。
□ 出力時間
Windows
コマンドプロンプトで「prompt $p $t$g」を指定して、その値の差分を出力時間（秒）とする。小数点以下は四捨五入。
Solaris/Linux
Time コマンドで得られる "real" の値を使用。
【ご注意】このデータは、PDF Tool V2.4MR1によるものです。今後の改良により変化する可能性があります。計測対象データにより変化する可能性がありますので、この処理速度を保証するものではありません。あくまで目安値としてご参考にしていただくためのものです。
【お詫び】この記事は11月8日用でしたが、誤って11月7日夜にブログで公開してしまいましたので、後刻、日付を訂正しました。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月07日
「しおり」のすすめ (7) 開発中の自動「しおり」作成ソフトをリーク！
PDFには「しおり」が必要、とこれだけ主張したからには有言実行せねばなるまい！ということで、いまPDFに「しおり」を自動で付けるソフトを開発しています。
実は、開発中のそのソフトを今日、初めて自分のパソコンで動かしてみたのですが、あまりにうまく「しおり」が付くので感動！ソフトを見て、感動したのは久しぶり！というわけで、このブログで情報をリークしてしまいましょう。
開発中の、このソフトはPDFの文書内容を解析して、「しおり」ツリーを自動的に生成することができます。
まず、次に示すPDFは、PDF Tool V2.4のマニュアルですが、まずいことに「しおり」がついていません。ブログで、「しおり」が必要と何度も言いながら、こういうPDFを製品につけてしまうなんてほんとに情けない限り。冷や汗ものです。
これを、開発中のソフトで読み込んで、「しおり」自動作成ウィザードを動かします。
そうしますと、この通り、「しおり」ツリーができ上がります。
この「しおり」ツリーをPDFに付加し、新しいPDFとして保存。Adobe Readerで開きますと、この通り！
たった5分で、「しおり」のないPDFにパーフェクトな「しおり」が付いてしまいます。これは便利！乞うご期待です。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (2) | トラックバック
2006年11月06日
「しおり」のすすめ (6) 「しおり」編集ソフト
このところ、とある分野の資料をWebでいろいろ検索しています。やや専門的な調査資料になりますと、PDFで配布しているものが多いのですが、特に官庁の委員会などの調査報告書PDFは、「しおり」が付いているものはほとんどないですね。
報告書を出す人達は、印刷して読まれることを想定しているのかもしれません。しかし、読むほうの立場から言いますと、どんな内容かをざっと見て、必要なページだけ印刷したり、かなり選択して印刷しなければなりません。100ページから200ページの報告書となりますと、端から印刷しまくるわけにはいきません。そんなことをしたら、あっという間に数千ページをプリンタで印刷することになってしまいます。
改めて、報告書類には「しおり」を付けて欲しいものだと実感しました。
さて、「しおり」は、PDF作成時に付けるだけではなく、一旦PDFを作成して、その後で、追加したり削除することも簡単にできます。
Adobeですと、Acrobat Standard以上であれば、「しおり」編集機能が付いています。でもAcrobat Standardは3万円台後半になります。アマゾンでAcrobat Standard7が35,800円（税込）です。 ほとんどの場合、PDFを作る、PDFを見るだけという人には少し高く感じるかもしれません。
そういう人には、ソースネクストの「いきなりPDF Professional 2 PLUS」もありますよ。これは、3,970円（税込）で、「しおり」の編集のほか、コメントを書いたり、リンクを付けたりもできます。
ところで、アマゾンで「いきなりPDF」を検索しますと、シリーズが全部出てきます。5点満点によるカスタマ・レビューの評点を見てましたら、面白いことに気がつきました—
○いきなりPDF Professional 2 (説明扉付きスリムパッケージ版) 5点
●いきなりPDF to Data Professional 2 (説明扉付スリムパッケージ版) 1点
○いきなりPDF 2 (説明扉付きスリムパッケージ版) 4.5点
●いきなりPDF EDIT! (説明扉付厚型スリムパッケージ版) 2点
●いきなりPDF to Data Professional (説明扉付きスリムパッケージ版) 2点
などとなっていますね。○はアンテナハウス製、●はアンテナハウス以外の会社が開発して供給しているものです。
カスタマレビューは、時々、極端に流れるきらいがあるように思いますが、ソフトハウスにとっては怖い存在です。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (2) | トラックバック
2006年11月05日
「しおり」のすすめ (5) Word からPDFの「しおり」を作る
Microsoft Wordで作成したドキュメントをPDFにするとき、「しおり」を作るには、次の二つの手続きが必要です。
(1) Word文書を作成する際に、スタイル機能を使って適切な「見出し」を設定する必要があります。
(2) 「見出し」を設定したWord文書をPDFに変換する際に、Microsoft Wordの「印刷」メニューではなく、PDF変換ツールのアドインボタンを使います。
・Antenna House PDF Driverの場合、下の図の左のアドインボタン
・Acrobatの場合はPDF Maker（下の図の右）
そうしますと、出来上がったPDFには次の図のように「しおり」が付きます。
Wordでは、9段階の見出しを付けることができますので、PDFの「しおり」も最大9階層のツリーを作ることができます。
しかし、実際のところ、Wordのスタイルをきちんと使って文書を作る人は少ないでしょうし、アドインボタンを使わねばならないということになりますとやや面倒です。
また、無償で配布されているPDFドライバなどには、アドインボタンのような付属ツールがありません。
このあたりに、一般にWebで配布されているPDFに「しおり」が付いていない原因がありそうです。
ただし、Word2007では、PDFをSaveAsで作成するオプションが用意されるようです（この話、結局どうなったんだろう？）。SaveAsでPDFを作成する際には、「見出し」を「しおり」に変換できます。そうなりますと、来年あたりからPDFの「しおり」普及度がぐっとあがることが期待できそうです。
【注】Wordの「見出し」と「アウトラインレベル」は通常は1対1に対応していますので、本文中では区別しないで使っています。ただし、独立に設定もできるようです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月04日
「しおり」のすすめ (4) XSL-FO における「しおり」
ちなみに、XSL-FOの仕様でも、V1.0では「しおり」がありませんでした。このため、XSL-FOの組版ソフトを開発している人たちが、それぞれ、独自にXSL-FOの仕様を拡張して「しおり」機能を独自に実装してしまいました。このためXSL-FO V1.0 ではPDFの「しおり」作成機能は、XSL-FOプロセサ毎の非互換拡張となっています。
今から考えますと、XSL-FOの仕様を作った時にはPDF出力よりも、紙への出力という意図の方が強かったのではないでしょうか。このため恐らく「しおり」ためのFOを忘れてしまったのではないかと思います。
XSL-FO V1.1では、いろいろなXSL-FO組版ソフトの機能を調査したうえで、「しおり」作成のためのFOが標準仕様として盛り込まれました。V1.1対応のXSL-FOプロセサでは、「しおり」作成機能は標準準拠となるわけです。
XSL-FO V1.1では「しおり」を次のように表します。
FOの例：Download file
このFOを組版してPDFにした結果は次のようになります。
このようにXSL-FOでの「しおり」の仕様は簡単です。
(1) PDFに現れる「しおり」ツリーと同じツリーをfo:bookmark-tree以下に作ります。
(2) 「しおり」の一項目をfo:bookmarkで表します。
(3) 「しおり」の見出しの文字列ををfo:bookmark-titleの内容テキストで表し、
(4) 「しおり」をクリックした時に表示する（ジャンプ先）本文をfo:bookmarkのプロパティとしてinternal-destination（外部リンクは、external-destination）で表します。
ですので、fo:bookmark-tree以下のツリー構造は、PDFの「しおり」のツリーそのものとなります。
このようなFOを作るスタイルシートを予め用意しておけば、XSL-FO組版ソフトを使うことで、PDF出力時に自動的に「しおり」が作られることになります。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月03日
「しおり」のすすめ (3) 「しおり」を付けるタイミングは？
「しおり」は、PDFファイルの中では、次の図のようにドキュメント・アウトラインという情報として管理されています。
ここで重要なことは、ドキュメント・アウトラインのデータは、PDFの本文ページのデータなど他の情報とは別に管理されていること。PDFに「しおり」を、後から追加したり、また、削除したりしてもPDFの本文ページの表示には何の影響もありません。
ですので、PDFを作成した後で、Webなどで公開するときに「しおり」を付けてナビゲーションし易いようにする、ということも問題なくできます。
しかし、多分、自分で意図的にPDFに「しおり」を付けたことのある人はほとんどいまないと思います。実は、私も、「しおり」の付いたPDFを作ったことは、何度もありますけれども、自分でPDFを編集して「しおり」を付けたことは、製品デモのときぐらいしかありません。
「しおり」をPDFに付ける作業をしたことがある人は、制作会社などで職業的にPDFのコンテンツを作成する人位ではないかと思います。そういう人は、お客さんから受注したPDF作成仕様に「しおり」を付けることという要求項目があって作業しているのでしょう。
多くの場合、PDFに「しおり」を付けるかどうかは、PDFを作成するツール依存になっているものと思います。そして、Microsoft Officeなどの「印刷」メニューからPDFを作成すると、できたPDFには「しおり」が付かないのです。
これが、PDFの「しおり」が便利な機能なのにも係わらず、普及していない理由なのでしょう。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月02日
「しおり」のすすめ (2) 米国では？
日本の有価証券の開示資料に「しおり」が付いてないという話をしましたが、これは、日本だけのこと？それとも米国も同じでしょうか？
そこで、NASDAQに開示されている年次資料(Annual Report)でどうなっているか調べてみました。
そうしますと、面白いことに？NASDAQの上場会社25社の開示資料中、「しおり」が付いているのは、3社だけです。この比率はほとんど日本と同じです。どうも、日米を問わず、決算報告書を作る人は、「しおり」に無関心？
米国の場合、面白いのは、PDF作成ツールがかなり分散していることです。Adobeの製品を使って作られたPDFは、25件中6件しかありません。シェアで言いますと3割弱です。
「AFPL Ghostscript 8.5」＋「PDFProcessor V1.0」で作っているケースが約半分の12件あります。これは一体なんでしょう？分かりません。
次はQuarkXPressが3件、10-K Wizard Technology, LLCが2件です。10-K Wizard Technologyで作成したPDFは2件とも「しおり」がついています。
ここから考えられることは、決算報告書のPDFを作成する人は「しおり」なんてあまり気にしていなくて、実際のところは、決算報告書を作るのに使っているツール依存になっている、ということですね。
■参考資料
NASDAQのComputers, Technology & Internet業種25社のAnnual Report（Form-10K） ページ数、しおり有無とPDFを作成したアプリケーション
| 社名 | ページ数 | しおり有無 | PDF生成エンジン | アプリケーション |
|---|---|---|---|---|
| ACD SYSTEMS INTERNATIONAL INC. | 28 | N | Acrobat Distiller 7.0 (Windows) | PScript5.dll Version 5.2.2 |
| ATMI | 40 | N | QuarkXPress 6.5 | QuarkXPress 6.5 |
| ACCELR8 TECHNOLOGY CORP | 92 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| ADVANCED MICRO DEVICES INC | 152 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| AFFILIATED COMPUTER SERVICES INC | 132 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| ALLIANCE DATA SYSTEMS CORP | 513 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| APC | 93 | N | Acrobat Distiller 7.0 (Windows) | PScript5.dll Version 5.2.2 |
| ANALOGIC CORP | 85 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| ANSOFT CORP | 51 | Y | PDF Prep Tool (www.blance.ch) | NA |
| APPLIED MATERIALS INC /DE | 119 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| APPLIED MICRO CIRCUITS CORP | 109 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| APPLIX INC /MA/-APLX | 86 | Y | 10-K Wizard Technology, LLC | 10-K Wizard Technology, LLC |
| ARIBA INC | 137 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| AUTODESK | 144 | N | Acrobat Distiller 6.0.1 (Windows) | NA |
| AUTOMATIC DATA PROCESSING INC | 72 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| AVENEX CORP - AVNX | 112 | Y | 10-K Wizard Technology, LLC | 10-K Wizard Technology, LLC |
| Avid Technology, Inc. | 100 | N | QuarkXPress 6.5 | QuarkXPress 6.5 |
| Aixa | 44 | N | Adobe PDF Library 7.0 | Adobe InDesign CS2(4.0) |
| Axon | 64 | N | QuarkXPress 6.5 | QuarkXPress 6.5 |
| BESI | 143 | N | ApogeeX 2.5 Normalizer | Adobe InDesign: pictwpstops filter1.0 |
| Cysco | 74 | N | Adobe PDF Library 7.0 | Adobe InDesign CS2(4.0) |
| Clearspeed Technology | 24 | N | Acrobat Distiller 4.0 for Macintosh | NA |
| COMPUTER TASK GROUP INC | 74 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| CONEXANT SYSTEMS INC | 115 | N | AFPL Ghostscript 8.50 | PDFProcessor V1.0 |
| CORNING INC /NY | 186 | N | AFPL Ghostscript 8.53 | PDFProcessor V1.0 |
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年11月01日
「しおり」のすすめ (1) しおりとは？
昨日も見ましたように、現在、Webで配布されているPDFには、「しおり」が付いているものが非常に少ないようです。では、「しおり」は無くても問題がないものなのでしょうか？まず、具体的な例を見てみましょう。
次の図は、しおりが付いている「財務諸表PDF」の例です。
これを次のような「しおり」がない「財務諸表PDF」の例と比較しますと、「しおり」があるほうが、遥かに全体像を理解しやすく、また、画面上で内容を閲覧しやすいだろうと思います。
画面の上で、数十ページのボリュームのPDFを読んで内容を把握しようとしますと、「しおり」があれば全体の大筋を瞬時に把握できます。
しかし、もし、「しおり」がないと、最初から最後まで、PDFリーダでずるずるとスクロール、または、ページをめくりながら見ていく必要があります。こういうPDFは、とても内容を把握しずらく、あまり親切とはいえないと思います。
このように「しおり」の重要性は多くの人が認めるものだろうと思います。
それでは、なぜ、現在配布されているPDFには「しおり」が付いているものが少ないのでしょうか？その理由として、次のようなことが考えられます。
１．PDFを作成する人が「しおり」について、まったく、知識を持っていない。
２．「しおり」については知られているが、あまり便利なものとは認識されていない。
３．「しおり」については知っているが、PDFに「しおり」を付けるにはどうしたら良いか知らない。
４．PDFを作成するのに使っているツールに「しおり」作成機能がない。
５．「しおり」を簡単につけるツールが普及していないため、「しおり」を付けたいが、手間が掛かることから敬遠されている。
次回は、もう少し、「しおり」が普及していない理由について考えてみたいと思います。
投票をお願いいたします