PDF　千夜一夜

« 2007年11月 | メイン | 2008年01月 »

2007年12月31日

PDF電子署名モジュール・英語版を発売

アンテナハウスは、このほど、米国で電子署名モジュールの英語版「Rainbow PDF Digital Signature」を発売しました。

Rainbow PDF Digital Signature

弊社は今年11月にRainbow PDFブランドを立ち上げ、それ以前より、販売していました英語版の「サーバベース・コンバータ」、「リッチテキストPDF3D&D」を、それぞれ、Rainbow PDFのブランド下に再編しました。今回の電子署名モジュール・英語版を加えて、3商品目になります。

2008年には、さらに「リッチテキストPDF4」の英語版、「書けまっせ!!PDF3」の英語版をリリースする予定です。

Rainbow PDFは、現状では、漸く欧米市場へ「敵前上陸」を果たしたばかりとでも言うべき状態ですが、2008年は、品揃えを強化して、大陸侵攻作戦です。

PDFは、恐ろしく競争の激しい分野ですので、こういう領域でブランド構築に成功できれば何をやっても成功できるでしょう。来年が楽しみです。

さて、今年も今日が最後となりました。1年間「PDF千夜一夜」をお読みいただきありがとうございました。皆様も、良いお年をお迎えくださいますよう。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月30日

PDFの世界標準ISO 32000がISO標準になったら？（4）

昨日は、PDFの仕様ISO DIS 32000が、ISOの標準規格になったら、ますますPDFソフトの種類が増えるだろうもお話しました。

2007年12月29日　PDFの世界標準ISO 32000がISO標準になったら？（3）

では、そのようなPDFソフトはすべてISO規格準拠と主張できるのでしょうか？もし、そうだとしますと、自称ISO準拠のPDFソフトが雨後の筍のように登場することになります。

そうなりますと、何からの基準をもって、PDFソフトがISO規格準拠かどうかを認定することが必要となるでしょう。そうしないと、自称ISO準拠のPDFソフトで作成したPDFを相互運用できないことになります。そうなればISO規格の権威は地に堕ちてしまいます。

ISOの規格で最も成功したのは、組織の品質管理に関する規格ISO9000ファミリーだそうです。

ISO9000では、審査登録機関があって、そこで認定を受ける仕組みがあり、世界で80万箇所の事業所が認定を受けているのだそうです。ISO規格をベースとするコンサルティングが大きなビジネスになっているようです。

将来的には、PDFも、恐らくこのような認定が行われるようになるのではないかと思います。PDFの場合は、供給者が何十万箇所にのぼることは考えられませんので、認定ビジネスを成立させるのは、かなり難しい課題かもしれません。

しかし、PDFは将来的には紙の代わりに世界中に流通するメディアになるでしょうから、相互運用を保証するための認定の仕組みが必要ではないかと思います。必要性があればビジネスが生まれるのは自然。きっとどこかで誰かがそのようなサービスを始めることでしょう。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月29日

PDFの世界標準ISO 32000がISO標準になったら？（3）

これまで何回か指摘していますが、紙は2000年以上の歴史をもち、現代でも情報媒体として、プリント媒体は非常に有力なのは間違いありません。日本での紙の生産量は、電子化・ペーパーレスが叫ばれる今でも純増になっているそうです。

一方、情報を出版したり、交換したり、蓄積する媒体として考えますと、紙はあまり効率が良くありません。特に、遠隔地に送付したり、膨大な量の情報を蓄積したり、あるいは、検索などを考えますと効率が悪いのは明らかです。紙ベースで業務を進めるようなシステムでは、数人の企業であればともかく、中堅以上の企業では、電子的なシステムに効率面でまったく対抗できないでしょう。

一方、情報を可視化し、閲読するための媒体として紙は非常に有力です。そうしますと、電子化・デジタル化された情報を紙媒体を前提として可視化するという方法は、電子化された・デジタルの世界と人間の可視世界とをつなぐ非常に重要な手段となります。

このデジタル情報を紙媒体に可視化する、という点で、現時点でもっとも有力な媒体はPDFです。しばらくの間、恐らく10年やそこらの期間、その地位が揺るぐことはなさそうです。

私は、日本ではPDFについて、あまり好意的・前向きに評価していない人が多いような印象を受けています。日本では、欧米に比べて、ややPDFの採用が遅れているように思います。

しかし、PDFが世界標準になることで、官公庁や行政をはじめ、日本でもPDFの利用にますます拍車がかかることは間違いありません。

需要が膨らめば、供給が増えるのが経済の原則でしょう。そうしますと、PDFの供給元が増えて、PDFの種類がますます増えてきます。

情報交換の媒体にPDFを使うということを円滑に実現するには相互運用性が重要です。アドビ製品だけで話が済んでいた時代には、相互運用性はあまり問題にならないでしょうが、供給元が増えて、さまざまなPDFが出てきますと、相互運用性をどう維持するかが、最も重要な課題となるように思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月28日

第一回国際PDF/A会議開催　

2008年4月10日から11日にアムステルダムで、第一回国際PDF/A会議が開催されます。

主催は、ドイツのPDF/Aコンピタンス・センターで、アドビを初めとする世界のPDF/Aの専門家を集めての会議だそうです。

また、欧州特許庁などのユーザの事例の発表が予定されています。

●場所：アムステルダムのヒルトン・ホテル
●参加費用：870ユーロ（2月15日までの早期登録は、720ユーロ）です。

詳細はこちらをどうぞ。
http://www.pdfa.org/doku.php?id=events:pdfa_conference_amsterdam:en

●会議のプログラム
http://www.pdfa.org/doku.php?id=events:en:pdfa_conference_agenda

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月27日

PDF Tool API によるページ順の並び替え

昨日に引き続いて PDF Tool API の話になりますが、コマンドラインで PDF のページ順の並び替えや特定ページの削除の方法についてお問い合わせをいただくことがあります。この場を借りてまとめてその方法をご説明します。

PDF Tool API のコマンドラインでそれらを実現するには、-mergeFile コマンドを使用します。-mergeFile コマンドは PDF（ページ）の結合・抽出を行うものですが、この機能を利用してページ順の並び替え等を実現します。実際のコマンドラインは以下のようになります。

○ PDF のページ順の並び替え
たとえば、100ページの PDF の表紙（1ページ）を最終ページに移動したい場合、まず、-d オプションで指定した入力 PDF の後に、パスワードが設定されているのなら、パスワードを指定し、ない場合は "" を指定します。その後に抽出するページを指定するのですが、今回の場合でははじめに 2ページから 100ページを抽出して、次に表紙（1ページ）を抽出しますので、「2-100,1」という記述になります。

　AHPDFToolCmd26.exe -mergeFile -d D:\input.pdf "" 2-100,1 -o D:\output.pdf

○ 表紙ページを削除
100ページの PDF の表紙（1ページ）のみを削除する場合ですが、先ほど例に挙げたサンプルを改変して、1ページ目の移動を止めて「2-100」と記述すれば OK です。これで、2～100ページのみの PDF が作成（＝抽出）されます。

　AHPDFToolCmd26.exe -mergeFile -d D:\input.pdf "" 2-100 -o D:\output.pdf

○ 別の PDF の特定ページとの置き換え
また、この 100ページの PDF の表紙（1ページ）を他の PDF（another.pdf）の表紙（1ページ）と入れ替える場合は次のようになります。

　AHPDFToolCmd26.exe -mergeFile -d D:\another.pdf "" 1 -d D:\input.pdf "" 2-100 -o D:\output.pdf

