« 2007年05月 | メイン | 2007年07月 »
2007年06月30日
PDFについてのQ&A — PDFのフォント埋め込みと著作権(続き)
昨日は、PDFへのフォント埋め込みは権利者の許可なく行うとフォントの著作権侵害となりますが、フォントベンダーによっては埋め込みを許可しているということをご説明しました。
アドビの場合は、埋め込みについては許可しているものが多いようです。
具体的には、こちらにライセンス契約書があります。
http://www.adobe.com/type/browser/legal/index.html
欧文フォント、和文フォントともフォント埋め込みに関する契約条項の文章は同じです。次のようになっています。
「お客様は、お客様の電子文書を印刷および閲覧するため、フォント・ソフトウェアのコピーをその文書に埋め込むことができます。埋め込むフォント・ソフトウェアがAdobeのウェブサイトhttp://www.adobe.com/type/browser/legal/embeddingeula.html で「編集可能な埋め込みのためのライセンス供与済」と指定されている場合は、さらに電子文書の編集の他の目的のためにもそのフォント・ソフトウェアのコピーを埋め込むことができます。」
フォント埋め込みの許可には次の段階があります。
(1)埋め込みを許可しない — アドビのフォントには埋め込みを許可しないフォントはありませんが、フォント・ベンダによっては許可していない場合もあります。
(2)表示と印刷 — フォントをPDFに埋め込んで配布し、表示したり印刷に使うことができますが、PDFを編集するのに用いたり、他のPDFを作成したりするのに用いることができません。アドビのフォントはこの分類が多いようです。
(3)編集可能 — 表示と印刷のほか、PDFの受け手がそのPDFの文書や構造を編集するに用いることができます。
(4)インストール可能 — 受け手がPDFに埋め込まれたフォントをPCにインストールして、新しいPDFを作成するのに用いることができます。これはPDFの受け手はフォントに関してオリジナルと同じ権利をもつことを意味しています。商業フォントではこの分類に属するフォントは少ないと思います。
さて、このようにフォントの埋め込みを許可したり、禁止したりするのは、フォントの権利者（ベンダ）の許諾事項となります。しかし、エンドユーザがフォントの使用許諾契約をチェックしたり、あるいは、権利者にいちいち確認するのは手間が掛かります。
これを自動的に行うために、TrueTypeやOpenTypeといった新しいフォントでは、フォントファイルのフォーマットの中に「埋め込み許可」に関する上記の(1)～(4)の分類情報がセットされるようになっています。
PDFを作成するソフトウエアは、この「埋め込み許可」の情報をチェックして、埋め込みするかどうかを判断することができます。
次の画面は、Antenna House PDF Driver V3.2の設定ダイヤログ「フォント」タブですが、Windowsにインストールされているフォントの一覧を表示するとき、埋め込みが禁止されているかどうかをチェックして鍵のマークで表示するようにしています。
比較的新しいフォントであれば、このようにプログラムで埋め込み許可状態をチェックできます。しかし、Type1のような古いフォントでは、こうしたフラグはありませんので、権利者が許可しているかどうかを個別に確認する必要があります。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月29日
PDFについてのQ&A — PDFのフォント埋め込みと著作権
先日、PDFのフォント埋め込みについてお話しましたところ、「フォント埋め込みは仮に部分埋め込みであっても著作権侵害にあたるのではないか」、というご質問をいただきました。そこで、この問題について考えて見ます。
まず、前提としてフォントに著作権があるのかということですが、これについて判例もあります。
海賊版フォントに対する判決
プログラムとしてのフォントデータの著作権を対象
平成１６年５月１３日 大阪地裁 平成１５年（ワ）第２５５２号 著作権侵害に基づく差止等請求事件
モリサワ勝訴
出典：http://www.translan.com/jucc/precedent-2004-05-13b.html
私は法律の専門家ではありませんが、フォントのデザインに万一著作権がないと仮定しましても、アウトラインフォントはプログラムとデータから成り立っていますし、プログラムと同じように著作権で保護されてしかるべきと考えています。
ビットマップフォントについても、以前に「2006年10月17日 Google Docs/Spreadsheetsを初体験(4) — Kochi-Mincho」でもお話しましたように、ビットマップフォントを無断で複製したことにより、「東風明朝」の制作・配布活動が中止になった例もあります。
マイクロソフトは、Windowsに同梱しているフォントについて、次のページで著作権の取り扱いについて告知しています。
Copyright : マイクロソフトの著作物の使用について
マイクロソフトは、フォントには著作権があると判断していると見られますが、日本語フォントの取り扱いについては「フォントの再頒布や、お客様のソフトウェアでの使用等の権利処理については」フォントベンダーに相談して欲しいと述べています。また、英文フォントについては各フォントの著作権者に相談して欲しいと述べています。
このようなことからフォントについては著作権法が適用されると考えるのが妥当と思います。PDFへのフォント埋め込みは、明らかに、フォントのグリフデータ（アウトラインデータ）の複製と再頒布にあたります。従って、著作権者の許可なくフォントの埋め込みを行えば権利侵害と看做されることになるでしょう。
では、PDFのフォント埋め込みでは、この問題をどのように解決しているのでしょうか？
まず、日本タイプグラフィ協会は、「電子ドキュメントデータへのフォント埋込み機能に対するタイプフェイス／フォントの権利保護に関する声明書」を出しています。
出典： http://www.typo.or.jp/info/morals/moral4.html
これによりますと、概要は、次のような声明になります。
(1) ユーザの立場においては、フォントの埋め込みは非常に有効かつ利便性が高い技術革新と言えます。
(2) 配布されたＰＤＦに埋め込まれたフォントセットのプロテクトを外して使用し､編集・校正することは、新たな文字組みを行うことになり、タイプフェイスの複製行為が行われることを意味します。
(3) 埋め込まれたフォントセットにより、タイプフェイスの複製・改変・二次的使用がより一層簡単となります。
従って、ユーザは、「埋め込んだフォントを用いて編集・校正などの新たな文字組を行う行為」、フォント埋め込みを不可としているタイプフェイス権利のフォントを埋め込まない、フォントが埋め込まれたＰＤＦを配布するに際して、当該フォントの使用許諾契約書に従うこと、を求めています。
また、PDFへフォント埋め込み機能を有するプログラムの供給者に対しては、ユーザに対して禁止されている行為を助けるようなソフトウェアを開発しないことを求めています。
では、PDFへのフォント埋め込みの提唱元であるアドビはどうなっているのでしょうか？アドビは自社でも多数のフォントを制作して販売しています。
アドビのWebページには、フォントのライセンスについての情報が掲載されています。
アドビ製フォントライセンス契約に関するFAQ（よくあるご質問）
ここにフォント埋め込みに関する項目があります。
そこでは、「アドビからライセンスを受けたすべてのフォントは、電子ファイルに埋め込みが可能です。」という一文があります。その後ろに「しかし。。」として幾つか細かい条件が記述されていますが、原則として、埋め込みして配布するだけであれば問題ないようです。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月28日
PDFについてのQ&A —PDFのセキュリティはどの位強固か？
PDFのセキュリティ機能は、どの位強固か、という質問をいただきましたが、その質問にお答えするには、まず、PDFのセキュリティ機能にどのようなものがあるか知る必要があります。PDFで使えるセキュリティ機能には次のようなものがあります。
(1)文書を開くパスワード — PDFファイルを開くときにパスワードの入力を要求し、正しいパスワードが入力されないと文書を開けないようにする。
(2)権限パスワード — PDFファイルは誰でも開くことができるが文書の内容をコピーしたり、高精度印刷したり、編集したりする権限のパスワードを設定する。
(3)文書を開くパスワードの代わりに、PDFを渡したい人の電子証明書を使ってPDFのコンテンツを暗号化し、PDFを閲覧しようとする相手が、対応する秘密鍵がないと開けないようにする。
(4)権限パスワードの代わりに、PDFを渡したい人の電子証明書を使ってPDFのコンテンツを暗号化し、PDFを閲覧しようとする相手が、対応する秘密鍵がないと開けないようにする。
(1)～(4)にあげた標準的なPDFのセキュリティではコンテンツを暗号化しますが、その暗号化プログラム（暗号アルゴリズム）は、RC4-40ビット、RC4-128ビット、AES暗号が一般に使われます。これらの暗号処理機能は標準セキュリティ･ハンドラとしてAdobe Readerに機能があります。
従って、PDFを作成するソフトが、PDFを作成するとき、(1)～(4)の方式で、RC4-40ビット、RC4-128ビット、AES暗号でPDFにセキュリティを設定すれば、Adobe Readerで処理することができることになります。
詳しくはこちらをご覧ください。
PDFの標準セキュリィティ機能
以上で述べたことは標準的な方法です。
しかしPDFでは、独自のセキュリティ・ハンドラ（セキュリティ処理プログラム）を定義することができますので、そうなりますと、そのセキュリティ・ハンドラでできるセキュリティ設定がなんでも可能になります。独自のセキュリティ・ハンドラを使えば、それ以外の暗号アルゴリズムを使うこともできます。従いまして、これについては、「強固」さの度合いはセキュリティ・ハンドラ依存となってしまいます。
さて、暗号アルゴリズムを使ってかけた暗号の強度につきましては、私は暗号の専門家ではありませんのが、一般には、RC4-40ビット⇒RC4-128ビット⇒AES暗号の順で強固になると言われています。
しかし、むしろ、セキュリティが強固かどうかは実際のところは運用に依存すると思います。すなわち、パスワードを使ってPDFにセキュリティ設定した場合、そのパスワードが漏洩してしまえば、パスワードを入手した人には、なんでも出来てしまいます。
日本が開発した「紫暗号」も米国に解読されていたと言う話を読みますと、紫暗号が解読されたきっかけは同じ通信文を、別のもっと脆弱な暗号と紫暗号とで二重に送ったためだそうです。また、ドイツのエニグマ暗号の解読の話を見ましても、毎日同じような暗号文を繰り返した送ったためなどとあります。
ですので、まず、パスワード方式の場合は、パスワードが漏洩しないようにするためにどうするか、最大の課題と思います。
そういう意味では、パスワード方式よりは、電子証明書を使ってセキュリティ設定する方が強固になるはずです。パスワード付きPDFの場合、パスワードを安全に配布するのが大きな問題ですが、電子証明書による暗号化では、パスワード配布の問題が存在しませんので、その分、安全になります。
電子証明書によるセキュリティ設定をサポートしているPDF作成製品は少ないようですが、当社で現在開発しています「PDF電子署名モジュール」では、この電子証明書によるセキュリティ設定も可能となります。
それから、権限パスワードの方は、実際にPDFが相手のPCの上で表示されていることになりますので、情報がまったく漏洩しないというのは常識的に見て考えられないことです。こちらの方は、あくまで、利用を制限する意図を示しているとお考えいただくほうが良いと思います。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月27日
PDFについてのQ&A —PDF のサイズを小さくするには？
Antenna House PDF Driver から PDF 出力をする際に、PDF のファイルサイズを小さくするにはどうすればよいのかという質問を受けることがあります。PDF Driver ではこういった要望にお応えするために「サイズ優先」と「サイズ優先(PDF1.5以上)」のふたつの設定ファイルをご用意しています。
PDF のファイルサイズ軽減のポイントとなるのは、「フォント」と「画像」の扱いですから、ファイルサイズを小さくしたいのなら、「フォントを埋め込まない」、「画像をダウンサンプリングしてから圧縮する」という方法が一般的になります。
先に挙げた PDF Driver の設定ファイルは両方とも「フォントを埋め込まない」設定にしてありますが、画像の処理については少し異なります。「サイズ優先」では、個々の画像についてダウンサンプリングを行った後、ZLIB(ZIP)圧縮と JPEG 圧縮の双方を試みて、サイズのより小さいものを選択します。「サイズ優先(PDF1.5以上)」ではダウンサンプリングを行った後、圧縮の比較に ZLIB(ZIP)圧縮と JPEG2000 圧縮を使用します。
ただし、これらを行うことによりたしかに PDF のファイルサイズは小さくなりますが、デメリットとして、
・フォントを埋め込んでいないため閲覧者の環境によっては異なった見映えになってしまことがありますし、
・画像圧縮後にファイルサイズの比較を行うという処理のために PDF の出力時間が多く掛かってしまします。
・また、画質もオリジナルと比較して劣化してしまいます。
しかし、それでもこれらが大した問題とならない場合には、特にメールやネット上での配布時に、ファイルサイズをより小さくした PDF を作成して配布するというのは、受け取る側への配慮として必要なように思えます。
投稿者 numata : 08:00 | コメント (0) | トラックバック
2007年06月26日
PKI Day 2007 ＜PKIの過去、現在、未来＞
6月25日は、1日PKI Day 2007に行って来ました。タイトルは、＜PKIの過去、現在、未来＞でした。
プレゼンテーション資料はこちらで公開されています。
PKI Day 2007 - ＜PKIの過去、現在、未来＞
PKIについて勉強し始めたばかりの私としては、過去、現在、未来とも大いに関心がありましたが、一番興味深かったのは、佐々木先生の基調講演Iで、「世界最初の印鑑」、「外国における印章の歴史」、「日本における印章の歴史」、特に、武田信玄の印章です。織田信長の天下武布も印章じゃなかったでしょうか。
公開鍵暗号方式発明者が誰かという話は、先日紹介しました、サイモン・シンの「暗号解読 — ロゼッタストーンから量子暗号まで」にも紹介されていましたので、私としては、記憶に新しいところですが、佐々木先生は、英国のCESG説について原論文をチェックされたそうですが、「本当だと思う」と明言されていました。「あ、やっぱりそうか」と一人で納得。
ところで、電子署名については講演された方は全体として期待した程普及していないとした上で、その一つの原因の電子署名法を挙げて、この法律についての批判される意見が多かったように思います。
第二基調講演者の宮川さんは、2000年頃にGPKIと電子署名が、電子申請、電子署名と検証用の基盤として導入されたところに、日本のPKIの歴史の不幸があった、と述べました。
PKIは、電子署名よりも、むしろ本人認証の基盤として重要であり、漸く、2006年から「電子政府認証ガイドライン」の議論が始まったのは、前後が逆ではなかったか、とのことです。
東京大学の佐藤氏も「東京大学におけるキャンパスPKIの配備に向けて」という題の講演の中で、認証基盤としてのPKIの重要性を強調されました。
PDFの電子署名ソフトを作っている私としては、少しばかり失望する場面が多く残念ではありました。
電子署名には、「データの改竄検出・真正性の確認」、「署名者が本人であることを確実に認証する」、「署名者の否認防止（押印により内容にコミットする）」という３つの側面があります。電子署名法はこの電子署名がこの３つを兼ね備えるべきことを盛り込んでしまっているようです。それが電子署名に対する要求のレベルを押し上げて、結果、利用を減らしたのではないかとも思えます。現実には、オフィス・ワークにおいて、上の３つの要求を兼ね備えた押印を行う場面はめったにないでしょう。
こうした実態に対して、e-文書法や「長期署名」では、電子署名法とは異なり、「データの存在性」、「データの証拠性」に重点があるように思います。このあたりで、同じ電子署名が異なる用途で見直される可能性もあるのかな、と思いました。
PKIの利用されるべき新しい領域では、JPNICの木村さんの「IPアドレスの使用権を示すリソース証明書」の講演がありました。これに関連しますが、Windows Vistaでプログラムを配布するには「プログラム証明書」をつけないと、「認識できない発行元」とされてしまうという問題があります。このように、今後、様々なデータやプログラムをインターネット経由で配布する際に、PKIを使って認証する機会が増えることが間違いないところでしょう。
Microsoft Vistaのスマートカード（ICカード）・ドライバのアーキテクチャ変更の話も参考になりました。ですが、ミニドライバ・アーキテクチャって、プリンタ・ドライバでは確かWindows95で採用されたのではなかったでしょうか。ICカードは10年も遅れて、Vistaでミニドライバのアーキテクチャに変更になったということですが、この遅れの理由は一体なぜ？
ICカード・メーカのマーケティングは囲い込み・独自アーキテクチャ戦略をとってきたらしいのですが、それが理由なんでしょうか。
日本の公的個人認証ICカード、電子入札ICカードは、まだまったくVistaに対応できていません。これに関して、「これは簡単なんだけど、政府がお金を出さないとメーカでは取り組めない」と耳にして、少しばかりあきれてしまいました。
なにはともあれ、PKI初心者の私としては、大変参考になりました。講演された方々にお礼を申し上げたいと思います。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月25日
コンピュータによるテキスト表記とPDFのフォント埋め込みについて
PDFへのフォント埋め込みを説明しようと思いましたが、前提となる知識などを整理する必要を感じました。
そこで、過去のブログの記事を中心に、「コンピュータによるテキスト表記とPDFのフォント埋め込みについて」という文章にまとめてみました。
こちらからご覧いただくことができますので、参考にしていただければ幸いです。
コンピュータによるテキスト表記とPDFのフォント埋め込みについて
説明の不十分な点、あるいは、理解の誤り、などご指摘いただければ幸いです。
目次
・はじめに
・基礎知識
・字形、字体
・表外漢字字体表
・字体の違いとデザインの違い
・文字コード
・漢字のコードポイント－字体－字形の3層モデルについて
・フォントとグリフ
・アウトライン・フォントとグリフ
・フォント・ファイル
・文字コードとグリフの関係
・異体字
・文字の位置によるグリフ切り替え
・ リガチャ（合字）
・PDFのテキスト表示の仕組み
・フォントが埋め込まれていない場合の文字の表示
・PDFへのフォント埋め込みとは
・フォントを埋め込まないPDFの表示の問題
・フォントを埋め込まない日本語PDFは英語版Windows上のAdobe Readerでは表示できない
・フォントを埋め込まない中国語PDFの表示
・フォントを埋め込まないアラビア語PDFは作成できない
・フォントを埋め込まないラテン文字PDF
・プロポーショナルフォントを使用した縦書き文書
・フォント埋め込みについてのQ&A
・お断り
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月24日
PDFについてのQ&A — フォント埋め込みについて（基本の説明)
昨日と１昨日のお話を振り返ってみますと、いきなり技術的な核心をお話してしまったため、PDFについてある程度知識のある方でないと、眼が点になってしまったのではないかと思います。
そこで、反省して、PDFで文字を表示する基本について触れてみることにしました。この詳しい説明は、PDF Reference 1.7では「第5章 テキスト」(p．387～）の初めの部分に出てきます。
まず簡単に略図を示してみましょう。
この図で、「文字列」と表した部分は表示したい文字となります。ラテン・アルファベットはABCのような文字のまま保存できます。CJK文字は文字コードの並びで表現するのが一般的ですが、フォントのグリフIDの並びで表すこともできます。
文字列には、使用するフォント・オブジェクト、文字の大きさ、文字を表示する位置など様々な情報が付随しています。
フォント・オブジェクトは、ページに付随する資源辞書の中のフォント辞書に詳しい情報が定義されています。フォント辞書は、Type1、TrueType、CIDフォントなどのフォントの種類によって若干の差がありますが、フォントの種類やPostScript名、標準の幅、などを規定しているものです。
実際に文字を表示するためには、文字を表すグリフ・データ、フォントのメトリックスなどが必要ですが、これらの情報は、フォント・ファイルの中に含まれています。
フォント・ファイルは、コンピュータ上（Windows環境であれば、Windows/Fontsフォルダ内）にあったり、あるいは、アプリケーション独自のインストール・フォルダやアプリケーション内部にあります。
PDFにフォントを埋め込むと、埋め込み処理の際に、コンピュータ上のフォント・ファイルから必要最小限の情報が取り出されて、PDF内部に取り込まれます。これが、PDFへのフォント埋め込みです。
略図で示しますと次のようになります。
フォントを埋め込んでいないPDFでは、文字を表示するのに必要なフォント・ファイルがPDFの外側にありますが、フォントを埋め込むと必要最小限の情報がPDFに付随します。そこで、PDFを表示するViewerが埋め込んだフォントで文字を表示することができるならば文字化けなどが発生することがなくなることになります。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月23日
PDFについてのQ&A — フォント埋め込みについて（続き）
昨日のお話は、フォントを埋め込まないと問題がでることがある、ということでしたが、以前に、フォントを埋め込む場合とフォントを埋め込まない場合についてPDFのデータが違うことをお話したことがあります。
2007年01月22日 日本語の文字についての用語について(9) — PDFへのフォント埋め込みとは — PDFに文字を埋め込まない場合は、PDFの中のテキストは文字コードで表現されていますが、PDFに文字を埋め込んだ場合は、PDFの中のテキストはグリフのIDとグリフデータ（グリフIDに一対一対応）で表されていることを説明しています。
この違いを理解するには、文字コードとグリフ（グリフのID、グリフデータ）という言葉についての知識が必要です。これにつきましても既にお話しています。
まず、文字コードは、コンピュータで文字を取り扱うために、文字を集めて抽象的な集合を作成してその構成単位に番号をつけたものです。構成単位は抽象的な文字であって、それを可視化・具象化したものが実際に画面に表示したり紙に印刷される文字となります。
日本語の場合、ひとつの文字コード（コードポイント）に対して対応付けられる、可視化される文字の形は一つだけではありません。これについては、2007年01月17日 日本語の文字についての用語について(5) — ３階層モデルなどで説明しました。
ここで、字体とは、文字骨格であり、字形とは文字の具体的な形です。
2007年01月11日 日本語の文字についての用語について(1)
コンピュータの上で、文字を可視化する方法は幾つかありますが、現在、一般的なアウトライン・フォントの場合、字形は、フォントのグリフデータとして用意されています。これについては2006年04月24日PDFとフォント(15) アウトラインフォントなどでお話しています。
PDFにフォントが埋め込まれていない場合、PDFの中には文字コード（コードポイント）の並びがあり、その文字コードを表示するために使うフォント・ファミリーが指定されています。そこで、その文字を実際に、画面に表示する前に、次の手続きが必要です。
(1)PDF中で指定されているフォント・ファミリーを、PDFを表示する環境であるPCに存在するフォント・ファミリーに対応付けする。同一のフォント・ファミリーが存在すれば問題ないが、存在しないと別のフォント・ファミリーの中で適切なものを決定する。
(2)フォント・ファミリーの中で、コードポイント⇒グリフIDに対応つける。
(3)当該のグリフIDに対応するグリフデータを使って文字を可視化する。
上のステップで特に、(2)、(3)の点について、2007年01月21日 日本語の文字についての用語について(8) — 文字コードとフォントなどでお話しています。つまり、同じコードポイントに対応付けられるグリフデータは一つとは限らないということです。
PDFにフォントを埋め込まないときは、あるコードポイントの文字を可視化するのに、上のような過程を踏むことになりますので最終的に可視化される文字が、偶に、意図しない文字になることがありそうなことは想像が付くと思います。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月22日
PDFについてのQ&A — フォント埋め込みについて
１昨日はシアトルでしたが、今日は東京です。シアトルはとても涼しかったですが、東京は暑いですねえ。
シアトルの大企業としては、BoeingとMicrosoftが有名です。Boeingは昔はシアトルに本社があったそうですが、だいぶ前に本社をChicagoに移してしまったそうです。聞くところによりますと、シアトルにいるとどうしても視野が狭くなって、世界戦略上望ましくない、という理由だったとか。そのときは、シアトル市民の自尊心が大いに傷付いたそうです。Microsoftとちがって、Boeingには競争相手がいますから、世界戦略が必要なんでしょうね。
さて、PDFについて某所の勉強会の講師をさせていただくことになりました。で、事前に幾つか質問をいただいているのですが、今日からその準備を兼ねて、事前にいただいたご質問にブログでお答えしてみたいと思います。
最初は、フォント埋め込みについて、「フォント埋め込みとは何か？」というご質問をいただいています。このブログでは、これまでも、フォント埋め込みに関して何回か触れてきました。
回数が多くなるにつれて、同じことをなんども取り上げてしまいそうですので、まず、過去の話題を整理してみます。
第329話 2006年09月10日 PDFのフォント埋め込み — フォントを埋め込まないと環境によっては文字が正しく表示されないことがあります。また、フォントを埋め込みでは日本語は通常サブセット埋め込みになりますので、ファイルサイズはそれ程大きくなりません。
第330話 2006年09月11日フォントを埋め込まないPDFの表示について～第360話 2006年10月11日フォントを埋め込まないPDFの表示(6) — ここでは、Adobe Readerで、フォントを埋め込まないPDFで、文字を表示するのに、どうやらWindowsのシステムフォントをすなおに使っているわけではなくて、なにか特殊なことをしているようだ、ということを説明しています。
なお、この中の実験で、2006年09月25日 フォントを埋め込まないPDFの表示(4)では、アラビア文字をPDF化すると、PDFDriverで「フォントを埋め込まない」と指定しても、必ずフォントが埋め込まれてしまう、ことを示しました。
第423話 2006年12月13日プロポーショナルフォントを使用した縦書き文書 — ここでは、プロポーショナルフォントで縦書きする場合、フォントを埋め込まないと、文字の表示が乱れてしまうことがある、という例を挙げています。
このように、フォントを埋め込まないと、いろいろと問題が生じるケースがあることを何回か取り上げています。しかし、フォント埋め込みとはなにか、を正面から取り上げたことはなかったようです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月21日
Vectorのダウンロード販売：PDF製品過半数がアンテナハウス製となる！
現在、Vectorで「一流ビジネスマンのPDF活用ツール」セールを行っています。ここで紹介されているPDFツールは、全部で18種類あります。
なんと、そのうち、過半数の10種類が当社製となりました。製品数の上だけなく、売上金額の方でも、同じくらいのシェアになりたいものです。
キャンペーンが終わってしまいますと、このページもなくなってしまうでしょうから、記録のためPDF化して残しておきましょう。
○1ページ目
PDFファイルをダウンロード
○2ページ目
PDFファイルをダウンロード
ちなみに、ここに掲載されている中で、次のものがアンテナハウス製となります。
・書けまっせ!!PDF2 Vista対応版（開発・販売ともアンテナハウス）
・リッチテキストPDF3（開発・販売ともアンテナハウス）
・書ける！PDF （開発：アンテナハウス 販売：ジャングル）
・書ける！PDF フォーム付 （開発：アンテナハウス 販売：ジャングル）
・いきなりPDF Professional 2 （開発：アンテナハウス 販売：スースネクスト）
・リッチテキストPDF3 D&D（開発・販売ともアンテナハウス）
・変換！PDF PRO （開発：アンテナハウス 販売：ジャングル）
・変換！PDF （開発：アンテナハウス 販売：ジャングル）
・いきなりPDF 2 （開発：アンテナハウス 販売：スースネクスト）
・Antenna House PDF Driver V3.2（開発・販売ともアンテナハウス）
こうしてみますと、PDFソフトも安くなりました。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月20日
PDFと署名(44) — MDP署名の場合
PDFの仕様では、普通の署名とMDP署名という、2種類の電子署名があることは前にお話しました。
2007年05月16日 PDFと署名(28) — PDFの2種類の署名
MDP署名とは、PDF Referenceで、modification detection and prevention（修正検出・防止）と言われているものの頭文字です。日本語版Acrobat 8では、MDP署名は「証明済み署名」（certified signature）と表記されています。
PDFにMDP署名をすると、署名後に変更可能な内容を次の3段階のどれか制限できます。
・変更を許可しない
・フォームフィールドの入力と署名フィールドに署名
・注釈の作成、フォームフィールドの入力と署名フィールドに署名
「変更を許可しない」を選択してMDP署名をしますと、PDFに対して変更ができなくなりますので、通常署名でできた二つ目の署名を初め、ページの編集、タッチアップ機能によるテキストの変更など一切の変更ができなくなります。従って、増分更新というような機能も無関係です。
「フォームフィールドの入力と署名フィールドに署名」または「注釈の作成、フォームフィールドの入力と署名フィールドに署名」を選択して、MDP署名をしますと、署名時に許可した変更だけができるようになります。署名後の変更内容は、通常署名と同じように、増分更新として保存されます。
PDFの電子署名は、(1)署名フィールドを作成して、(2)そこに署名するという二つのステップの処理を行うことになりますが、MDP署名後に新しい署名フィールドを作成することができません。
MDP署名したPDFファイルに、署名者と別の人に電子署名を求める場合は、予め署名フィールドを作成しておく必要があります。
(1)予め署名フィールドを作成する
(2)MDP署名をする
(3)通常署名をする
このようにMDP署名と通常の署名では若干ワークフローが違います。しかし、電子署名をした後の変更内容が、PDFファイル上で増分更新として扱われることについての違いはありません。
ちなみにMDP署名をした後、通常署名をしたPDFの署名検証結果(例)は次のようになります。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月19日
PDFと署名(43) — 署名と増分更新（続き)
昨日の続きですが、PDFに署名した場合、必ず増分更新になることについて、Acrobat 8について動作を確認して見ましょう。
１．PDFの途中にページを挿入したときの動作
ア．署名なしのPDFファイル場合
(1)オリジナルPDFファイルの%%EOFの位置（最後）をAとします。
(2)1ページを挿入し、「上書き保存」したときは、PDFファイルが増分更新され、新しいPDFファイルでは、最後の位置Bと位置Aの2箇所に、%%EOFが存在します。
(3)1ページを挿入し、「名前をつけて保存」したときは、保存後のPDFファイルの最後の位置はCとなり、位置Aには%%EOFは存在しません。そして、不要なオブジェクトが削除されますので、C<Bとなり、ファイルサイズが小さくなります。
イ．署名をしたPDFファイル
(1)オリジナルの署名済みPDFファイルの%%EOFの位置（最後）をA'とします。
(2)1ページを挿入し、「上書き保存」したとき、PDFファイルが増分更新され、新しいPDFファイルでは、最後の位置B'と位置A'の2箇所に%%EOFが存在します。
(3)1ページを挿入し、「名前をつけて保存」したときも、新しいPDFファイルの最後の位置B'と位置A'の2箇所に%%EOFが存在します。
このように、未署名のPDFファイルと署名済みのPDFファイルでは、「名前をつけて保存」の結果が変わっていることが分かります。そして、署名済みのPDFでは、「上書き保存」と「名前をつけて保存」が共に増分更新になっています。
２．PDFのページ削除の例
未署名のPDFファイルでPDFのページを削除した場合、「上書き保存」でも増分更新にならず、削除したページがなくなってしまうことは、以前にお話しました。
2007年06月12日PDFと署名(40) —PDFの増分更新（続き)
署名済みのPDFファイルでは、PDFのページを削除しようとしますと、次のようなメッセージが表示されます。
以上は、ページ挿入・削除の例ですが、電子署名の有無でPDF操作に違いが出ていることがわかります。
３．署名済みPDFのテキストを編集（タッチアップ）
署名したPDFのテキストを編集してみます。
(1)編集前
(2)タッチアップ・ツールでテキストを編集後
タッチアップテキストで編集したPDFの署名のステータスは次のようになります。
ここで注意しなければならないのは、表示されるPDFの内容は変更されているにも関わらず、「署名は有効です」となることです。
なぜならば、PDFの電子署名の検証は署名対象領域が変更されていないかどうかを検証する仕様です。これに対して、既に説明しましたように署名されたPDFは増分更新されますので、署名対象領域は変更になりません。
このことから、電子署名の署名値の検証ではPDFの変更を検出できず、変更を検出するには署名対象領域以外にデータが追加されているかどうか、言い換えますと増分更新値の存在を、をチェックする必要がある、ということになります。
【注意】以前におはなししましたようにPDFには、2種類の署名があります。今日のお話は、このうちの「通常署名」にあてはまります。
2007年05月16日PDFと署名(28) — PDFの2種類の署名
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月18日
PDFと署名(42) — 署名と増分更新
先日は、PDFの内容を変更した場合、増分更新という保存方法があることをお話しました。
・2007年06月11日PDFと署名(39) — PDFの増分更新
・2007年06月12日 PDFと署名(40) — PDFの増分更新（続き)
増分更新の特徴については、次のように整理できます。
(1) PDFファイルの最後は%%EOFですが、PDFを増分更新すると更新する前のPDFファイルの%%EOFの後ろに更新情報が追加されます。
(2)更新前のPDFに対して、追加した内容だけではなく、更新前のPDFから削除・変更した内容も追加情報として扱われます。
(3)更新部分は、旧版PDFの終わりの%%EOFから更新後のPDFの終わりの%%EOFまでの間に保存され、%%EOFの数はPDFの改訂された版数に対応します。
(4)そこで、増分更新だけを使って更新したPDFであれば、当該の版に対応する%%EOFまでの情報を取り出すことで、改訂前の版のPDFに遡ることができることになります。
通常のPDFでは変更して保存した場合に増分更新しなければならないと決まっている訳ではありません。むしろ、増分更新では、削除した情報を抱えることになる結果、PDFが冗長になりますし、リニアライズ（Web最適化）という面からは望ましくないとも言えます。
例えば、Acrobat8では、「名前をつけて保存」では増分更新となりません。「上書き保存」とすると増分更新となりますが、しかし、PDFの途中のページを丸ごと削除してしまうと、「上書き保存」しても増分更新になりません。
ところが、「PDFに一旦署名をすると、PDFへのあらゆる変更は増分更新としなければなりません。」(PDF Reference 1.7 p.99。 この記述はPDF 1.4から追加された。)
そこで、電子署名に対応するPDFアプリケーションは、電子署名されたPDFを変更する場合は増分更新しなければなりません。この結果、電子署名したPDFについては、旧版のPDFを取り出すことができることになります。
なお、Acrobatでは電子署名PDFに名前をつけて保存するときの機能がバージョンによって少し違うようです。「Digital Signatures in the PDF Language」に次のような一文があります。
---ここから---
最初のAcrobat は、Save As コマンドを使用するとPDF ファイルの中でもはや使われてい
ないオブジェクトを削除し、その結果すべてのファイルを、増分更新セクションのない単純な
PDF ファイルとして保存した。この結果、既存の電子署名を無効にしてしまう。そこで、よ
り最近のAcrobat は、もし電子署名がファイルの中に存在すると増分更新セクションを最適化し
ないようになった。そこで、Acrobat 5 を使っているならば、Save コマンドだけを
使い、Save As コマンドを使ってはならない。または、Acrobat 6 以上を使うこと。
---ここまで---
これを見ますと、Acrobat 6で電子署名PDFのSaveAs機能を変更したと理解できます。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月17日
『Antenna House PDF Driver 3.2』5ライセンスパックを発売
アンテナハウスでは、この程、新たに『Antenna House PDF Driver 3.2』5ライセンスパックを発売しました。
従来、『Antenna House PDF Driver 3.2』は、ダウンロード販売、または弊社の他製品への同梱、OEM様の製品との同梱でお求めいただいていましたが、新たに、シュリンク・ラップ・パッケージとしてもお求めいただくことができるようになりました。
■製品の概要
・内容物 CD-ROM、インストールガイド、ライセンス証書兼ユーザ登録用紙
・パッケージ DVDケース
・価格 10,500円（消費税込み） 5ライセンス
■パッケージ・イメージ
■以下に、「Antenna House PDF Driver V3.2」の販売形態について整理してみました。
１．PDF Driver シングル・ライセンス（デスクトップ）
○販売形態 ダウンロード販売のみ
○発売日 2007年6月8日
○標準価格 税込み1,880円／ライセンス
○販売経路 ベクター、So-net、Impress、他
２．PDF Driver 5ライセンスパック（デスクトップ）
○販売形態 パッケージ販売（DVDケース）
○発売日 2007年6月14日
○標準価格 税込み10,500円／５ライセンス
○JANコード 4959313850702
○販売経路 ソフトウエアお取り扱い店、ディーラ様
３．PDF Driver サイトライセンス（デスクトップ）
○販売形態 ダウンロード販売のみ
○発売日 従来より
○標準価格
パック価格 税込価格
・5ライセンス 8,400円
・30ライセンス 50,400円
・50ライセンス 78,750円
・100ライセンス 147,000円
○販売経路 アンテナハウス直販（アンテナハウス・オンラインショップ）
http://www.antenna.co.jp/sales/shop/
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月16日
ジャングルより『戻す！PDF』2製品他を発売
6月14日 株式会社ジャングルは、PDF⇔Wordとの相互変換ツール『戻す！PDF to 文書』とPDF⇔Excelとの相互変換ツール『戻す！PDF to 表計算』、そして2007年5月に発売した人気の製品をセットにした、『変換！PDF PRO＋書ける！PDFフォーム付き』を2007年7月5日（木）より、全国の量販店及びネットショップで発売開始することを発表しました。
『戻す！』シリーズは、アンテナハウスの「リッチテキストPDF3」より、一部の機能だけを廉価で使いたい、というご要望をお持ちの方々向けとなります。
・『戻す！PDF to 文書』と『戻す！PDF to 表計算』は、それぞれ標準価格5,229円
また、『変換！PDF PRO＋書ける！PDFフォーム付き』は、『変換！PDF PRO』と『書ける！PDFフォーム付き』をセットにした製品で、標準価格が16,590円となります。
現時点で、これらの製品の同等品パッケージをアンテナハウスから発売する予定はありません。
次の図は、株式会社ジャングルから発売されているPDFシリーズの機能比較表です。
アンテナハウス製品との対応関係が少し、分かりにくくなりましたが、次の通りです。
■同等品あり
・『変換！ＰＤＦ』 ： 『リッチテキストPDF3 D&D』と機能的に同等。
・『変換！ＰＤＦ Pro』 ： 『リッチテキストPDF3』と機能的に同等。
・『書ける！ＰＤＦ』 ： 『書けまっせ!ＰＤＦ2』と機能的に同等。
・『書ける！ＰＤＦフォーム付き』 ： 『書けまっせ!ＰＤＦ2』プラスフォーム300種類
これらは機能的に同等ですが、『変換！』、『書ける！』シリーズのユーザ登録、カスタマ・サポートなどはアンテナハウスからではなく、株式会社ジャングルにてお受けしています。
■同等品なし
・『戻す！PDF to 文書』
・『戻す！PDF to 表計算』
・『変換！PDF PRO＋書ける！PDFフォーム付き』
ご理解の程、よろしくお願いします。
■詳しくはこちらをご覧ください。
「戻す！PDF to 文書」「戻す！PDF to 表計算」「変換！PDF PRO＋書ける！PDFフォーム付き」2007年7月5日発売！
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月15日
2日連続 Acrobat 8.1.0の自動アップデート、なぜ？
2007年06月10日 Distiller がOffice 2007フォーマットに対応の謎！？の際に、Acrobat Professional 8.0 を8.1にダウンロード・アップデートしたのですが、その後、13日、14日と、なぜか2回Acrobat 8.1.0が自動アップデートされました。
知らないうちに勝手にPCにアップデートを適用するのは何をされるか分からない怖さがあります。この自動アップデートは止めて欲しい。
それだけではなく、Acrobat 8.1のアップデートは相当に長い時間がかかります。
14日なんて、早朝良い気分で仕事を始めたところ、Windowsの「アップデートしますか？」というメッセージが出ました（昨日から）ので、何回もでて煩わしいので「Restart now」としましたところ、WindowsXPが更新されました。それだけなら良いんですが、今度は、Acrobat 8.1のインストーラが動き始めて、次のような画面がでます。
「えー！28分！」は、こけおどしでした。実際は、4,5分で終わりましたが、なぜ、2日連続でアップデートしなきゃならないんだろう？
昨日のは、恐らく、Acrobatの方のアップデートで、多分、今日のはWindows環境が変わったので、自動インストーラが動いたように想像しますが、なんにしてもなんのメッセージもなしに、勝手に動くのは止めて欲しい。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月14日
コンポーネントソース社からTOP10パブリッシャ盾が届く
本日、コンポーネントソース社から「Component Source 2006アウォーズ」の記念盾（下の写真）が届きました。
この盾、中央の大きなのは、日本のトップ10パブリッシャの記念です。しかし、むしろ、前の二つが世界全体でのトップ100をしめしていてその記念というところに意義を感じています。
アンテナハウスの製品では主にXSL Formatterを販売していただいていますが、コンポーネントソース社は、本社はイギリスの会社なので、世界全体の中では英国を中心に欧州地域が強いという印象をもっています。盾も日本の盾とは違ったデザインになっているところが面白い。
盾は透明なので分かりにくいですが、右前の小さな盾が、「XSL Formatter」が世界のトップ100になったことを記念しているものです。
ということで、昨年は、XSL Formatterが海外でよく売れました。
今年は、PDF製品を含めて、海外展開を強化していきたいと考えています。早期に海外:国内の売上げを50対50にしたいですね。
いつまでも、日本のソフトウェアは輸入超過と言われないように頑張ります！
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月13日
PDFと署名(41) —PDFの複数署名
PDFでは、文書に複数の署名をすることができますが、この複数署名は増分更新の機能を使って実現しています。
まず、PDFを作成して、それに普通の電子署名をします。ついで、さらに二つ目の電子署名をします。次のようになります。
ここで注意して欲しいのは、最初に署名をした段階での署名の検証状態は次のようになっています。
○最初の署名をした段階での電子署名の検証状態
・プロパティ
○二つ目の署名をした段階での電子署名の検証状態
・一つ目の署名のプロパティ
・二つ目の署名のプロパティ
二つ目の署名をした段階で、一つ目の署名は署名が適用された後に変更されたというステータスに変わってしまいます。
PDFファイルの内部は次のようになっています。
最初の署名をした段階で、オリジナル（署名前）のPDFに対して署名辞書が作成されて、その中に署名データが作られます。署名の対象範囲は、署名データ以外のPDF全体です。
次の署名は最初の署名を含める範囲を署名対象範囲としています。二つ目の署名データは増分更新として作成されます。
また、前回と同じように、増分更新部分（最初の%%EOFより後ろ）を削除してみます。
そうして、PDFファイルに保存しますと、最初の署名がなされた状態に完全に元に戻ります。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月12日
PDFと署名(40) —PDFの増分更新（続き)
PDF Referenceではincremental updateという言葉を使っていましたので、増分更新という言葉を訳語として当てはめてみました。日本語で増分更新と言いますと、いかにも、後ろに追記していくような印象を受けます。
しかし、実は、追記ではなく、文字列を削除したり、書き換え（更新）する場合でも、PDFファイル上は、増分更新の形式となります。その例を示してみます。
(1)文字列をタッチアップツールで変更した例
オリジナルのPDFの文字列を修正して上書き保存、さらに、修正して上書き保存しました。
・オリジナルPDFファイルをダウンロード
・修正したPDFファイルをダウンロード
・修正に修正を重ねたPDFファイルをダウンロード
昨日と同じように、この３つのPDFファイルの%%EOFの位置をチェックしますと次のようになります。
第3番目「修正に修正を重ねたPDF」ファイルでは、３つの%%EOFがあります。バイナリのエディタで、PDFファイルを開いて、２つめ&&EOFから後ろを全部削除してみます。
a. 削除する範囲を選択
b.削除後
こうして削除したファイルを保存し、削除前のPDFと削除後のPDFを比較してみます。
このように、増分更新した場合、削除されたはずの情報もそのまま残っていますので、更新された部分のデータをPDFから削除すると、削除されるまえのPDFに戻ります。
(２)ページの追加削除は増分更新になるときとならない時がある
Acrobat 8 の増分更新は、文字列のみではなく、PDFのページ追加、ページ挿入、ページ削除なども、後ろのページについてであれば有効です。但し、PDFの途中のページを削除しますと、上書き保存しても増分更新にはならないようです。
(３)増分更新ではリニアライズは無効になる
なお、増分更新しますと、リニアライズ（Web表示用に最適化）は、仮に設定されていても無効となります。リニアライズでは、ファイルの先頭にランダムアクセスのための情報が必要ですが、増分更新は、ファイルの後ろへの追加になりますので、リニアライズと矛盾するからです。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月11日
PDFと署名(39) — PDFの増分更新
PDF文書の変更と署名の関係について、調べてみました。これについてお話する前に、PDF文書を作成したあと変更した場合、PDFファイルがどのようになるかを見てみたいと思います。
PDFファイルは、適当なツールを使えば内容を編集（削除、追加、変更）したり、しおりをつけたりといった、様々な変更を施すことができます。そのような変更を行った結果をPDFファイルに保存するときの方法に「増分更新」という保存方法があります。
増分更新とは、変更前のPDFファイルの内容をそのままに維持して、変更前のファイルの最後に変更した内容を追加し、新しいPDFファイルを作る方法です。
Acrobat 8では、PDFを編集して「上書き保存」すると増分更新となります。「名前をつけて保存」すると増分更新ではなく、新しい内容（編集前のPDFの内容が維持されない）になるようです。
次の図は、Wordと「Antenna House PDF Driver」でオリジナルPDFを作成し、Acrobat 8でオリジナルのPDF（左）に、1行追加して上書き保存（中央）し、さらに一行追加して上書き保存（右）したものです。
・オリジナルPDFファイルをダウンロード
・1行追加して、上書き保存したPDFファイルをダウンロード
・さらに1行追加して、上書き保存したPDFファイルをダウンロード
一般にPDFファイルは、%%EOFが区切りになっています。そしてファイルの最後には必ず%%EOFが入ります。そこで、この3つのPDFファイルで%%EOFが入っている位置に注目して図に示しますと次のようになります。
（注）正確には%%EOF位置の後ろの改行コード（0D0A）の0Aの位置を示しています。
増分更新では、編集前の古い世代のPDFがそのまま保持され、%%EOFの後ろに、変更した内容が追加されます。Acrobatのマニュアルには「ファイル」-「復帰」メニューで増分更新したPDFを前の世代に戻せると書いてありますが、なぜか、このPDFではメニューがグレーになってしまっています。
そこで、バイナリエディタで、%%EOFを区切りにして、追加された部分を削除してみました。次のPDFは、「さらに1行追加して、上書き保存したPDFファイル」をバイナリエディタで開いて、0e30以降を削除したものです。
・さらに1行追加して、上書き保存したPDFファイルから0e30以降を削除したPDFファイルをダウンロード
これをご覧いただきますと、増分更新された部分を強制的に削除すると、オリジナルPDFに戻っていることが分かります。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月10日
Distiller がOffice 2007フォーマットに対応の謎！？
Acrobat 8.1のアップデートページを見ますと、
Acrobat DistillerがOffice 2007のフォーマットに対応：docx, xlsx, pptx, docm, xlsm, xlsb, pptm
とあります。「げー！これは大変だ！当社の『サーバベース・コンバータ』に強力なライバルが出現！？SBCは3年掛かって漸く売れるようになったのにーっ！」と思い、あわてて、Acrobat 8.0を8.1にアップデートして、チェックしてみました。
Acrobat 8.1にしますと、確かに、Distillerも、8.1になっています。
で早速、Office 2007のファイルをDistillerにかけてみました。
しかし、ログファイルに出てくるのは、次のようなエラーメッセージばかりです。
%%[ Error: undefined; OffendingCommand: PK ]%%
%%[ Flushing: rest of job (to end-of-file) will be ignored ]%%
%%[ Warning: PostScript error. No PDF file produced. ] %%
PDF への変換時間 : 00 時間 : 00 分 : 00.125 秒
Distillerで、Office 2007の文書を本当にPDFに出来るのでしょうか？出来るとしても、Disitillerって、PostscriptからPDFに変換するソフトだと思っていましたが、いつの間に、Office対応になったんでしょうか？
この謎は、まだ、解けていません。
どなたか、ご存知の方いらっしゃいますか？
【2007年6月11日追記】
この文章は
「Office 2007文書をPDFMaker、またはAdobe PDFプリンタ経由でAdobe PDFに変換可能」
に変更されました。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月09日
アンテナハウスPDF Driver V3.2 のシングル・ライセンス・ダウンロード販売開始
アンテナハウスでは、2007年6月8日より、「Antenna House PDF Driver V3.2」のシングル・コピー・ライセンスを、ベクター他のダウンロード販売サイトより一斉に販売開始しました。
弊社では、これまで、「PDF Driver V3.2」は、従来、5本以上のサイトライセンスで販売してまいりました。このため、「PDF Driver V3.2」を1本だけお求めになりたい場合には、「リッチテキストPDF3」など、「PDF Driver V3.2」が同梱されている他の製品をお求めいただくしか方法がありませんでした。
しかし、最近になって、「PDF Driver V3.2」のサイトライセンス販売が増えていることもあり、単体販売を始めたものです。
販売価格は1,880円（税込み）です。
現在、次のダウンロード・サイトでお求めいただくことができます。
(1) ベクター
(2) So-net ソフトダウンロード
(3) インプレス・ソフトウェアダウンロード
(4) Amisoftダウンロード
今後、楽天、ソフトダイレクトなどのほかのダウンロードサイトからも販売開始します。
これにより高速、安定、高品質で定評のある「Antenna House PDF Driver V3.2」をより幅広い層にお使いいただくことを期待しています。
ところで、3年ほど前、V1時代に、 PDF Driverの英語版を一度作成しました。その後、英語版については販売を具体化する機会もなくずっと忘れていました。ところが、USの営業責任者が今週日本に来ていたのですが、彼はずっと、以前に渡したV1の PDF Driver V1の評価版を使い続けているとのこと！彼のPCには、いろいろなソフトに同梱されているPDF DriverがAcrobatを含めて、3種類入っているそうです。しかし、Acrobatは遅いし、当社の PDF Driver V1が一番良いということでずっと使っていたとのことです。なんと、試しに作った英語版の唯一のユーザだったのです。
と言うわけで、もう一度、英語版を作成して、今度はちゃんと売ってみたいと思っています。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月08日
各社 PDF 作成ソフトの機能比較表
ご紹介が遅くなりましたが、日本で販売・配布されている主要なPDF作成用ドライバソフトの新しい機能比較表を下記に用意しています。
●Webページ：各社 PDF 作成ソフトとの機能比較表
JIS X0213:2004全文字を各製品でPDFにしたものが次にあります。これらのPDFで実際にお確かめいただくことができます。
・Antenna House PDF Driver 3.2
・Acrobat 8 Professional
・SkyPDF Pro 2.53
・クセロPDF2
この表を最初に作りましたのは、4月下旬です。
Acrobat 8.0はVista非対応ですが、6月6日からAcrobat8.1がダウンロードできるようになりました。
8.1でVista対応しています。
ダウンロードページはこちらです。
Adobe Acrobat 8.1Professional/Standerd アップデート - 日本語、英語、フランス 語およびドイツ語版
・Windows Vista、Office 2007に対応となっていますので、Acrobat 8.1も上の表では全て○となります。
また、昨日、「日経パソコン」6月11日号が手元に届きました。
今週号は、特集2で「PDF万年初心者クリニック」という、面白い記事が掲載されています。この記事の中(p.70)にPDF製品の一覧表が掲載されています。
それによりますと、これから発売されるPDFドライバの新しいバージョンとしては、次のものがあります。
・「いきなりPDF Prosessional３」 6月29日発売予定
・「SkyPDF Pro 3.0」 7月発売予定
・「FinePrint pdfFafctory3 Pro」 7月上旬発売予定
ということで、まだまだPDF Driverの熱い戦いは続きそうです。
その一方で、クセロPDFは、どうしたのでしょうか？
4月11日2.0評価版(β版）を出したあと、Vectorのダウンロード（評価版）は、まだ2.0βのままです。正式に2.0になるのはいつのことでしょうか？
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月07日
PDFと署名(38) — ChallengePKIプロジェクトについて
今日は、日本ネットワークセキィリティ協会（JNSA）の2007年度定時総会が開催されるということで、オブザーバとして見学させてもらいました。
いままで、JNSAについては、まったく知りませんでしたが、このところPKIについて調べていて、このような団体があることを知りました。PDFの電子署名は果たして、セキュリティと言えるのかどうか、疑問がないでもありませんが、公開鍵暗号化方式という根っこのところでは、セキュリティ技術に関係があることは確かです。
と言うわけで、「Challenge PKI」という活動に関心をもちました。
Challenge PKIのプロジェクトでは、PKIの相互運用性に関するテストスイートを作っています。
(1)最新版のテストスイート：
Challenge PKI Test Suite (CPKI-TS) 2.0 2004年7月版
a. GPKIテストスイート：１台のパソコン上に、ブリッジ、府省及び民間の認証局(CA)を擬似的に構築でき、GPKIの環境をシミュレートできる。
b. タイムスタンプ局を相互運用できるシミュレート機能もあります。
当社でも、ちょうど、PDF電子署名のテストを行う必要がありますのでこういうテストスイートがあると大変助かります。
(2) UTF8String問題
電子証明書などにつかう文字コードの符号化方式として、PrintableString、IA5String、T61Stringなどが古くから使われていました。ところが、最近は、UTF8stringが定義され、
RFC3280：Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
によりますと、December 31, 2003 から、一部ですが、UTF8Stringを使用しなければならないとなっています。
ChallengePKIプロジェクト・ページの情報では、これに対してUTF8Stringは、まだ実装しているアプリケーションが少なくて急いで、UTF8Stringを使った電子証明書を出す必要はない、としています。
UTF8String問題についての注意喚起が公開されました。(2003/12)
UTF-8問題と移行のシナリオ 島岡 政基
このあたり、実態は、一体どうなってるのでしょうか？
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月06日
ウェブに公開した PDF の保存を禁止する。
PDF をウェブに公開した際に、ユーザのコンピュータに保存できなくしたいというご要望をしばしばお受けしますが、通常、ブラウザで表示される際にはすでにローカルにキャッシュされていますので、これは難しい話です。
それでも、抑止的な方法（裏技？）ならあります。それは Acrobat プラグインの「メニューバー」、「ツールバー」を非表示にするという方法です。
この方法を使用した PDF はネット上で見かける機会がありますが、これに加えてさらに JavaScript を使用してブラウザのメニューバー等を非表示にした状態で PDF を表示をさせているサイトも見かけます。どのサイトも意図しているのは、閲覧のみにしたいということでしょう。
たしかに、「メニューバー」、「ツールバー」の表示 / 非表示を PDF の設定で切り替えることができるのをご存知ない方が対象でしたら、これらは効果的だと思いますが、実際のところこの PDF は「メニューバー」、「ツールバー」を非表示にしているだけですから、それを表示する方法もありますし、Acrobat にもショートカットとして記載されています。
【F8】ツールバーの表示 / 非表示
【F9】メニューバーの表示 / 非表示
先ほど開いた PDF もショートカットを使用すれば見慣れたレイアウトに戻ってしまいます。
残念ながら、現在のところ件名の要望に完全にお答えする方法はないようです。
投票をお願いいたします
投稿者 numata : 08:00 | コメント (1) | トラックバック
2007年06月05日
日本語スタイルシート技術の検討のご紹介
日本印刷技術協会（JAGAT）の2006年度活動「縦組みスタイルシート作業部会」の報告が次のところに公開されています。
現在、W3CのCSSやXSL-FOなどのスタイルシート技術を使って電子ドキュメントを組版することが普及し始めています。その際、CSSやXSL-FOには日本語の組版に必要な機能が不足していることから、日本語組版に必要な機能を整理することを行っています。
JAGATのWebページでも説明されていますように、この作業部会の成果の一部は、昨年ドイツで行われたW3Cのプリントシンポジウムで報告されました。
○関連
2006年10月18日 W3C Print Symposium 2006 (1)
2006年10月19日 W3C Print Symposium 2006 (2)
2006年10月20日 W3C Print Symposium 2006 (3) XSL-FOとCSSの互換性
2006年10月21日 W3C Print Symposium 2006 (4) XSL-WG
2007年02月20日第22回多言語組版研究会 — 「縦組の組版方法と組版指定交換形
式」を開催しました
2007年02月23日日本語組版はグリッドベースで行うと言って良いのか？(1)
2007年02月24日日本語組版はグリッドベースで行うと言って良いのか？(2)
2007年02月25日日本語組版はグリッドベースで行うと言って良いのか？(3)
2007年02月26日日本語組版はグリッドベースで行うと言って良いのか？(4)
2007年02月27日日本語組版はグリッドベースで行うと言って良いのか？(5)
2007年03月03日日本語組版はグリッドベースで行うと言って良いのか？(6)
2007年03月04日日本語組版はグリッドベースで行うと言って良いのか？(7)
投稿者 koba : 08:00 | コメント (1) | トラックバック
2007年06月04日
PDFと署名(37) — ハッシュ・アルゴリズムの進化
前回、ハッシュ・アルゴリズムについて、少し取り上げました、ここで、ハッシュ・アルゴリズムの種類と脆弱性について調べてみます。
以前に、公開鍵暗号方式の説明をしたときは、詳しい仕組みやアルゴリズムまで踏み込むのはあまり関係ないのかな、と考えて、ハッシュ・アルゴリズムについては説明を省略してしまいました。
2007年04月05日PDFと署名(4) — 公開鍵暗号方式を署名に使う
ハッシュ・アルゴリズム（ハッシュ関数）については、こちらをご覧ください。
ハッシュ関数
文書をハッシュ・アルゴリズムに入力し、出力されたデータをハッシュ値と言います。または、ダイジェスト値と呼ぶこともありますし、電子政府のWebページでは、フィンガー・プリントと呼んでいます。
電子署名では文書を丸ごと秘密鍵で暗号化するのではなく、文書のハッシュ値を計算し、そのハッシュ値を秘密鍵で暗号化します。そして、(1)オリジナル文書、(2)ハッシュ値を暗号化したデータ、そして(3)公開鍵を相手に渡します。受け取った相手は、暗号化されたデータの暗号を解いて求めた（オリジナル文書の）ハッシュ値と、受け取った文書から改めて計算したハッシュ値を比較して、その両者が一致すれば、受けとった文書が改竄されていないこと、そして、公開鍵とペアになる秘密鍵の所有者が暗号化したことを認めることになります。
4月5日の図を、上の説明に合わせて書き直しますと、次のようになります。
ハッシュ・アルゴリズムの真髄は、(1)ハッシュ値はオリジナルに比べて非常に小さいこと、(2)入力されたデータが少しでも違っていればハッシュ値が異なること、(3)異なるオリジナルデータからは同じハッシュ値にならない（衝突が起きない）ということになります。
但し、この(1)～(3)を全部達成するのは不可能なことは明らかです。仮に元の文書が、1万文字（2バイト／文字）とすると2万バイトになります。2万バイトの情報の改竄パターンは、意味のある情報になるかどうかを別にすると、最大で2の8万乗-1だけあります。ハッシュ値を128バイトとしますと、ハッシュ値で表現できるパターンは2の(128×8）乗です。ですので1ハッシュ値あたり大体2の78乗回の衝突が起きるはずです。しかし、衝突が起きる確率は極めて小さい（2の78乗÷2の8万乗）のです。
このようにハッシュ・アルゴリズムで計算したハッシュ値は衝突が不可避なわけです。しかし、ハッシュ値が同じになる（衝突が起きる）ような改竄方法を短時間で計算できてしまうと問題になります。
これに関連して、最近は、暗号の専門家の会議で、ハッシュ・アルゴリズムの脆弱性がいろいろと報告されています。
MD5を含む各種ハッシュアルゴリズムに欠陥か
暗号アルゴリズムに重大な欠陥発見の報告相次ぐ
SSLやPGPで使われているSHA-1アルゴリズムにセキュリティ欠陥――専門家が指摘
これに対しては、「 CRYPTREC暗号技術監視委員会事務局 」から、次のような公告も出ています。
ハッシュ関数SHA-1及びRIPEMD-160の安全性について
現在のところ、電子署名ではSHA-1を使っていることが多いのでSHA-256 以上に移行するのは難しいのですが、タイムスタンプのような新しい技術では、新しい技術を採用するのが比較的簡単、ということで日本の商用タイムスタンプ局は、ハッシュ・アルゴリスムとしてSHA-512を採用しているようです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月03日
XPS vs PDF 10年後はどうなる？
昨日、10年後に電子文書の世界がどうなるか、について雑談をしたのですが、以下は、その時話したことのメモです。
現在の時点で、電子文書といえばPDFということになります。
PDFが米国で生まれたのは1993年です。まだ、10数年しか経過していません。日本語版は1997年のAcrobatバージョン3からですので、日本語版は今年で10周年ということになります。
今年は、PDFの強力なライバルとして、マイクロソフトのXPSが登場しました。既に、XPS出力をサポートし始めているサードパーティ製品も登場していますし、遅かれ早かれ、我々もXPS出力をサポートすることになるでしょう。従って、電子文書の今後10年を予測するのは、XSPの将来を占う、ということとほとんど同義になるように思います。
それについて思い出しますのは、ネットスケープの盛衰です。
もう、なくなってしまいましたが、1980年代から1990年代にかけて、アメリカのコンピュータ関係の最大の展示会といえば、ラスベガスで開催された秋のCOMDEXでした。COMDEXに初めてInternetExplorerが登場したのは、多分、1995年ではないかと思います。その時、COMDEXには、インターネット関連の製品が雨後の竹の子のように現れて、沢山のブースで展示されていました。
そのブースの展示を見て回って驚いたことに、マイクロソフト以外のほとんどすべてのブースでは、インターネット製品のデモにネットスケープ・ナビゲータを使っていました。インターネット・エクスプローラを使っていたのはマイクロソフトのみ。ですので、マイクロソフトは「99対１」で負けていたという印象が強く残っています。
それから10年経過した、現在の状態は、皆さんがよくご承知の通りです。最近は、FireFoxが少し頑張ってシェアを取っていますが、インターネット・バンキングなんてIEしか対応していないものもあります。
そこで、PDFとXPSを対抗技術とみますと、現在、当時と同じようにマイクロソフトは「99対１」で負ている、と言って良いでしょう。では、10年後にPDF対XPSは、「10対90」になるのでしょうか。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (1) | トラックバック
2007年06月02日
XSL Report Designer V2.1 を発売
アンテナハウスは、6月1日にXMLデータをレポート形式で出力するためのレイアウトをデザインする「XSL Report Designer」のV2.1の日本語版と英語版を同時にリリースしました。
本製品は、XMLを綺麗にレイアウトするためのレイアウト指定言語「Extensible Stylesheet Language」（XSL-FO)に準拠するレポートをWindowsの画面上で対話的にデザインするソフトです。
レイアウトした結果からXMLをXSL-FOに変換するためのXSLスタイルシートを自動生成することができます。通常、XSLスタイルシートを開発するには、XSLスタイルシートに関する詳しい知識が必要です。しかし、本製品を使いますと、XSLスタイルシートの開発の工数が不要になります。
また、XMLデータをXSL-FOに変換するのに、本製品添付のJAVA版ランタイム・エンジンを使うこともできます。ランタイム・エンジンを使うと、XSLスタイルシートでは使うことのできない計算機能などが利用できます。
「XSL Report Designer V2.1」では、新たに、次の機能を強化しました。
○表のスパン機能
表において、複数のセルをまとめることができるスパン機能。これによって、Excelのように表スパンを使った表が設計できるようになりました。
○オブジェクトのグルーピング機能搭載
レイアウト時に、オブジェクトをまとめて、グループとして扱うことができるグルーピング機能を搭載。オブジェクトのレイアウトがさらに簡単になりました。
○便利な吸着モード
レイアウト時に、オブジェクトを移動する際、直近の角に吸いつく吸着モードを搭載。オブジェクトのレイアウトがさらに簡単になりました。
○スタイルシート出力の強化
V2から搭載され、大変、ご好評をいただいている「XSLスタイルシート」出力機能を改良し、表のスパンに対応した出力ができるように改良しました。
■本製品についての詳しい情報
○日本語版 http://www.antenna.co.jp/designer/
○英語版 http://www.antennahouse.com/product/designer/
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年06月01日
PDFと署名(36) — ハッシュ・アルゴリズムについて
さて、昨日の続きですが、「PFU タイムスタンプの使い方」2006年5月版 P.57/60 には、さらに、PFUのタイムスタンプは、「V2.0L10から、PDF文書からのハッシュ生成アルゴリズムを、より強固なものに変更しています」として、SHA-512ハッシュアルゴリズムおよびSHA-512withRSA署名アルゴリズムを使っていること。そして、「これらに対応していないAcrobat署名プラグインでは、正しい検証結果が得られません。」と書いてあります。
ところが、PDF Referenceによりますと/adbe.pkcs7.detachedは、メッセージダイジェストとして以下の5種類をサポートしています。
・SHA1 (PDF 1.3)
・SHA-256 (PDF 1.6)
・SHA-384 (PDF 1.7)
・SHA-512 (PDF 1.7)
・RIPEMD160 (PDF 1.7)
出典：PDF Referefnce 1.7 740 ページの表
とあります。なので、単純にアルゴリズムをサポートする・しないだけの観点で言えば、Adobe Reader内蔵のデフォルトハンドラでもSHA-512はサポートしていると言えます。
じゃあ、なぜAdobe readerのデフォルト署名ハンドラで、PFUのタイムスタンプが検証できないのか、これが以前として疑問です。
そこで、PFUのタイムスタンプ・ハンドラが作成している署名値を、少し調べてみることにしました。
PDFでは、署名値は署名辞書のContentsキーに保存されています。
Contentsキーの内容は、署名対象PDFの署名対象範囲（ByteRange）のダイジェストになります。公開鍵方式で署名する場合は、この値はPKCS#7のバイナリデータをDER符号化したものである、とされています。
PKCS#7とDER'について：
PKCS#7: RFC2315 Cryptographic Message Syntax Version 1.5
DER:Distinguished Encoding Rules
この中を見るのはとても大変そうですが、都合の良いことに、DER符号化したPKCS#7のデータをXMLにするツールがラング・エッジのWebサイトから入手できます。
これで見ますと、PFUのPDFタイムスタンプ・サンプルの署名値は次のようになります。
PFUのタイムスタンプ・サンプルPDFの署名値PKCS#7をXML化したもの
投票をお願いいたします