以上が PDF Tool API による PDF のページ順の並び替えの実現方法となります。Antenna House PDF Tool は、評価版もご用意しておりますので、ご興味のある方はぜひお試しください。

投票をお願いいたします

投稿者 numata : 08:00 | コメント (0) | トラックバック

2007年12月26日

PDF Tool API でセキュリティを外す方法

先日、PDF Tool API のコマンドラインでセキュリティの掛かった PDF のセキュリティを解除する方法についてお問い合わせをいただきました。たしかにマニュアルにも記載していない方法ですので、この場を借りてご説明させていただきます。

コマンドラインの記述自体はいたって簡単でして、-changeInfo コマンドを使用して、パスワードの指定をせずに出力していただければ、セキュリティ設定のされていない PDF が出力されます。

たとえば、ユーザパスワードに "1"、オーナーパスワードに "2" が設定されている元ファイル「1-2.pdf」をセキュリティ無しの PDF として出力する場合、以下のようなコマンドラインになります。

　AHPDFToolCmd26 -changeInfo -d D:\1-2.pdf 2 -o D:\output.pdf
　※ -d で指定した入力ファイル名の後ろにオーナーパスワードを指定します。

ただし、上記のコマンドラインの場合、「文書情報」（「タイトル」や「作成者」等）が削除されてしまいます。それらを継承する必要があるならば、以下のように -ofd オプションを付加してください。

　AHPDFToolCmd26 -changeInfo -d D:\1-2.pdf 2 -o D:\output-2.pdf -ofd

現在、PDF Tool API では、「文書情報」以外の PDF の「開き方」等を継承するオプションはご用意しておりませんので、必要に応じてコマンドラインにオプションを設定していただく必要があります。

・Antenna House PDF Tool

投票をお願いいたします

投稿者 numata : 08:00 | コメント (0) | トラックバック

2007年12月25日

PDFの世界標準ISO 32000がISO標準になったら？（2）

前回の「PDFの世界標準ISO 32000がISO標準になったら？（１）」に続いて、もう少し考えて見ます。それは、2008年のPDFの行方を占うことでもあります。

PDFのISO規格の成立までの過程について、いまひとつ、まだ良く分かっていませんが。

先日、XML開発者の日に、OOXML（Office Open XML形式）のBallot Resolution Meeting（BRM)について村田さんの説明がありました。

その日の説明では、確か、「OOXMLはISOのFast Trackの投票は通過しなかったのですが、投票に際して寄せられたコメントに対して提案者であるECMAが対応する回答を準備中。BRMにおいて、その回答に基づいてOOXML規格書の変更について審議、BRM終了後1ヶ月以内にECMAは最終規格案を作成する。それに基づいて各国は、賛成、反対、棄権の投票を変更できる。最終的に、2/3の賛成があれば、規格案はISO規格として採用される」、ということだったと思います。

一方、PDFのISO規格であるDIS 32000は、ISOのFast Trackの投票を通過しました。
2007年12月06日　PDF仕様　ISO投票を通過

で、この後の予定について、AIIMのブログ

Next Steps for ISO/DIS 32000

には次のようにあります。

・投票を通じて、多数のコメントを受け取った。その大部分は文章に関わるものであるが、それを規格書の改訂案に盛り込む必要がある。
・反対の投票をした人は、コメントの扱いについて満足した場合、態度を賛成に変更することができる。

・もし、反対投票者が、コメントによって賛成に変更しなかった場合、修正された規格書を対象に2ヶ月の投票期間で再投票する。
・反対投票者が、コメントで賛成に変ったらコメントによる修正をISOの規格書に盛り込み、即、出版となる。

Fast Trackの投票で、賛成多数で通過したPDFの規格案と、賛成表が足りなかったOOXMLの規格案で、その後の規格書出版までの手続きがどのように違うのか、あまり良く分かりませんが、「OOXMLはBRMでは決着しないで必ず再投票になるが、PDFは再投票なしにBRMで決着する可能性がある」ということなのでしょうか？

投票をお願いいたします

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年12月24日

第10回XML開発者の日(3)

全体のメモがこちらにあります。よく、ずっとメモしていたものだ。
http://d.hatena.ne.jp/StL/20071221/p1

ジャストの舛形さんの、XML-IMの話を聞いて、アンテナハウスXML Editorで少し試みた、「入力支援」機能を思い出しました。

XML-IMの場合は、IMEで文章を入力していくときに、文字列に対して紐づけたXML要素をIMEで文字を入力するときに選択可能にしようというものです。

アンテナハウスXML Editorでは、DTDを元にして、DTDからその位置で入力可能な要素の候補リストアップしていこうというものでした。途中までやって中途半端なままで、もう、7,8年止まったままになっています。

このように、XMLの要素をどうやって簡単に入力するかというのは、エディタを作る場合のかなり大きな課題です。

人間にとってXMLを簡単に使えるようにするには、タグの入力とかオーサリングが大きな問題ですが、XMLのオーサリング技術って、この10年位あまり進歩してないような気がします。

この10年の進歩といいますと、やはりxfyがでてきたことでしょうか。ｘｆyでかなりいろいろできるようになったのは、大きな進歩と言って良いような気もします。

しかし、xfyでDITAのような高度なXML文書の編集ができるのだろうか？

そういえば、DITAの編集で、いま一番良いエディタは、Syntext Serna、それに近いのがOxygenXML Version 9という話が出ていたのを思い出しました。

Oxygen XML V9 Now Just Works: Here's How
http://tech.groups.yahoo.com/group/dita-users/message/8382

ぜひ、xfyでDITAに挑戦してみてもらいたいものです。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月23日

第10回　XML 開発者の日(2)

昨日に続き、第10回XML開発者の日で、面白かった内容につきまして。

セッション4で、村田　真さんが、「Atomとその拡張を検証するためのスキーマ」という題で、Atomに要素や属性を追加して拡張した複合文書を検証する方法について報告されました。

XMLでは名前空間を使うことにより、さまざまなスキーマのXMLを自在に組み合わせることができます。
Atomに限らず、ODF（Open Document Format）、OOXML（Office Open XML形式）などで、あるひとつのスキーマのXMLの中に、他のスキーマのXMLを入れて、複合文書を作る例が増えています。

こうした複合文書を検証するための仕様としてNVDLという仕様があるようです。（もう、かなり昔からやているようですが、知りませんでした。）

NVDL：Namespace-based Validation Dispatching Language
http://nvdl.org/

NVDLは、複合文書XMLの大きなツリーを、名前空間毎の個別スキーマの枝毎に切り離して、単一スキーマのXML文書にし、個々に検証しようという仕様のようです（多分）。

それから、IBMの基礎研究所の宮下さんによる、NVDLで切り離してシンプルなXMLファイルにしたものを、もう一度、組み立てるプログラムのデモがありました。

問題としては、Atomにせよ、ODFにせよ、名前空間をきちんとした方針で使い分けているわけではなく、単に要素名の衝突をさけるという便宜上の使い方をしているために、複合文書を分割するとやたらに沢山のファイルができたりしてしまうことだそうです。

また、実際に使うXML文書の要素には、ユニークなID（識別子）が付いていたり、ある要素からあるIDをもつ要素を参照したり、あるいは、文書要素間で相互に参照しあったりする関係をもっています。そうしますと、複合文書を、名前空間毎に切り離した段階で、IDのユニークさ、あるいは相互の参照などの関係が変ってしまうことになります。これらの問題は、どうもNVDLではうまく扱えないようです。

複合文書を、それを構成する部品に分解したり、部品を組み合わせて複合文書を作ることが自由自在にできるようになると、相当に面白い応用ができそうな気がします。それには、予めそういうことを考えて文書構造を設計しておかないといけないということなのでしょう。

こうしたことを考えますと、NVDL問題もそうなのですが、XML技術は面白いですが、実用上に使いこなすのは非常に難しいものだと思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月22日

第10回　XML開発者の日(1)

21日は第10回XML開発者の日。去年より１ヶ月ほど遅く、暮れの押し迫った季節で忙しかったのですが、1日参加してきました。（来年は、もう少し早めに開催してほしいな）。

プログラム：http://www.asahi-net.or.jp/~eb2m-mrt/kaihatsu10.html

今回は、どうもジャストシステムのプレゼンテーション・デイのようで、半分位xfyとジャストの技術・製品の宣伝だったように思います。

昨年は、宮川さんのPlaggerのプレゼンなどがあって盛り上がりました。今年は、それに比べて、やや目新しさに掛けたようですが、XML技術というのは、それ自体として色々な技術的な挑戦とそれを使った新しい応用があってとても面白いものだと思います。少なくとも文字コードなどよりは面白いでしょう。

で、面白くない方の文字コード関係では、アドビの山本さんによるAdobe-Japan1-6をUnicodeのUTS 37 Ideographic Variation Databaseに登録したという話に、実務的にですが、関心をもちました。

このUTS 37は、もともとは漢字の異体字を登録して使うための仕様として2005年に提案されて、2006年1月に正式な仕様となっていました。要するに、Unicodeにコードポイントのある文字を例えば、U+82A6としますと、その異体字に対してE0100～E01EFまでの240のインデックスを付加することで識別可能とするものです。

今回Adobeが初めて、この仕様をつかって、Adobe-Japan1-6の中の字形を登録したとのことです。

登録された字形とコードはこちらに公開されています。まだ、登録ほやほやで12月14日付けです。
Ideographic Variation Database

例えば、<82A6 E0100> が、Adobe-Japan1-6 のCID+1142に、<82A6 E0101>が同CID＋7961に対応します。

ここに登録された文字を使うUnicodeテキストには、E0100～E01EFのコードが含まれます。従って、アプリケーションは、Unicodeテキストのこの部分を解釈して、それなりのグリフに対応つける必要があることになります（最悪、E0100～E01EFを削除する）。このようなコードが普及する前に、Unicodeテキストを処理するアプリケーションの改造が必要になります。

Adobe-Japan1-6の字形が登録されてしまった以上、今後、他のフォントベンダーなり、他のメーカは、各Unicodeのコードポイントに付随するインデックスであるE0100～E01EFに異なる字形を割り当てることができなくなると思います。

このあたりは、PRをしっかりやって、他のフォント・ベンダ等も協調をとっていただきたいものです。そうしないと、Unicodeテキストをグリフにマップする過程で、字形が思わぬものに置き換わる可能性があります。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月21日

PDFの世界標準ISO 32000がISO標準になったら？（１）

PDF1.7をベースとした、ISO標準（ISO 32000）が来年(2008年）には、標準として認められることはほぼ間違いないと思います。そうなったとき、どんな変化が起きるのでしょうか？置きうるシナリオを考えて見ました。

１．PDF仕様の利用に関する正当性
ユーザは今まではPDFの仕様はアドビのものであり、従ってアドビ以外のPDFを使うことは、ある意味では、アドビの権利を侵害するかもしれないということを心配していたかもしれません。多くのユーザは、そこまで心配をしなくても、アドビのPDFが正統なものであり、多少価格が高くてもアドビの製品を買おうという決定を正当化するものだったと思います。

しかし、PDFの仕様がISO の標準として出版されれば、PDF仕様の利用に関してはこうした心配がなくなります。

このことは、ユーザがPDF製品を、心理的には、自由に選択することができるようになります。一方において、ユーザが自分自身の責任でPDF製品を評価して選択しなければならないことになるでしょう。

普通のユーザにとっては、自分の手で、PDF製品を評価して選択することなどは、あまりやりたくないことでしょうから、第三者の評価、推薦、場合によってはランク付けのようなものに需要が生まれるのではないかと思います。

２．PDF製品のメーカにとっての動機付け
PDF製品のメーカにとっては、いままでは、クローン製品のメーカという立場でしたが、今後は標準仕様をサポートするメーカということになり、PDF製品の供給に、大義名分が与えられますので、大きな動機付けになるでしょう。このことは、PDFをサポートするソフトウエア・メーカが、ますます増えることになり、メーカ間の競争もますます激しくなることは確かでしょう。

３．PDFが正しいかどうかの評価
現在、PDFが正しいものかどうかを評価する基準は、恐らくAdobe Readerで表示できるかどうか、どいうことが第一になっているだろうと思います。

これは、言ってみれば、Webページが正しいかどうかを、ブラウザで表示できるかどうかで評価しているようなものです。

しかし、Webページをブラウザで表示できるかどうかでその正しさを判定するのは、技術的には誤りです。本当は、Webページを記述するためのHTMLやXTHMLの定める文法に合致しているかどうかで評価しなければならないのです。

Webページの場合は、そういう妥当性を検証するツールやサービスはいくつかあります。

・W3CのHTM:/XHTML　検証サービス
・Another HTML-lint

PDFについても同じように妥当性を検証するツールが必要なのですが、現在は、そういうものはないように思います。ISO標準になれば、当然に、そういうものが揃わなければならないと思います。誰がそろえるか？それが課題でしょうけれども。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月20日

Adobe Distiller Server復活

米国のアドビは、Adobe Distiller Serverを復活させたようです。新バージョンは8ですが、新たにPDF/A、PDF 1.7をサポートしたバージョンとして再登場です。

Adobe Distiller Server 8

Distiller Serverは、昨年販売を終了し、後継製品としてLiveCycle PDF Generatorが提供されていました。日本では、アドビPDFサーバ製品の日本におけるもっとも強力なパートナーといわれる日立ソフトのWebページには、Distiller Serverは販売終了したと紹介されており、移行キットも販売されています。日本ではどうするんでしょうね。

○日立ソフトのWebページ
一応、記念として、ここにスナップショットを上げておきます。

将来、担当者の方が振り返って、ああ、こんなこともあったんだなと懐かしむことができますように。

PDF Zoneの記事によりますと、アドビはサーバ製品をすべてLiveCylce製品ラインに移すことを決定したのですが、オリジナルのDistillerを好むお客さんがいて、その人たちがどうしてもLiveCycleに移行しなかったとのこと。

Distiller Server8では、PDF/Aをサポートしているようですが、同じ記事を見ますと、PDF/Aはやはり欧州が積極的なようですね。

Distiller Server8は1サーバ100ユーザで4千ドル。無制限ユーザ版が1万2千ドルとなっています。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (2) | トラックバック

2007年12月19日

PDF 作成方法による速度比較

2007年12月14日　「書けまっせ!!PDF3」12月下旬発売します。

で、「書けまっせ!!PDF2」と「同3」でPDFの作成方法を、Windowsの印刷機能を利用するPDF Driver方式からPDFを直接出力する方式に変更したので、PDF作成速度が体感として速くなったとお話しましたが、実際に計測して比較して見ました。

結果は、次の通りです。
（１）デジタル方式で生成した40ページのPDF（ExcelからPDF Makerで作成）
・「書けまっせ!!PDF2」だと、PDFを3回出力した所要時間平均：15.8秒
・「書けまっせ!!PDF3」だと、PDFを3回出力した所要時間平均： 4.7秒

(2)アナログ方式（スキャナ）で作成した2ページの画像PDF
・「書けまっせ!!PDF2」だと、PDFを3回出力した所要時間平均：4.7秒
・「書けまっせ!!PDF3」だと、PDFを3回出力した所要時間平均：4.8秒

これでみますと、やはりPDFDriverで作成するほうが、時間がかかるようです。

なお、所要時間とは、PDF出力開始から、Adobe Readerで出力したPDFを表示するまでの時間のことで、4秒程度の所要時間は、Adobe Readerが消費しているのではないかと思います。

いづれにせよ、「書けまっせ!!PDF3」の方が、PDF作成速度はかなり速くなっていることが、数字でも分かりました。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月18日

WebFontについて(2)　もう少し

昨日、お話しましたWebフォントについて、もう少し。

CSSの提唱者であるHåkon Wium Lieさんのブログに、少し古いですがWebフォントの記事とサンプルがあります。

CSS @ Ten: The Next Big Thing

通常の印刷では、様々なフォントを使うことができるのに、Webのデザイナーは、10種類やそこらの、普遍的に入手可能なフォントを使ってデザインしなければならない。

などとあり、Webフォントを使ったページデザインの例、WebフォントのCSSによる使い方の説明が出ています。

○Webフォントの歴史

Webフォントは、1998年にCSS2で、スタイルシートからフォントをリンクする方法が説明されており、MicrosoftとNetscapeがサポートしたのですが、(1)両方ともTrueTypeをサポートしなかったこと、(2)両者が、それぞれ別々に、EOTとTrueDocというあまり使われず、ツールもないフォーマットをサポートしたために、忘れ去られていたんだそうです。

なるほどー。

いまは、一般的でないフォントを使おうとすると、画像化してからWebページに貼り付けるしかないようです。

Håkonさんのブログで紹介されているCSSZen GardenのWebページも一部の文字は画像化して埋め込まれているものです。

こういう使い方はやはり変態的ですし、確かに、いろんなフォントを自由自在に、簡単に使えるようになればWebページの表現は、もっと楽しいものになりそうです。

しかし、考えて見ますと、PDF（あるいは、電子文書）へのフォント埋め込みを許諾しているフォントは多いですので、PDFへのフォント埋め込みと同じレベルで、HTML+CSSへのフォント埋め込みを可能にできないのでしょうかね。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年12月17日

WebFontについて

HTMLからWebサーバに置いたフォントをアクセスして、端末に表示するWebFontのフォーマットとして、MicrosoftのEOTフォント埋め込み形式がW3CのCSSワーキング・グループに提案されたようです。
※注意　これは、W3CのCSSワーキングで検討中の項目であり未公開です。W3Cとして正式に決定したものではないと思います。

このことが、次のAdobeのTypblography, the Phinney-us Blogに紹介されています。
Web font embedding returns: Survey!

Webフォントが使えるようになると、クライアントにフォントがなくても、サーバ側からフォントをダウンロードして表示可能になりますので、Webページのデザイン上のメリットは大きいと思われます。しかし、一方において、多くの商用フォントではこのようなフォントの使い方は許諾されていません。

従って、WebフォントをCSSとブラウザがサポートすると、商用フォントの不正使用を助長する可能性があるということで、Phinney氏のブログでは、多くのコメントが寄せられています。

また、ブログサイトでのアンケートの結果が公開されました。

Web fonts: user survey results

Q1　Webページ用のフォントの選択について

（1）印刷に使っているのと同じフォントをWebページに使えること：「致命的に重要」と「極めて重要」との回答が65%
（2）既存の視覚的に同等性を保つ部分で、Webでも同じフォントを選択できる：「致命的に重要」と「極めて重要」との回答が81%

Q2　Webフォントの仕組みとしてどういう仕組みが望ましいか？

フォントの使用条件で許諾されたフォント（全体の3-5%）のみを使用可能とする意見よりも、プレビューと印刷を許諾されたビットマップをもつフォント（全体の半分）を使用可能とする方が望ましい、という意見が多い。

Q3　フォントの使用ライセンスに関する意識

かなり多くの回答者は、フォントが合法的に使用可能かどうかをチェックする、と回答しています。

このアンケートを見る限り、Webフォントについての需要はかなり大きいのではないか、という印象をもちます。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年12月16日

電子帳簿保存法 — 知っていますか？「見積書を全部保存しないといけない」ってこと

2007年07月04日　電子帳簿保存法で、成立しなかった取引の見積書保存義務に関する疑問について触れましたが、これについて、未だに疑問が解消できませんので、もう一度立ち返って調べて見たいと思いたちました。

まず、上のブログでお話しましたように、当日の国税担当官は、「取引に関して、相手方から受け取った注文書、契約書、送り状、領収書、見積書その他、これらに順ずる書類及び自己の作成したこれらの書類でその写しのあるものはその写しを保存しなければならない」（法人税法施行規則第五十九条三項）と述べました。これについて、私が質問したところ、さらに、「成立しない取引の見積書も保存しなければいけない」と回答しました。

調べてみますと、これは、「電子帳簿保存法取扱通達の制定について」という文書（次のURL）
http://www.nta.go.jp/shiraberu/zeiho-kaishaku/tsutatsu/kobetsu/sonota/980528-2/01.htm

の第4章　電子取引　の（電磁的記録等により保存すべき取引情報）の10-1　法第10条（（電子取引の取引情報に係る電磁的記録の保存　に関わる解説（次のURL）
http://www.nta.go.jp/shiraberu/zeiho-kaishaku/joho-zeikaishaku/dennshichobo/050228/05.htm

を元にしているらしいです。実際に見てみますと、そこには、「（2）　メッセージの交換過程で発生する訂正又は加除のデータの取扱い」という項目があります。この解説文章に次のようなくだりがあります。「この場合における訂正又は加除のデータとは、確定データに至る前の情報をいうのであるから、例えば、見積書の場合、前の見積り金額を変更して、新たな見積り金額として確定する場合には、各々の見積り金額が確定データとなるのであるから、最終的に合意に至った見積りデータのみを保存するのではなく、各々の見積りデータを保存することに留意する。」

ここでは、一連の電子的メッセージの遣り取りの中で、見積金額を訂正していった場合、最終的に合意した見積データだけでなく、各々の見積データを保存しなければならない、とあります。

この文章を読む限り、取引が成立したとして、その取引を成立させるためのメッセージを交換する過程で発生する見積データを前提に解説しているように思えます。

そうすると、この通達の解説文からは、冒頭にあげたような成立しなかった取引の見積書の保存義務があるという結論は導き出せそうもないように思います（！？）

そうしますと、平成19年6月29日付けの資料の中にある『平成16年度に定期的に行った国税庁とJIIMAやJBMIAなど関係4団体との協議会の中で、国税庁担当官から見積書を例に上げて、「採用されなかった見積書でも保存の義務があり、これを電子化した場合、検索できなければならない。採用しなかった見積書を電子化文書にして保存しない場合は、当該の見積書を受領した相手方に確実に返却しなければならない。」との説明を受けている。』という、この説明は、国税庁の担当官の拡大解釈・あるいは解釈ミスではないかと思いますが、どうなんでしょうね。

私としては、やはり、あの担当官の成立しなかった取引の見積書を保存しなければならないという回答は、一般論として言うならば、法令解釈のミスではないかとの感を強くしました。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月15日

「リッチテキストPDF4」ファミリ、「書けまっせ!!PDF3」ファミリをベクターよりダウンロード販売開始

12月14日、ベクターより、「リッチテキストPDF4」ファミリ3製品、「書けまっせ!!PDF3」ファミリ2製品の5製品を、ダウンロードにて同時に販売開始しました。

○「リッチテキストPDF4」カタログページ
○「書けまっせ!!PDF3」カタログページ

アンテナハウスでは、昨年末位まで、あまりダウンロード販売に力を入れていませんでしたが、昨年10月からダウンロード販売にかなり力を入れてきました。

ダウンロード販売でそれなりに実績は上がっていますが、まだまだ、目標とする数字には届いていません。

今回の5製品同時発売で、今度こそ目標到達を狙います。

それに、今年は、1月のベクタープロレジ大賞と7月のベクタープロレジ大賞の2回ノミネートされながら、いづれも大賞を逃しています。

2007年01月08日リッチテキストPDF2 D&D ベクタープロレジ大賞にノミネート

いまひとつ、力不足ということでしょうが。3度目の正直で、今度こそプロレジ大賞を取りたいと。もっともその前にノミネートされないといけないですが。皆さま、よろしくお願いします。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月14日

「書けまっせ!!PDF3」12月下旬発売します。

アンテナハウスでは、「書けまっせPDF3!!」を12月下旬より発売します。

詳しくはこちらをご覧ください。
○「書けまっせ!!PDF3」Webページ
○「書けまっせ!!PDF3」発売のお知らせ

既に、「書けまっせ!!PDF3」については、PDF千夜一夜でも何回かご紹介しています。

「書けまっせ!!PDF3」は、紙の用紙にペンでさらさらと記入するような手になじむ使い易さを実現したいと考えて、「ゼロから作り直しをした。」ことは、最初（11月25日）にお話しました。その時は、一番ご要望の多かった文字入力時の操作性についてはWindows標準のリッチエディット・コントロールに代わって、自社開発の「テキスト入力コントロール」を用意したことをお話しました。いま、縦書きもできるエデット・コントロールは、開発のライブラリーとしてもあまり入手できないように思います。これを自社開発したことで、今後も、自社製品のいろいろな面で使えると思います。

さて、もう一つ、外見からは分かりませんが、大きな変更は、文字・線・画像などを入力した後にPDFを作成する方法を、Windowsの印刷機能に依存する仕組みから、直接PDFを出力する仕組みに変えたことです。

以前に、「さまざまなPDFの作成技術の概観」で、アプリケーション・プログラムからPDFを作成するいろいろな方法を整理しました。

■さまざまなPDFの作成技術の概観

その中の図

でご説明しますと、「書けまっせ!!PDF2」までは、⑤の経路でPDFを作成していましたが、「書けまっせ!!PDF3」では、④の経路でPDFを作成するようにしました。

理論的には、かなり早くなるだろうと予想していましたが、結果として、体感的にはPDF出力が相当早くなりました。

それだけではなく、PDF Driverをはずしたことで、Windows Vistaの64ビット版OSでもプログラムを動作させることができるようになりました。「書けまっせ!!PDF3」は、32ビットのアプリケーションです。普通のアプリケーションは32ビット版でも64ビットのOSで動かせるはずです。しかし、プリンタ・ドライバは64ビット版を作らないと64ビットOSで使えないようです。このため、「書けまっせ!!PDF2」は、Vistaの32ビットOSのみ動作保証していました。しかし、今度から64ビット版も保証できるようになり、アンテナハウス・デスクトップ製品では初めてのVista64ビット版OS動作保証というおまけがつきました。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月13日

「書けまっせ!!3」本日発表

アンテナハウスでは、「書けまっせ!!PDF3」を、本日、発表します。

「書けまっせ!!PDF3」は、もう、ブログでも何回か紹介しましたが、今年の期待作です。しかし、やはり良いソフトを作るのは時間が掛かりますね。

「書けまっせ!!PDF3」は、アドビのPDF製品ではやっていない、あるいは、想定していないPDFの活用法を切り開こうというものなのですが、こういうソフトを作っていますと、PDFにはまだまだ大きな可能性があるとつくづく感じます。

先日のアドビの社長インタビューを紹介しましたが、そこでアドビのPDFは高品質と胸を張っていました。
2007年11月23日　アドビジャパン社長のインタビュー

確かに、高品質かもしれませんが、しかし、PDFを紙の代わりとして考えますと、アドビが開拓してこなかった、非常に大きな未開拓の用途があるように思います。

まずは、「書けまっせ!!PDF3」をブレークさせて、そこで、一番、新しいPDFの用途を創造し、新しい市場の開拓をしよう！と胸が弾みます。

「書けまっせ!!PDF3」が大ブレークすると良いなあ。そしたらもっとすごい製品をいろいろつくるぞ。

ソフトウエアだけではないですが、メーカでなければできないことは、新しい製品を作り、新しい用途、新しい市場を切り開くことです。やるぞお！

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月12日

PDF のアクセス権限

PDF は権限パスワード（オーナーパスワード）を設定する際に閲覧者に与える操作の許可を設定することが可能です。PDF の仕様では、このパスワードによる操作の許可が、以下のフラグセット（「User access permissions」）により決められています。

BIT POSITION	MEANING
1-2	Reserved; must be 0.
3	(Revision 2) Print the document. (Revision 3 or greater) Print the document (possibly not at the highest quality level, depending on whether bit 12 is also set).
4	Modify the contents of the document by operations other than those controlled by bits 6, 9, and 11.
5	(Revision 2) Copy or otherwise extract text and graphics from the document, including extracting text and graphics (in support of accessibility to users with disabilities or for other purposes). (Revision 3 or greater) Copy or otherwise extract text and graphics from the document by operations other than that controlled by bit 10.
6	Add or modify text annotations, fill in interactive form fields, and, if bit 4 is also set, create or modify interactive form fields (including signature fields).
7-8	Reserved; must be 1.
9	(Revision 3 or greater) Fill in existing interactive form fields (including signature fields), even if bit 6 is clear.
10	(Revision 3 or greater) Extract text and graphics (in support of accessibility to users with disabilities or for other purposes).
11	(Revision 3 or greater) Assemble the document (insert, rotate, or delete pages and create bookmarks or thumbnail images), even if bit 4 is clear.
12	(Revision 3 or greater) Print the document to a representation from which a faithful digital copy of the PDF content could be generated. When this bit is clear (and bit 3 is set), printing is limited to a low-level representation of the appearance, possibly of degraded quality. (See implementation note 25 in Appendix H.)
13-32	(Revision 3 or greater) Reserved; must be 1.

（PDF Reference, version 1.7 より抜粋）

さて、Acrobat 8 Pro で「Acrobat 5.0 およびそれ以降」のセキュリティ設定を行った場合にどのフラグがセットされるのかを実際に調べてみました。
※ 現在、「Acrobat 5.0 およびそれ以降」でセキュリティ設定を行うと、8bit の設定が可能な「Revision 3」が使用可能となります。

Acrobat 8 Pro の GUI で表示される項目				BIT POSITION
変更を許可	印刷を許可	テキスト、画像、およびその他の内容のコピーを有効にする	スクリーンリーダーデバイスのテキストアクセスを有効にする	12	11	10	9	8	7	6	5	4	3	2	1
許可しない	許可しない	-	-	0	0	0	0	1	1	0	0	0	0	0	0
許可しない	低解像度（150 dpi）	-	-	0	0	0	0	1	1	0	0	0	1	0	0
許可しない	高解像度	-	-	1	0	0	0	1	1	0	0	0	1	0	0
ページの挿入、削除、回転	許可しない	-	-	0	1	0	0	1	1	0	0	0	0	0	0
フォームフィールドの入力と既存の署名フィールドに署名	許可しない	-	-	0	0	0	1	1	1	0	0	0	0	0	0
注釈の作成、フォームフィールドの入力と既存の署名フィールドに署名	許可しない	-	-	0	0	0	1	1	1	1	0	0	0	0	0
ページの抽出を除くすべての操作	許可しない	-	-	0	0	0	1	1	1	1	0	1	0	0	0
許可しない	許可しない	ON	（自動的に ON）	0	0	1	0	1	1	0	1	0	0	0	0
許可しない	許可しない	-	ON	0	0	1	0	1	1	0	0	0	0	0	0

Antenna House PDF Driver のセキュリティ設定には、「変更を許可」に「すべての操作を許可」という項目があります。これは「印刷」の許可設定のみを行いたい場合に用意したものですが、Acrobat にはそれに対応する項目が用意されていません。そのためか、Acrobat でその設定がされた PDF を開くと「変更を許可」が「ページの抽出を除くすべての操作」となってしまいます。

投票をお願いいたします

投稿者 numata : 08:00 | コメント (0) | トラックバック

2007年12月11日

「アウトライナー2」で作る経営計画

アンテナハウスは、12月決算なので、あと少しで2007年も終わりです。とりあえず、11月までのところでは昨年を上回る成績になっていますので、なんとか後1ヶ月を頑張って、通年で好成績を残したいものです。

で、いま、2008年の経営計画の取りまとめ最終段階です。ところで、今年は、経営計画の作り方（と言いましてもドキュメントの整理法ですが）を少し変えようかと試みています。

弊社では、製品別等のグループ・リーダ制をとっていますが、各グループ・リーダから2008年の計画をもらい、それをまとめて作ります。もちろん、ボトムアップでは、人間誰でも易きに流れますので、トップダウンで目標を設定します。

今までは、オリジナル文書をWordで整理してましたが、今年は、集まった文書をPDFにして、それを「アウトライナー2」でまとめて、表紙、目次、しおりをつけて計画書にしようかと考えています。

使ってみますと、なかなか具合が良いんですね、これが。

なにしろ、弊社のリーダは、皆独自色が強いもので、文書を作るファイル形式がばらばら。これを全部Wordにするには、その編集が大変なんです。PowerPoint、Excel、テキストファイルをそれぞれ、PDF化してしまい、そのPDFを寄せ集めて、整理するのだとそんなに手間が掛かりません。

「アウトライナー」をこういう使い方をしてますと、やはり、機能的に足りないところも見つかって、ああしたい、こうしたいと思いながらやってます。PDFの新しい使い方というと大げさですが、これは楽しいですね。

来年の「アウトライナー3」にはぜひ、この経験を反映したいと思っています。お陰様でソフトを作る楽しみがまた増えました。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月10日

PDF vs Mars

昨日は、PDFとXPSの比較をご紹介しましたが、序に（といってはなんですが）、Marsの動向をチェックしておきましょう。

Mars Project

Marsについて公開されたのは、XML2006だったと思います。それから約1年経過した訳ですが、2007年11月にMars Reference 0.8が公開されています。このバージョン番号から言ってもまだ未完成です。

前回、2006年12月08日PDFのXMLフォーマットが登場！？でMarsを紹介しました。この時の仕様書は、0.7版でした。そうしますと、1年間で仕様書のバージョンが、0.1進んだことになります。

Marsは、XPSと同じくXMLベースです。アドビのMarsについてのフォーラムを読んでいますと、MarsはPDFと完全互換とし、PDFとMars間のラウンドトリップができることを目標にしているようです。

XPSは、例えばフォントについて言えば、昨日もありましたがType1フォントはサポートしていませんし、TrueTypeフォントさえもサポートしておらず、OpenTypeサポートに絞っているようです。

それに対して、PDFとMars間は、実用的に100%互換にするつもりなのでしょう。そうしますと、PDFとMarsの2つの仕様を保守していく意味があるのか？ということが当然ながら疑問になります。フォーラムでもその点質問がありますが、どうもこれに対しては、Marsは、XMLベースのワークフローへの統合というメリットを訴えています。

XMLベースになることで、データを取り出したり、新しい名前空間を使って独自のXML構造を埋め込んだりというような使い方が可能になるというのは確かにメリットを感じます。PDFにも、タグ付きPDFとか、XMPでメタデータを付けるなどの構造をいれる方法はありますけれども、やはりネイティブXMLの方がその辺は楽になると思います。

Marsの本体は、SVG1.1を独自拡張したものなので、SVGが進化していくとMarsとの関係がどうなるか、多少の疑問を感じますが、そのあたりSVG仕様の進化も遅いですから。

Dr. Macroのブログには、Marsが普及するまでに5年以上かかるとありました。

Adobe MARS: Looks Interesting (2006年12月）

もう1年経過した訳ですが、XMLベースになっているというメリットだけだと、現在のPDFを置き換えるだけのメリットとは言えません。仕様書が1年で漸く0.1バージョン・アップしたのみと言い、このペースだと、普及するのに5年じゃなく10年以上掛かる？

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月09日

PDF vs XPS

Adobe のブログを見ていましたら、PDFとXPSを比較して（PDFが良いと言っている)記事が、12月7日付けで掲載されていました。

If You Are Considering XPS, Consider This（XPSを検討しているなら、この点を考えましょう）

ここには2つのPDFがあり、それぞれ一つの観点でPDFの方が良いと言っています。
１．Print Workflows（印刷のワークフロー）
２．Electronic Approvals（電子的な承認）

まず、印刷のワークフローですが、ここはアドビが歴史的に強い、商業印刷業界の話なので、大体、予測が付くというものですが。
・XPSは、Windowsベースで、オフィスの仕事に使うなら適切かもしれないが、伝統的な商業印刷に使うには、様々な欠陥がある。
　-Type 1フォントをサポートしていない。
　-DeviceN、LABカラーをサポートしていない。
　-滑らかなシェーディング、トラッピング、オーバープリントとノックアウトなどをサポートしていない。
・典型的なMicrosoft Officeの文書でさえも、うまく印刷できないことがある。
　-Word 2007に付随するテンプレートでさえもXPSで表現できないものがある。

次に電子的な承認という点では、電子署名機能を取り上げています。PDFとXPSについて次のような比較を行っています。
・PDFは2000年から電子署名の機能があり、ユーザの利用経験により、改良されてきた。
・PDFの電子署名では、署名の外観をつけることができるので、電子署名の専門知識のないオフィス作業者でも、署名の外観から署名者、署名の妥当性などを判断できる。
・MicrosoftのXPSビューアでは適切な承認ワークフローを構築できない。
　-XPSの仕様では、署名をする場所を指定できるが、MicrosoftのXPSビューアではそれを実装していない。
　-IEに統合されたブラウザベースのXPSビューアでは、特定のページではなく、文書の周囲に署名をつける。すなわち、封筒に署名しているようなものだ。例えば、印刷したら署名されていたかどうかもわからなくなる。
　-その上、MicrosoftはXPSビューアを2種類提供しているが、それぞれで署名の取り扱いが違う。
　IEに統合するタイプのものでは、文書に署名することと検証とができる。一方、スタンドアロンで走るXPSビューアEPは、署名情報を全く表示できない。IEを使っていないユーザは、XPS ビューアEPを使用せざるを得ないのだが。

10年以上の歴史のあるPDFと、1年生のXPSを比較してみれば、それは、いろいろな欠点を上げることができるでしょうね。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月08日

ISOにてDIS 32000(PDF1.7)投票で残念なこと

一昨日、ISOでのPDF仕様の投票結果は、賛成多数で通過ということをお話しました。

2007年12月06日　PDF仕様　ISO投票を通過

これで一つ残念なことがありました。
それは、コメント付きの賛成投票国として、英国、米国、ドイツ、スイスが、それぞれ、コメントを、13、125、11、19件付けていたということです。フランスは37件のコメント付きで反対です。

ところが日本は、コメントなしの賛成になっていました。

米国、英国などのコメントは、仕様書に対する、誤りや意見を述べたものと思います。ISO DIS 32000の仕様書は、PDF Reference1.7を元にして、大急ぎで作成されたもので、私もざっと見ましたが、多少疑問点や直す方が良いと感じるところがありました。決して、完成された仕様とは言えない状態なんですね。

米国では、大勢の参加者で、この仕様に対してコメントをつけています。

一部はここに公開もされています。
http://pdf.editme.com/PDFREF

要するにコメントの数は、(フランスはどうか分かりませんが）、関係者のPDFに対する熱の高さ、温度の高さを示していると言えます。

この数字から判断しますと、PDFに熱心な順から、米国＞スイス＞英国＞ドイツ　ということでしょうか。
フランスも反対意見も多いにせよ、熱心といえます。

それに対して、日本は、先進国のなかで一番PDFに冷淡？

そんなことを考えますと、日本からももっとコメントを出すべきでした。私なども気が付いたことがあったにも関わらず、なにもコメントを出せなかったのが残念です。いまさら言っても仕方ありませんが。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年12月07日

「リッチテキストPDF4」を発売

アンテナハウスは、12月下旬から、PDF変換ソフトの最新版「リッチテキストPDF4」を販売開始します。

今回のバージョンの主な機能強化項目は次の通りです。
１．PDFからWord、PDFからExcelへの変換精度を、さらに向上させました。
２．OCR機能を使って書式や文字を認識する機能を付加して、従来変換できなかった文字コードのないPDFの変換を可能としました。（OCR機能搭載は最上位版「コンプリート」のみ。）
３．ファミリを「ライト」、「スタンダード」、「コンプリート」の3製品とし、お客様のニーズに応じて選択の幅が広くなりました。
４．GUIをより簡単にして、操作をより分かりやすくしました。また、WordとExcel用のPDFを読み込むアドインを開発し、WordやExcelからPDFを直接開くことができるようにしました。

詳細につきましては、次をご参照ください。
(1)製品のご紹介ページ：http://www.antenna.co.jp/rpd/
(2)「リッチテキストPDF4」発売のお知らせ：http://www.antenna.co.jp/news/pdf40news.html

リッチテキストPDFの最大の特徴は、PDFからWordやExcelに変換するときの変換の質の高さにあります。

変換の質とは、(1)PDFのページレイアウトをWordまたはExcel文書として再現すること、(2)そしてそれと同時に、再編集しやすい文書を作ることにあります。

この(1)と(2)の要件を両方とも満たすことが重要です。レイアウトを再現するだけであれば、Wordのテキストボックス機能を使いまくって文書を作れば比較的簡単にレイアウトの再現ができます。しかし、そのようなWord文書は、文字や文章を修正するのは大変難しくなります。文字や文章を再編集するだけであれば、テキストにするのが一番簡単です。

このあたりが難しいところですが、そこは、弊社は文書変換ソフトを20年も作っている会社ですので、変換については、日本一ではないかと思っています。しかし、他社も進歩しているでしょうから、「リッチテキストPDF4」と他社の最新製品を、また、無慈悲に比較してみようと思っています。

また、日本一で井の中の蛙にならないよう、世界の市場に行って戦ってみようと考えています。今は、一部の機能だけを英語版として出していますが、今回の「リッチテキストPDF4」で初めて、フル機能の英語版を作成する予定です。世界の市場で、勝ち残る製品を出すことで、日本のお客様にもより良い製品をお届けできるものと考えています。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年12月06日

PDF仕様　ISO投票を通過

PDF 1.7をベースとするISO標準仕様案 DIS 32000に対する投票は、13対1で無事通過したようです。

○コメントなしの賛成国：オーストラリア、ブルガリア、中国、日本、ポーランド、南アフリカ、スペイン、スウェーデン、ウクライナの9カ国。
○コメント付きの賛成国：英国、米国、ドイツ、スイス
○反対国：フランス
○保留：ロシア

総投票数14国のうち、13国（93%）がポジティブ、1国がネガティブ。

コメント総数は205件あり、2008年の1月21日から23日の会議にコメントへの対応が報告されます。

全員が満足すれば、その時点で、PDF標準はISO仕様となります。もし、事態が紛糾すれば、2ヶ月のFDIS投票となるようです。

いずれにせよ、PDFの仕様が、ISOの標準として出版される時期が確実に近づいてきています。

我々サードパーティにとっても、来年には、私達の製品は、もはやクローンではなく、ISO標準を実装した製品と主張することができるようになり、大変に喜ばしいことです。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月05日

XHTML+CSSでPDF

O'ReillyのXML.COMブログにKurt Cagle 氏が「Cheers for the Prince」という記事を書いています。

Princeは、CSSで印刷品質のページを組版しようというソフトウェアです。あまり大したことはないだろうという先入観をもっていたようですが、使ってみて大変気に入ったと言っています。

Kurt Cagle 氏は構造化文書を書くためにDocBookを使っているようです。DocBookをXSL-FOに変換するオープン・ソースのスタイルシートはあります。これを使えば、DocBookをFOに変換してPDF化するのは簡単です。

しかし、この方法は、書籍などをきちんと作るには良いが、簡単なその場限りの文章などを印刷するには、ちょっと重過ぎるとのことです。

このため簡単な文書を印刷するのにCSSを使う方法を試してみたところ、結構気に入ったようです。

DITAのメーリング・リストにも、DITAからCSS用のTOC（目次）と索引を作るスタイルシートを誰か作ったら、PrinceでDITAを組版できるのではないかという投稿がでてきました。

Prince礼賛論の行方に注目です。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月04日

PDFと長期署名(17) — PDF独自の長期署名仕様をどうするか？

「PDF千夜一夜」では、過去16回にわたって、PDFと長期署名について考えてきました。

現在、長期署名については、ECOMで実証実験が進んでおり、2007年度も多数の企業が参加して相互運用実験を行っています。

「長期署名フォーマット相互運用テストプロジェクト」

アンテナハウスは参加していませんが、関連会社のラング・エッジがXAdESに積極的に取り組んでおり、実証実験にも参加してます。この実証実験は、なかなか大変なようですが、有意義なものだと思います。

さて、PDFに長期署名を施すことはできますが、その結果は、PDFファイルにはできません。現在の時点で長期署名を施した結果をPDFとして保存できる仕様はないからです。

この仕様について、日本独自のPDF長期署名仕様を長期署名JISの中に盛り込むという動きがあり、この案が当初のECOMの長期仕様に関するJISへの提案に盛り込まれていました。しかし、その後、これについては大きな問題があるということが分かりました。現在、下記に掲載されている10月17日付けの最新案からは削除されたようです。

http://www.ecom.jp/LongTermStorage/esprofile.html

さて、そうなりますと、PDFの長期署名仕様をどうするか、ということが改めて大きな検討課題となります。

これについて、私は、現在の時点では、次のように考えています。

まず、日本独自のPDF仕様を考えるのは、止めるほうが良いと思います。一番大きな理由は、いまのソフトウエア業界では、日本独自の仕様というものは、全く通用しなくなっているのではないかということです。日本独自に関わらず、独自仕様というものが難しくなっているとも思います。

結論を急ぎ過ぎかもしれませんが、独自仕様は、結局、コスト的に非常に大きなものになります。米国や中国のような大きな市場であれば、なんとかなるかも知れませんが、日本のような中途半端な規模の市場で、独自仕様を考えたら、海外勢にコスト的に全く太刀打ちできなくなってしまいます。短期的には成功しそうにみえても、長期的には必ず駆逐されてしまうのではないでしょうか。

そうなりますと、もし、仕様を作るなら相当に大きな視野でものを考えて、世界をリードできなければならないと思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月03日

石の上にも三年

「石の上にも三年」という諺があります。

「冷たい石も三年座り続ければ、暖かくなる」という意味から、「どんなに苦しくても大変でも、じっと辛抱すれば必ず報われる。」という風に使われるようです。

「千夜一夜」の1000日というのも大体3年に相当します。もしかして、「アラビアンナイト」も石の上にも三年派？

ところで、アンテナハウスは12月決算なので、あと1ヶ月で2007年の成績が決まります。今年を振り返ってみますと、「サーバベース・コンバータ」など2004年に開発を始め、2005年に発売した製品が2007年の今年になって、だいぶ売上が増えてきました。ようやく製品・ビジネスとして成立する見通しが付いたと言ってもよさそうです。

昔からビジネスは3年位で目処をつけると言われていました。1年目、2年目は投資期間、3年目で収支均衡させ、4年目から利益を出す。5年位で累積黒字とする、というようなビジネスプランを立てたら良い、という意味です。そうしてみますと、インターネット時代になって、情報の流通速度が飛躍的に速くなって、世の中の動きが早くなったように見える今日でも、やはり3年がひとつの区切りになるという状況は変わっていないのでしょうか？

「アンテナハウスPDF」は、2005年8月自社ブランドPDF製品として参入しました。大体2年強を経過したところです。丁度3年目のこれから1年間が勝負どころになりそうです。

今月、12月に「リッチテキストPDF4」、「書けまっせ!!PDF3」を発表する予定ですが、今度のバージョンで、ひと勝負！

今度の「書けまっせ!!PDF3」はお勧めです！10万本もいけそう！！いやいや、英語版も出しますから、これで100万本いきましょう！！初夢はきっと100万本売って50億円。来年が楽しみです。（この部分は、ホラです。お間違えのないよう。）

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月02日

XML Conference 2007 など

いよいよ、明日から米国ボストンでXML Conference 2007が始まります。

弊社は、2001年12月にフロリダ・オーランドで開催されたXML Conference 2001に初出展してから、今年で7回連続出展しています。

いままでは、１コマだけの出展社でしたが、今年は、ゴールド・スポンサーになりました。
XML Conferenceの、通常の出展料は、5000ドルですが、ゴールド・スポンサーは、1万ドルということで2倍の値段になります。

ケチを自認する私としては大変な決断です。でも、XML Conferenceは、XML専門の会議としてそれだけの営業的な効果はあると思います。

XML Conferenceを含め、今年は、かなり積極的に欧米の展示会に参加しましたが、XML関係の売上効果面では全体としてそれなりの効果はあったと思います。

欧米のXMLの展示会は、的が絞れていますので、XSL Formatterのような専門的なツールの販売促進には最適な手段と思います。それに対して、日本の場合、展示会の主催者は参加者を増やすことに熱心で、会議での発表の質を高めることにあまり熱心でないように思います。発表内容の質が高ければ、参加者のレベルが上がりますし、そうすると、結局、販売促進効果もあるように思います。

PDFは、その点どうなんでしょうか？
来年は、欧米でRainbowPDFブランドを推進するためPDF関係にも出展を拡大する予定です。

現在のところ、4月までにthe ALA (American Library Association), FOSE (連邦政府向け), AIIM (ドキュメントとイメージ管理)の3つの展示会に参加する予定です。

欧米でRainbowPDFブランドを確立して、日本に逆輸入できるようにしたい！

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月01日

PDF出力時の改ページ位置のずれ

Antenna House PDF Driverを使って、PDFを作成するシステムを作っているお客様から、ExcelのファイルをPDF化すると、改ページ位置がずれてしまうが何とかならないかという問合せが来ました。

確かに、Excelファイルをプレビューしたとき、手元のプリンタ（私が普段使っているのはCanonのMP500というパーソナルなプリンタです）と、PDF DriverでPDFに出したときで改ページの位置が1ページあたり1行ずつずれてしまいます。社内の他のプリンタでも、PDFと改ページ位置がずれるようです。

調べてみますと、Antenna House PDF Driverの代わりにAdobe PDF (8.1)のドライバを使っても全く同じようになり、実際のプリンタで出すのと比べて、PDFでは1ページあたり1行ずつ改行位置がずれていきます。

お客様は、この問題にかなり困っているようですので、弊社の担当者もいろいろと調べていました。
Adobeのサポートにも、同じような問題の報告が寄せられているらしく、次のような情報があります。

○Excel から PDF ファイルを作成する際の推奨事項（Windows 版 Acrobat 6.0/7.0）
http://support.adobe.co.jp/faq/qadoc/AJ25.nsf/0/2fedaa08c10ea9a449256d420049b1d7?OpenDocument

このページには、次のような注意事項が書かれています。
----------------------
Excel ではページ設定および使用可能なフォントを「通常使うプリンタ」のプリンタドライバ用に適用するため、「通常使うプリンタ」を変更することによって文書のフォーマットが変更されてしまう場合があります。Excel 文書が別のユーザによって、または別のコンピュータ上で作成される場合は、Adobe PDF プリンタを「通常使うプリンタ」に設定してから文書を作成するように、文書の作成者に依頼してください。
----------------------

これについては、マイクロソフトのWebページに、さらに、詳しい解説があります。

○http://support.microsoft.com/kb/400271/ja
　[XL2002] 異なる環境で印刷範囲やセルの幅や高さが変わる場合の対策

○http://support.microsoft.com/kb/881233/ja
　別のコンピュータでファイルを開くと画面表示や印刷結果が異なる場合の注意事項

要するに、Excelの場合、文書を表示・印刷するときのページのレイアウトの計算を高速に行うために、セル幅やセルの高さ、文字の大きさの計算を簡略化しているため、ページのレイアウト結果が、環境（ディスプレイやプリンタ・ドライバ）に依存するようになっているようです。

このため、プリンタ・ドライバを変更するとページのレイアウトが変わってしまうことが往々にしてあるようです。

どうも、各社のPDFドライバは同じようにPDF作成時の改ページ位置が、物理的なプリンタ装置の場合と違う傾向があるようです。物理的なプリンタ装置では、完全に紙の縁まで印刷することはなく、周囲に印刷できない領域がありますが、PDFドライバは論理的に計算するものですので、装置の特性で印刷できない領域がないということが、影響しているのかもしれません。

原因は、何にせよ、Excelの場合は、改ページの位置が変わる傾向がありますので、文書を作るときに、印刷に使用するPDFドライバを、「通常使うプリンタ」に設定するように注意しないといけないと思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック