« 2008年02月 | メイン | 2008年04月 »
2008年03月31日
OpenOffice.orgでIPAフォント設定時の縦書き用グリフ問題
昨日、ご紹介しました「ドキュン」は、PDF作成に、OpenOffice.orgを使っているようです。このPDF作成とプレビュー機能について、docuneへの要望というカテゴリーに「縦書き文書のプレビューの改善要望」という文書が公開されています。
■縦書き文書のプレビューの改善要望
http://docune.jp/doc/3353
この文書中では、『IPA明朝を指定した文書のプレビューで縦書きの句読点のグリフが正しくない、その原因はIPAフォントの不具合である。』と指摘されています。この点をもう少し詳しく検討してみたいと思います。
日本語のフォントの中で、句読点や括弧類は横書きと縦書き表示される字形（グリフ）が異なります。この中で、括弧類などでは、横書き用のグリフを時計周りに90度回転することで縦書き用のグリフにすることができます。しかし、句点、読点などは横書き用グリフを90度回転しても縦書き用のグリフになりません。従って、横書き用と縦書き用のグリフの2種類をフォントの中で用意しておく必要があります。表示または印刷では、横書きか縦書きかで、2種類のグリフを切り替える必要があります。
縦書き時に、句読点のグリフが正しくない場合、その原因には、「フォントの不具合」、「アプリケーションの表示・印刷の不具合」の両方の可能性があります。どちらの原因かを特定するには、フォントとプログラムの両方を精査してみなければなりません。自分でソフトを開発しているならともかく、部外者にはこれを特定するのはなかなか難しいと思います。いくらOpenOffice.orgがオープンソースであると言っても、この内部を精査する時間と能力のある人は、そんなに大勢はいないでしょう。
と言うわけで、以下の話も推測に過ぎませんが。
○OpenOffice.orgで、IPAフォントの括弧や句読点が縦書でどう扱われているか
原文：OpenOffice.org Writerのファイルをダウンロード
印刷：上の文書をプリンタに印刷した結果（スキャナで取り込み）
PDF-1：PDF-1ファイルをダウンロード（OpenOffice.orgでPDF化した結果）
PDF-2：PDF-2ファイルをダウンロード（AdobePDFでPDF化した結果）
この結果を比較すると、次のことが言えるでしょう。
(1)プリンタへの印刷結果では、句読点は縦書きのグリフになっている。
(2)OpenOffice.org自体の機能でPDFを作ると、句読点は横書きのグリフになっている。
(3)OpenOffice.orgからAdobePDFでPDFを作ると、句読点は縦書きのグリフになっている。
※上記は、OpenOffice.org Writer 2.0、WindowsXP（英語版）、AdobePDF（ドライバ） 8.1、印刷はCanon MP500を使っています。
「OpenOffice.org で縦書きを設定した文書をプリンタへ印刷、または、AdobePDFによるPDF化では、句読点は縦書きグリフとなっていることから、IPAフォントには句読点の縦書き用グリフが含まれている。」らしいことは推測できます。
しかし、OpenOffice.orgが内蔵するPDF生成機能を使ってPDFを出力したときは、句読点が横書き用グリフのままになっています。このことから、私は、むしろ、OpeｎOffice.orgのPDF作成機能に問題があるのではないだろうかと思います。この横書きと縦書きでのグリフ置換は、もしかするとWindowsが行っているのかもしれないですが、そうだとしますと、LinuxやSolarisでは、印刷結果なども変わってくるのでしょうね。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月30日
PDFをFlashに変換してパブリッシュするWebサービス(メモ)２
日本でもPDFなどの情報を投稿して共有するサイトができていました。やはり、プレビュー表示はFlashを使っているようです。
オーケー・ウエーブが提供している「ドキュン」です。2007年7月開始です。
http://docune.jp/
投稿したPDFの表示はFlashを使っているようです。昨日、ご紹介しました、issuuの場合は、プロが制作した雑誌などの公開を目標にしているようですが、「ドキュン」の方は、一般のユーザが作成したコンテンツを対象にしているようです。
その代わり、PDFだけではなく、テキスト形式、Word(doc）、Excel形式（.xls）、PowerPoint形式（.ppt）、OpenOfficeのWriter形式（.odt）、Calc形式（.ods）、Impress形式（.odp）、Draw形式（.odg）、JPEG形式（.jpg, .jpeg）、PNG形式（.png）、リッチテキスト形式（.rtf）を投稿できます。
PDF以外のファイルをアップしたときの、サーバサイドのPDF変換は、OpenOffice.orgを使っているようです。Word文書をアップすると、フォントが別のフォントに置き換わったりしてしまいます。
このあたりは、apolabさんが「縦書き文書のプレビューの改善要望」としてあげています。
Webページは、全体として、分かりやすく、使いやすいインターフェイスになっていると思います。但し、ブログページなどナビゲーションの仕方が良く分からない箇所があります。
やはり、Webで情報を共有したり、パブリッシュするには、PDFよりFlashの方が良いのかな？と。
あまり関係ないですが、それにしてもSVGはどこへ行ってしまったんでしょうか。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月29日
PDFをFlashに変換してパブリッシュするWebサービス(メモ)
Flashを使ってPDFをパブリッシュするissuuサービスについてちょっと調べてみました。
■http://issuu.com/ （ベータ版）
このWebページは、U-tubeのFlash版だと思いますが、公共のライブラリーと称しています。出版物をFlashに変換して、公開するサービスをやっているようです。
自分のプロファイルを登録し、出版したい資料もアップロードできます。日本語のPDFをFlashに変換することもできます。
○ページをナビゲートする画面
雑誌のページだと、ファイルをダウンロードするのに少し時間がかかるようで、それが難点といえば難点。
○ページを拡大して表示する画面
公式ブログがあります。
昨年の6月から限定のβテストが始まっています。
昨年12月に公開のβテストで、誰でも使える（PDFをアップロードできる）ようになったとあります。
現在もβ版。
2月にSXSW Web Awardsのファイナリストに選ばれたようです。
まだ、公式のサービスが始まっていませんので、ビジネス・モデルが分かりませんが、なかなか面白いく、1見の価値があるWebページです。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月28日
XSL-FO 2.0 の要求項目 第2版 公開
W3CのXSL FO作業グループは、XSL-FO 2.0の要求項目の第2版を26日（日本時間27日）に公開しました。
Extensible Stylesheet Language (XSL) Requirements Version 2.0
W3C Working Draft 26 March 2008
XSL-FO2.0については、現在、どのような機能を拡張すべきかについてのアンケートも行われています。
Information needed to answer XSL 2.0 Requirements Survey （2008年9月30日まで）
なお、日本語組版については、W3Cのタスクフォースとして日本語組版についての要求をまとめる作業が行われています。これもそろそろ、取りまとめられる予定です。
ちなみに、上記の要求項目第2版の
6 Further improved non-Western language support
の部分を見ますと、
---ここから---
Specifically, the Japanese Layout Taskforce is creating a document about requirements for general Japanese layout realized with technologies like CSS, SVG and XSL-FO. The document is currently in draft stage and is being developed further by the Japanese participants in the task force. This document will be an input to the XSL working group as a source of requirements.
---ここまで---
となっていて、日本語組版に関するタスクフォースがまとめた資料は、XSL-FO 2.0 の要求項目への情報源として使用される予定になっています。
XSL-FO 2.0が、日本語組版に関する規定が盛り込まれた形で完成するのは、少なくとも後、数年は掛かることが予想されます。少しずつではありますが、Webで綺麗な日本語組版ができる時代に向かって進んでいることは確かです。
○日本語組版のタスクフォースについて
Japanese Layout Taskforce
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月27日
アンテナハウスPDF Tool V2.6 Windows, Solaris, Linux出揃いました
26日より、アンテナハウスPDF Tool V2.6Solaris版をリリースしました。
PDF Tool V2.6のWindows版は、既に、昨年5月に初版をリリースしていましたので、Solaris版は、10ヶ月遅れとなります。Linux版は、先月（2月）にリリースしていますので、漸く、V2.6でWindows、Solaris、Linuxの3種類が揃ったことになります。
PDF Toolは、PDF Driver APIとPDF Driver、PDF Tool APIから構成しています。
○PDF Driver＋PDF Driver APIは、サーバサイドでアプリケーションからPDFを作成する機能を実現できます。但し、Windows版のみ提供となっています。
○PDF Tool APIは、PDFの分割・結合、セキュリティ設定、すかし設定、しおり・リンク・注釈などの設定機能を提供しています。
次の表にOS別の提供機能を比較しました。
| PDF 作成 (PDF Driver APIとPDF Driver) | PDFの加工 (PDF Tool API) | |
|---|---|---|
| Windows | ○ | ○ |
| Solaris | × | ○ |
| Linux | × | ○ |
このため、Solaris、Linuxでは、PDFを作成することができませんのでご注意ください。
(1)詳しい情報がこちらでご覧ください。
http://www.antenna.co.jp/ptl/index.htm
(2)評価版のダウンロードも用意いたしました。お申し込みはこちらからどうぞ。
http://www.antenna.co.jp/ptl/download.htm
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月26日
PDFによる情報保存の法的な有効性 (1)
先日、国土交通省の電子納品でのPDFの扱いに少し触れました。
2008年03月23日PDFのフォント埋め込み — 電子納品PDFでフォントを埋め込まないのはなぜ？
簡単に整理しますと、
１．「土木設計業務等の電子納品要領(案)」では、平成16年版には既にPDFによる電子納品をかなり幅広く認めているようだ。
２．「工事完成図書の電子納品要領(案)」では、平成20年版で、PDFによる電子納品を認めることになっている。
電子納品に関する要領・基準はこちらに一覧表があります。
・国土交通省：CALS/EC電子納品に関する要領・基準
このページに掲載されている他の基準についても調べてみました。
A．一般・土木分野（続き）
３．CAD製図基準(案) H16.6 特にPDFには触れていない。
４．デジタル写真管理情報基準(案) H18.1 特にPDFには触れていない。
５．測量成果電子納品要領(案) 国土地理院 H16.6 かなり広範にPDFを認めている。
http://psgsv.gsi.go.jp/koukyou/download/denshinouhin/pdf/youryouv2.1.pdf
６．地質・土質調査成果電子納品要領(案) H16.6 電子柱状図など、PDFを標準としている。
B．電気
１．工事完成図書の電子納品要領（案） 電気通信設備編 H16.6 特にPDFには触れていない。
２．土木設計業務等の電子納品要領（案） 電気通信設備編 H16.6 土木設計と同じく、広範にPDFを認めている。
３．CAD製図基準（案） 電気通信設備編 H16.6 特にPDFには触れていない。
C．機械
１．工事完成図書の電子納品要領（案） 機械設備工事編 H18.3 かなり広範にPDFを認めている。
２・ 土木設計業務等の電子納品要領（案） 機械設備工事編 H18.3 かなり広範にPDFを認めている。
３． CAD製図基準（案） 機械設備工事編 H18.3 特にPDFには触れていない。
４． 電子納品要領（案） 機械設備工事編 施設機器コードH18.3 特にPDFには触れていない。
以上のように、基準によって、PDFを標準にしたり、オリジナルとPDFを認めたり、認めなかったりとかなり温度差があるようです。
なお、国土交通省の電子納品の基準をベースにして、都道府県などの地方自治体でも同様な基準を定めていて、PDFによる工事図書の納品はかなり幅広く実務的に採用されているようです。
なぜ、このようなことが気になったかと言いますと、実は、次のような例があるからです。
■財団法人 建築行政情報センターのWebページで、「改正建築基準法に係る質疑・応答」というQ&Aがあります。
確認・検査・適合性判定の運用等に関する質疑
http://www.icba.or.jp/kaisei/doc/Q&A.pdf
（最終更新日 平成１９年１２月 ３０日）
この中に、次のような質問があります。
Q108 建築士設計事務所において保存すべき設計図書を、ＰＤＦファイルで保存することは可能でしょうか？
回答は次のようになっています。
原本性を担保するという観点から、ＰＤＦファイルについては、以下の２通りが想定されます。
①ＣＡＤによって作成された設計図書（電子データ）をＰＤＦ印刷した場合、当該ＰＤＦファイルによる保存は認められません。
②紙面に打ち出された設計図書をスキャンした場合、当該ＰＤＦファイルによる保存は可能です。なお、マイクロフィルムによる保存は従来より認められているところです。
この質疑応答は、あまりにも短くて趣旨がはっきり分かりません。CADはだめだが、他のアプリケーションなら良いのかどうか？あるいは、ボーン・デジタルなPDFは全部だめなのかどうか？
こういうものを見ますと、どうも、PDFファイルが電子データの保存形式としてどの程度認められているのか、もう詳しく調べてみる必要がありそうです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月25日
透明の扱いについて(メモ)
先日、「萩さん日記」という、とても興味深いブログを見つけました。
http://hagi-san.blog.ocn.ne.jp/hagisan/
XPSにかなり期待しているようです。
どこの方かは存知上げませんが、プロフィールを拝見しますと、「プリンタ、ページ記述言語 (PDL)、電子ドキュメント関連製品の開発や RIP コア技術の開発を 30 年以上」とありますので、中々、すごいキャリアです。尊敬します。もう、1年以上前から書かれていたようで、もっと早く知っていれば良かったのですが。
最新の記事は、「透過レイヤーを含む PDF 生成における問題」という内容です。
概ね、ここに書かれている通りと思いますが、アプリケーションを開発している立場からちょっとコメントさせていただきます。
透過は、GDIプリント・パスではサポートできないというのは正しいと思いますが、じゃあ、「WPF対応のアプリケーションを開発し、透過をサポートするXPSを生成。。。XPSをPDFに変換」とは、たぶん思わないのじゃないでしょうか。
GDIには、透明を表示するAPIがありますので、画面上に透過を表示することができます。また、GDIPlusは透過をサポートするPNGも表示できます。ですので、透明をWindowsGDI画面に表示するのは比較的簡単にできます。
そうしますと、あとは、PDF出力なのですが、PDFを直接生成すれば、透過をサポートするのはそんなに大変ではありません。
例えば、「書けまっせ!!PDF」では、透明度を設定したPNGを画面に表示することもできますし、PDFに出すこともできます。（でも、GDIプリンタにはちゃんと出せないようです。これは、プリンタ・メーカの責任？）
◎透明を設定したPNGと透明を設定しないPNGを画面に表示した例（「書けまっせ!!PDF3」）
◎上のファイルをPDFに出して、Adobe Readerで表示
※PDFファイルをダウンロード
私などは、むしろ、WPFをサポートするアプリケーションを開発する方が大変じゃないかと思います。それに、WPFをサポートすることで、GDIのみのWindowsでは動かないというのは困りますので、GDIとWPFを両方サポートしなければならなくなって、2重の開発投資が必要になります。新しいアーキテクチャに直ぐには乗り換えることができない、ということなのですが。
こんなことを言っていますと、自分が年を取っているなと感じるのではありますが。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月24日
PDFのISO 32000は決着済み
重要なニュースを見落としていました。
AIIMのStandards Watch(3月11日）によりますと、1月のISOの会議で、国際ワーキング・グループは反対コメントを解決することができて、反対投票が賛成に変更になり、標準は完全に承認されて、出版に回ったとのこと。
PDF Reference as Standard
http://aiimstandardswatch.typepad.com/aiim_standards_watch/2008/03/pdf-reference-a.html
なお、ISOのWebページを見ますと、開発中で、40.99Stageになっています。（完全に承認されて、FDISに登録されるために回覧中。FDIS段階で承認されると出版。）
ところで、既に、ISO 32000の次のバージョンへのリクエストが集まっているようです。米国の委員会では既に、次のバージョンへのアイデアを意見交換中だそうで、リストがあります。
中に、MathMLなんてのがあります。これは、ちょっと違うんじゃないでしょうかね。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月23日
PDFのフォント埋め込み — 電子納品PDFでフォントを埋め込まないのはなぜ？
お客さんから、弊社の「アウトライナーを電子納品のPDFを作成するのに重宝している」というご連絡と幾つか、ご要望をいただきました。
昔、電子納品が始まる頃に、電子納品の仕様についていろいろ調べたことがありました。昔は、オリジナルのワープロ文書などを、そのまま納品するような仕様になっていた記憶があります。電子納品は、最初の頃は国土交通省の大型工事を対象でしたが、だんだん、地方自治体まで広がって、いまではかなり一般的になってきたようです。
それで、いつの間にか、報告書をPDFで納品するようになったようです。「土木設計業務等の電子納品要領(案) 平成16年6月国土交通省」を見ますと、
４．ファイル形式 (p.12)
・報告書ファイルのファイル形式はPDF 形式とする。
となっています。
でも、国土交通省のパブリック・コメント募集：
「土木設計業務等の電子納品要領(案)」、「工事完成図書の電子納品要領(案)」及び「デジタル写真管理情報基準(案)」の改定に関する意見募集について
の資料を見ますと、
「工事設計業務の電子納品」においては、PDF形式での納品が標準的になっているようですが、「工事完成図書」の方は、平成20年改訂案版でもPDFが標準になっていなくて、「受発注者協議により、オリジナルファイルから変換したPDF ファイルも納品可とする。」（p.25）になっています。
◎設計業務ではPDFが標準なのに、完成図書はPDFが標準じゃないのはなぜなんでしょうね？
ところで、「土木設計業務等の電子納品要領(案)＜改定素案＞」（平成20年3月国土交通省）の「5 報告書ファイルの作成」にPDF作成の注意事項があります。
---ここから---
• 用紙サイズは、A4 縦を基本とする。
• 印刷を前提とした解像度、圧縮の設定を行う。
• 不要なフォントの埋め込みは行わない。また、特殊なフォントは用いない。
---ここまで---
とあります。
◎このフォント埋め込みを非推奨にしている理由は理解できません。作成者と同じフォントが、受領者の環境にない場合、フォントが埋め込まれてないと文字化けする可能性があります。
例えば、ISOのPDF/Aの仕様でも長期保存用のPDFは、フォント埋め込みを必須としています。
異なる組織間でPDFを受け渡す際は、フォント埋め込みを標準とするべきだと思います。逆に、フォント埋め込みをしないことを推奨するには、PDFの作成・表示環境が時間と空間を越えて不変であるということが前提が必要です。しかし、この前提が簡単には保証されないことは少し考えれば分かると思います。
残念ながら、パブリック・コメントは、3月19日で終了してしまっていました。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月22日
普通のやつらの上を行け (Paul Graham)
先日、Paul Graham氏の「もうひとつの未来への道」をご紹介しましたが、続いて、「普通のやつらの上を行け」をご紹介します。
原文：Beating the Averages
http://practical-scheme.net/trans/beating-the-averages-j.html
これは要するにプログラム言語Lispが如何に優れているかという話ですが、概略を紹介します。
１．ソフトウェア・ビジネスは競争がとりわけ激しい。ある会社が他の会社よりも良いソフトウェアを早く書いたら、他の会社がいずれ潰れる。（他の条件が同じとして）。だから間違った技術を選択したら致命傷になる。
２．C++やPerlを大勢の人が知っていることは、その言語を選択する理由にならない。
３．デスクトップのソフトウエアを書くときは、OSがサポートする言語を選択するのが良い。しかし、Webベースのアプリケーションならどんな言語でも選択できる。
４．ViawebはLisp言語を選択したが、Lispはソフトウェアを素早く書くのに向いている。競争相手は20～30社に及んだが、CGIスクリプトを使っていた。Viawebは機能的には競争相手の遥か先へ行っていたし、競争相手が新しい機能を付けても1日2日で追いつくことができた。これはLispで誰よりも早くソフトウェアを開発できたからだ。
５．Lispは今ある言語の中で、最もパワフルだ。では、Lispがそんなに良いなら、なぜ、誰も使わないのか？
６．プログラム言語はその力において差がある。全ての言語は、機械語から最も力のある言語までの連続したスペクトル線の上にある。一般的にはアプリケーションを書くなら手に入る最も力の強い言語を使うべきだ。
７．ある年齢に達すると、プログラマは自分から言語を変えることはほとんどなくなる。何を使っていてもこれで十分だと思ってしまう。スペクトル線で自分が使っている言語位置の下を見下すことができても、上を理解できないからだ。
８．Lispがもっとも上位に来る理由は、マクロ機能である。Lispのコードはパーサで読むとデータ構造になる。他の言語ではコンパイラが生成する構文木をLispでは直接プログラムとして書く。この構文木を操作するプログラム、いわばプログラムを生成するプログラムがマクロだ。Viawebエディタの20-25%はマクロであり、ライバルのソフトウェアではできないものすごく難しいことをやっていた。これで、ライバルのソフトウェアにはできないことができたのだ。
９．プログラミング言語の変化は遅い。その理由はプログラマがそれを道具として思考するものだから。半分技術だけれども半分は宗教だ。
１０．1960年代にLispによって導入されたガベージコレクションは、近年ようやく良い技術として認められるようになった。しかし、1960年代にLispが導入したマクロはまだ未知の世界だ。
---ここまで---
著者がLispのハッカーであることを割り引くにしても、一考を要する文章ではありますね。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月21日
電子署名法の見直し 委員会の検討結果
「電子署名及び認証業務に関する法律の施行状況に係る検討会」報告書（案）では、概ね、次のようなことを検討して、提案として、纏めています。
１．電子署名に用いる暗号技術の安全性について（技術的側面）
提案骨子「ハッシュ関数SHA-1、暗号アルゴリズムRSA1024bitの安全性については、比較的短期間に、危殆化の恐れがある。2008年度早期に、特定認証業務に係る電子署名の基準にSHA-2を追加し、2014年までにRSA2048bitを活性化。概ね2014年頃に、電子署名法施行規則及び告示から、SHA-1とRSA1024bitを削除するのが良い。」
２．電子証明書の発行に際して、利用申込者の真偽を確認する方法を多様化することについて（制度面）
全国社会保険労務士会連合会、日本税理士会連合会、日本司法書士会連合会及び日本土地家屋調査士会連合会（「士業４団体」）の加入者名簿を本人確認に使えるようにすべきだ。
３．普及促進策について（ビジネス面）
主務省においては、関係者とも協力して普及促進策を実施・検討するべきとして、幾つかの例を挙げています。
（報告書pp.23～24）
４．その他の課題
（１）法人名や役職名等を対象とする電子証明書の発行に関して、電子署名法に基づく認定を受けることができないか？
これについては、「電子署名について、 手書き署名・押印と同等の法的取扱いを定める電子署名法においては、認定の対象は自然人を電子証明書の発行対象とする特定認証業務とするのが妥当である。」としています。
（２）認定認証業務の電子証明書に記載する氏名・住所・生年月日以外の属性についての証明を認定対象とできないか？
「認定認証業務が属性の確認に用いている情報が属性を証明する権能を持った者から正確に提供されていることが確認されれば、認定認証業務による電子証明書に記載された属性情報に関する事実上の推定が働くと期待される。」として、現状を変更することはしない。
これは、例えば、会社の代表者であることを、電子証明書に記載する際、それを、認定事業者が証明できるようにしたいという要望があり、それを否定しているようですが、私には、属性を証明する機能をもつ、という意味が良くわかりません。
（３）電子文書を長期保存する場合の電子署名の利用を想定し、電子署名の長期検証性の確保について規定を置くべきではないか？
「電子署名をどのように利用するかについては、市場の活動を制限しないという観点からも特に規定しておらず、電子文書の長期保存に利用する場合の措置に関する規定を置くことも考えにくい。」としています。
（４）認証業務の認定制度に、複数の認定レベルを設けることはできないか？
「認定制度に、複数のレベルを設けることは不適当である」
（５）利用者がどのようなレベルの管理を行えば電子署名法第３条における「適正」な管理と考えられるかについて、何らかの指針等が必要ではないか？
「必要な広報活動を行っていく」
（６）認定認証業務間でのブリッジ認証局（BCA）を構築して、認定認証業務に係る電子証明書の相互
運用を促進するべきではないか？
「認定認証事業者の自主性において民間BCAを構築する際は、国は適切に情報提供等を行うべきである」
この報告書案を見ますと、どうも電子署名法について、あまり大きな変更を行うつもりがないように見受けられます。
■本文とは関係ありません（広告です）
「アンテナハウスPDF電子署名モジュール」では、PDFに電子署名を付けることができます。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月20日
電子署名法の見直し
総務省で電子署名法についての検討会の報告書案についてのコメント募集が出ています。
「電子署名及び認証業務に関する法律の施行状況に係る検討会」報告書（案）に係る意見募集
締め切りは24日（来週月曜日）ですので、もうあまりコメントの時間はありませんが、報告書をざっと眺めてみました。
最初にど肝を抜かれたのは、電子証明書の発行枚数です。意見募集とは何の関係もありませんが。
・お隣の韓国の公認証明書の発行枚数は、2006年10月現在で、1380万枚だそうです。
・日本は、認定認証業務に関わるものが、2007年3月末で31万４千枚。
また、公的個人認証サービスの電子証明書が、2008年１月末で45万枚。
両方あわせても、76万4千枚（累積発行数と思います。）
（報告書案pp.26～27 「外国の事例」）
日本の人口は韓国の2.7倍という数字になっていますので、人口あたりの発行枚数で言いますと、韓国は日本の49倍となっています。
電子証明書の発行枚数が多いから良いという訳でもないでしょうが、この数字を見ますと、電子署名の関係者が、普及してないと嘆く気持ちも分かります。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月19日
もうひとつの未来への道 (2)
昨日の続きです。
２３．Webベースアプリケーションの顧客は、個人や小さな会社。大企業は遅くなる。
２４．セキュリティに関する反論がある。しかし、個別企業でセキュリティ管理するよりは、運営に特化したベンチャの方が安全だろう。
２５．Webベースアプリケーションは、ITのアウトソースに相当するが、社内のシステム管理者に、競争の圧力を掛ける意味でも、アウトソースをするのが良いのではないか。
２６．大企業にものを売り込むには、それだけでお金が掛かる。だから、イントラネット・ソフトは生き残る。
２７．サーバでソフトを動かすのはメインフレーム時代からあった。しかし、デスクトップに変わったのは、小さな会社が新しいソフトを作ったからである。メインフレームでは固定費が高くてベンチャ企業はソフトを書けない。だからベンチャ企業はApple IIでソフトを書いた。
２８．デスクトップ・コンピュータ時代は、新しいソフトウエアの台頭で成立した。例えば、VisiCalcがその例。
２９．現代は、コンピュータが安くなり、サーバベース・ソフトウエアが有利だ。また、Webサイトがあればソフトが売れる。
３０．デスクトップ・ソフトを書くのはつまらなくなっている。マイクロソフトの土俵に上がらねばならず、さらに、売れたら、マイクロソフトにとって代わられてしまう。Winowsは、ハッカーに人気がない。
３１．Webベースアプリケーションは、ちょうど25年前のPCと同じ。
３２．デスクトップPCのユーザがコンピュータを理解しなければならないのは、マイクロソフトの問題である。Webベースアプリケーションにはマイクロソフトの場所はない。マイクロソフトはかつてのIBMと同じになる。
３３．しばらくの間、Webベースアプリケーションには支配者は現れないだろう。しかし、Webベースアプリケーションを作って運営するのは大変。開発者は机の下で眠らねければならず、責任も重くなる。デスクトップ・ソフトでは、開発者はリリースしたら休むことができるが、Webベースアプリケーションでは、ユーザが使い始めたら、リリースする前よりも大変になる。
３４．WebページはUIとして貧弱だが、とりあえずは使える。これも昔のPCと同じだ。そして、どのブラウザでも使えるソフトはそれだけで大きな意味がある。
３５．Webベースアプリケーションは、クライアントに関しては何も仮定しないので、Webが動作すればどこでも動作する。
３６．クライアント側で次に何が起こるかは予測できない。しかし、ブラウザが使える限り、Webベースアプリケーションは生き残る。
３６．安価に開発できて、もっとも小さなベンチャ企業でも公開できる。ユーザが気に入るものを作り、使った金より多くの収入が得られればやって行ける。
－－－ここまで－－－
Webベースアプリケーションで成功した先駆者の言葉らしく、開発者に挑戦を呼びかける結末になっています。デスクトップ・ソフトウエア業界は、マイクロソフトやアドビなど上位の企業に寡占化してきていますが、デスクトップPCからWebベースになって、新しいフロンティアが開けたということが良くわかります。
現在は、Paul Graham氏がこの話をしてから既に7年後となります。この間、Webベースアプリケーションが着実に増えているのは確かです。が、重厚長大なデスクトップアプリと、Webベースアプリケーションとのせめぎ合いはまだ決着が付いていないと思います。
今後はどうなるのでしょうか？AIRのようなRIAの登場で、また、少し、図式が変わるかも知れません。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月18日
もうひとつの未来への道
たまたま、会社の中の論敵から、Paul Grahamの
もうひとつの未来への道 ---The Other Road Ahead
http://practical-scheme.net/trans/road-j.html
というのを紹介されたので、読んでみたところ、これは大変面白ものでした。
主題は一言で言いますと、「25年前、デスクトップ・コンピュータが登場して、それが主流になっていたが、今後はWebベースのアプリケーション：ASPが主流になるだろう。」ということですが、実際にベンチャ企業を立ち上げて、WebベースのViawebというショッピング・サイト用のサービス（Yahooに売却してYahoo Storeとなった）を作った人の話です。
2001年に行われた講演の記録ですので、主題は、いまでは、ありふれたもののように見えますし、もはや新しいとは言えませんが、やはり先駆者だけあって、さまざまなところに、教訓になりそうな鋭い洞察が盛り込まれています。
まだお読みになっていない方は、ぜひ、目を通されると良いと思います。
とりあえず、時間を節約したい人のために要旨をメモしておきます。
１．デスクトップ・コンピュータを持つと、いやが応でもその動作を学ばねばならない。しかし、普通のユーザにその動作を学ばせるのはおかしい。
２．Webベースアプリケーションは、Webサーバで走り、Webページをユーザ・インターフェイスにする。ソフトウエアを使うのにコンピュータを学ぶ必要はない。
３．純粋なWebベースアプリケーションに必要なのは、インターネットに接続されたWebブラウザだけあれば良い。
４．私のコンピュータという概念はなくなる。クライアントにデータを保存するべきではない。アプリケーションのインストールもしない。
５．複数のユーザから同時に使える。ディスクのクラッシュもないので、データはより安全。
６．開発者にとっては、Webベースのアプリケーションは、ひとつのコードの塊ではない。違ったタイプのプログラムの集合になる。
７．ハードウエアを追加することで新しい機能を追加できる。
８．望みのどんなコンピュータ言語でも使うことができる。
９．ソフトウエアのリリースは、爆発的なものではなく、段階的な変更の連続になる。時には、1日3～5回。ソフトウエアは徐々に連続的に変化する。
１０．バージョン番号は、宣伝のために存在するだけで、意味が無くなる。
１１．バグを手元で再現できる。小さな変更だけでリリースするので、複合バグが出にくくなる。バグが出ても新鮮なので解決しやすい。
１２．関数的プログラミング手法を使いやすい。
１３．サポートのやり方も変わる。ユーザからのフィードバックが大歓迎になる。
１４．バグをその場で修正するので、サポート部門と開発者が密接になる。
１５．ソフトウエアを直ちにリリースできるので、アイデアを直ぐ実装して反映できる。
１６．信頼できる少数のプログラマしか必要としない。グループが小さくなればなるほど、開発の生産性が上がる。但し、プログラマがシステム管理者にもならないといけない。
１７．全てのユーザが行う全ての振る舞いを観察することができる。ユーザを見ることで、設計上の指針も得られる。どこで困っているかも分かる。
１８．サーバあたり何人のユーザをサポートできるかでコストが決まるので、効率が重要だ。
１９．試用サイトでユーザを獲得する。試用サイトのユーザのクリックを調べて改善する。
２０．サブスクリプション形式が自然な課金方法だ。
２１．定常的な収益が得られる。海賊版も出ない。
２２．ISPをリセラーとして販売するのは悪いアイデア。自分でサーバを管理すべきだ。それで、ソフトとハードを常に改良できる。
---続く--
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月17日
アドビAIRを試してみる (2)
◎ゆる時計
AIRで作ったウィジット。
※ウィジット：アプリケーションソフトやデスクトップ上で動作する、小規模なアクセサリーソフト。ガジェットとも呼ばれる。(Wikipediaより）
この会社はウィジットを集めたサイトも提供しています。
ウィジットタウン：http://www.widgetown.com/
ウィジットプラットフォームという言葉もあります。ここの分類は次のようになっています：
[yahoo!ウィジット、Googleデスクトップガジェット、WindowsVistaガジェット、MacDashboardウィジェット、AdodeAIRウィジェット、その他]
ガジェット広告という新しい分野も出現しているようです。
◎NHK時計
Yahoo!ウィジェット版やWindows Vista版、Mac OS X版につづいて、AIR版ができたようです。
でも、メールアドレスを申込書に記入して送信しなければならないようなので、とりあえずパス。
このあたりまでは、ウィジェット／ガジェット作成手段としてAIRを使うものが多いということになります。
◎Web私書箱（β）
これは、WebのアーカイブサービスのインターフェイスとしてAIRを使おうということのようです。
AIRを使うことで、ドラッグ＆ドロップでファイルをアップロードが可能になります。
ローカルからWebブラウザ経由でのuploadが、ドラッグ＆ドロップでできるようになる、というのはAIRの売りです。それを生かした例ということ。
◎FLO:Q（フローク）
ソニーが行っているもの。
企業コラボ・ウィジェットもあります。
ウィジェットを簡単なメディアとして使おうということのようです。
こうしてみますと、ウィジェット／ガジェットを新しいメディアとして注目している人がいて、その開発手段としてのAIRが注目されているということなんですね。このあたりは恐らくFlashの延長ではないかと思いますが、PDFが出てきませんね。どこかにPDFを使った例はないのでしょうか。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月16日
アドビAIRを試してみる
昨日、某所でアドビのAIRのセミナーを聞きました。
早速、AIRのランタイムをダウンロードしてインストール、試してみようと思い、AIRギャラリーを見ました。
http://www.adobe.com/jp/devnet/air/gallery/
◎ForesMessenger
下のボタンを押して、とありますが、ボタンが見えない！と思ったら、どうもFlashPlayer9がないとボタンが見えないようです。FlashPlayer9をインストールしたらボタンが見えました。
１．ボタンを押す
２．Open/Saveを選択する
３．インストールするか聞いてくる。（Publisherが認識されない（Unknown）。ちょっと怖い。たぶん、ファイルに電子署名してないからだろう。）
４．インストールボタンを押す。
５．ロケーション（フォルダー）を選択
６．これでインストール完了
７．動いた
しかし、AIRで作る意味があるのかどうか、分かりません。
◎Fax・書類送付状作成ツール
アスクルのものダウンロードファイルが、ZIPになっている。
AIRって、ダウンロードからインストールまでの簡単さが売りだと思いましたが、ZIPファイルを配布してもしょうがないんじゃないの？
と思いながらZIPファイルを解凍して実行する。
インストールは、インストール許可するかを確認するだけでOK。
これは、なかなか便利です。
Flashで作ったアプリの例ですが、通常のデスクトップ・アプリと対して変わらないようにも思います。
AIRで作る意味がどこにあるのだろう？わかりませんね。
■AIRというのは、FlashとHTMLとPDFを統合したものと、Adobeの人は言っていましたが。
◎AIRmikanβ ver0.9
これは、面白そうと思って、ダウンロード・ボタンを押します。
ダウンロード確認ダイヤログでOpenします。
「Sorry, an error has occurred.」となってしまいました。
どうもAIRのバージョンが違うようです。
何事もはじめはこんなもの？
まだAIRのよさは分かりません。明日、また続きを試して見ましょう。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月15日
Elliotte Rusty HaroldのXMLの未来予言（2）
昨日の続き
■Atom Publishing Protocol （APP)
１．従来、クライアントからサーバへのアップロードはFTPであった。しかし、初心者にはFTPは理解できない。
２．APPを使えば、URLとユーザ名とパスワードだけで、WebにPOSTできるので、この問題は解決する。
■データベース
１．XMLをファイルシステムに置くのは、データの重複、検索などの都合上、効率が良くない。
２．リレーショナル・データベースは、XMLの保存には、データ構造上適切でない。
３．XMLデータベースが増えてきた。
ロー・エンド： eXist, Berkeley DBXML
ハイ・エンド：Mark Logic, IBM DB2 9pureXML
■XQuery
１．XQuery 1.0 は何年もの開発の後、とうとうリリースされた。2008年には更新が完成しないかもしれないが、十分使えるレベルである。
２．2008年には、javax.xml.xqueryもリリースされるはず。
-----ここまで----
【私的感想】
Elliotte Rusty Harold氏は、さすがに、 「XMLバイブル」の著者だけあって、なかなか、よく状況をまとめていると思います。しかし、私には、あまり同意できない箇所もあります。
特に、オーサリングのあたりはあまり同意できません。特に、次の点。
１．彼はPublishingと言いながら、XHTMLとHTMLしか頭に無いようです。HTMLにするだけなら、わざわざOfficeを使わなくっても、「ホームページ・ビルダー」で十分じゃないかと思います。
２．OfficeでXMLをまともにオーサリングするのは至難だと思います。一番困るのは、属性を入力する方法がないということ。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月14日
Elliotte Rusty HaroldのXMLの未来予言（１）
The future of XML（Elliotte Rusty Harold）
■夢占い
１．過去3年間は、Webアプリケーションが、伝統的なWebサイトの遥か先まで進んだ時期であった。ワープロ、表計算。。すべてブラウザに乗った。
２．Sunの夢は、Javaではなく、JavaScriptで実現した。Sunの最大の誤算。
３．ブラウザがOSに取って代わるというetscapeの夢が実現しつつある。もはやOSを気にする人は居ない。
４．Ajax=JavaScript+XML。xはXMLを表すとはいうものの、XMLはこの動きにそれ程関係していない。
５．DOMが問題。開発者はDOMしか知ろうとせず、DOMとXMLの区別を知らない。DOMは、XMLを処理するのには最悪のAPIである。
６．DOMは、XMLの首に掛かった重荷。ソフトウエア業界がXMLを採用を進めるための最大の障害である。W3Cは、悪い仕様を廃止すべきだ。
７．XMLは死んだのか？
■XMLのルーツ
１．XMLの基本仕様はどれもソフトウエア開発用に設計されたものではない。出版／Web出版を意図したものだ。
２．XMLの前身であるSGMLは出版用。SGMLの最大の成功であるHTMLは最大の失敗例でもある。ブラウザ開発者もデザイナも誰一人SGMLを知らず、勝手な拡張でSGMLパーサもHTMLを解析できない。
３．XMLはSGMLを軽くする目的では成功。しかし、Webに整合性をもたらす目的では失敗。XHTMLはHTMLの方言に過ぎない。
４．XMLソフト開発用ではないが、プラットフォーム独立、国際的なデータ形式、入手しやすい無償パーサで、開発者の役に立っている。
５．出版という点では、編集、出版、読者について考えてみることが必要。
■編集
１．編集という意味では戦いはXMLの勝利で終わった。MS Office、OpenOfficeなどすべてXML形式になった。
２．政府が、OpenDocやオープン・ソースに移行することで、MS Officeは徐々にシェアを失うだろう。
３．XML形式になって、バイナリ形式と比べて、他の形式に変換するのが格段に楽になった。
４．2008年は、ゲームの枠を変えるXML最大の技術XSLT誕生10周年である。フォーマットについて、あまり気にしなくても良くなり、ベンダー・ロックインが問題でなくなった。
５．OOXML、OpenDocからHTMLへの変換が重要。
６．XMLとXSLTで過去の隠れたデータも表に出てくる。
７．編集ツールは、WordやOpenOfficeで決まりだ。
---続く---
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月13日
O'Reilly MediaのSafariU
O'Reillyといえば、Web2.0という言葉で有名ですが、O'Reilly Media社は、世界でも最も有名なコンピュータ関係書の出版者であり、オンライン媒体による出版社としても知られています。同社は、米国の技術・コンピュータ系書籍の出版社としては、15%のシェアを持っているそうです。現代の出版会社としては、一番面白い存在だと思っています。
先日、AIIM2008にて、MarkLogic社のブースでO'ReillyのSafariUというサービスのケーススタディを配布していましたので、貰ってきて眼を通してみました。
このSafariUというのは、大学の先生達が、授業につかうためのテキストをカスタムで作成するサービスです。
http://www.safariu.com/index.do
次のような機能・効果があるとされています。
・教授は、2200冊以上の本、5000の論文などから必要な材料を探しだして、カスタムの教科書を作ることができる。
・カスタム教科書をオンラインのシラバス(教授細目）に変換する。
・学生は、10冊までテキストで言及した本にアクセスできる。
・学習対象物を教授達は仲間と共有できる。
・コストは、教育者側には無料。学生が負担。但し、年間700ドル分以上の学生の申し込みが必要。
・SafafiUのカスタム教科書は250～300ページで、学生には、46ドルから52ドルで提供される。2003-2004年には、4年制大学の学生の1年間の教科書代は850ドルだったので、学生にとっては大きな負担減になる。
確かに、大学や大学院の授業で使うテキスト代はなかなか高いですから、これをカスタムで安く作成できるようになれば、学生にとっては大変に助かります。学生というより、その親にとってもね。
こういう新しいサービスを構想して、実現していくことができるというところが、米国のすごさかなと思います。日本ではこういうサービスの構想はあるのでしょうか？
◎ケーススタディ2006年に作成されたものですが、探しましたところ、Webでも公開されていますね。
The Reality of Web 2.0: O’Reilly Media’s SafariU Leads by Example
◎SafariUは、2005年5月開始だそうで、ニュース・リリースが出ています。
O'Reilly and Safari Books Online Launch SafariU: Custom Publishing and Online Platform for Educators
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月12日
AIIMでPDF/Aについてのセミナーを計画
アメリカのAIIMでは、PDF/Aについての専門的なセミナーを計画しているようです。
PDF/Aについては、欧州が一番進んでいて、米国は遅れているようだと、先日も書きました。
2008年03月07日 AIIM International Expo & Conferenceの参加記
実際、欧州のPDFソフト・メーカが中心になって、PDF/A Competence Centerを設立していますし、4月には、ここが中心になって、PDF/Aについての会議が開催されます。
先日のAIIMでも欧州系のPDFソフト・メーカの各ブースで、この国際PDF/A会議のちらしを配っていました。欧州ベンダが一体になってPDF/Aを推進しているな、と感じて、少々焦ったのですが。
今度は、米国AIIMが専門的セミナーでPDF/Aの啓蒙を始めるとなりますと、ますます、日本との差が開いてしまいます。困りますね。
とりあえず、AIIMセミナーの内容のリストをご紹介しておきます。
・ 保存
• 保存の問題
• ERMの概要
• ファイル形式の概要
• PDF/A 入門
• 保存における電子署名
• 準拠レベルと制限される機能の概要
• カラー
• 保存のためのメタデータ
• 長期保存のためのワークフローと移行
• 準拠レベルと問題点
• デジタル生まれの文書からPDF/A文書を作成する
• スキャンしてPDF/A を作成(イメージをPDF/Aに変換)
• PDF/A ファイルの妥当性検証
• 実装のベスト・プラクティス
• PDF/A 製品の選択
• 他のPDF標準のPDF/Aとの関係
• PDF/Aの法的な、コンプライアンスに関する関わりあい
----ここまで---
なかなか興味深い内容です。
Webでのセミナーも計画されているようですので、できることならチェックしてみたいものです。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月11日
Web時代の出版・マーケティング DRMを見直す
日経エレクトロニクスの3月10日号に「コピーに自由を生まれ変わるDRM」という特集がでているとのこと。
まだ、紹介記事や関連の記事を読んだだけですが、大変面白そうです。
ここに編集長のテレビPRが出ています。
http://bptv.nikkeibp.co.jp/article/080306/080306152.html
「YouTubeで世界へ」，角川グループがYouTubeの積極活用に踏み切る
によりますと、角川グループは、YouTubeの映像認識技術をつかって、動画による収入を著作権者にも分配する仕組みを作ろうと考えているようです。
■インタビュー記事
角川デジックス 代表取締役社長 福田正氏インタビュー「Googleと組んだのは黒船だから」（前編）
角川デジックス 代表取締役社長 福田正氏インタビュー「Googleと組んだのは黒船だから」（後編）
PDFでもAdobeのLiveCycleのような本格的なDRMがあります。しかし、販売を目的とするコンテンツの場合、DRMを使うと、DRMを使わないときよりも売り上げは減ってしまうと聞きます。つまり、DRMの不便さがユーザを逆にコンテンツから遠ざけてしまうということらしいです。
そうなりますと、これはコンテンツを販売したい人、そのコンテンツを利用したいユーザの両方にとってデメリットになってしまいます。ですので、多くを売りたいと考えた場合は、DRMなしで販売するほうが恐らく売上が増えるわけですが、そうなりますと著作権の保護ができないというジレンマがあります。
情報を紙で販売している時代には、紙を複写する手間とかコストの問題があり、これが複製の抑止力として働きました。しかし、電子文書は、複製の手間やコストはほとんどゼロですので、複製を抑止するものがなくなります。しかも、何回複写しても完全にオリジナルと同等です。
そういう時代に、どうやって情報を出版するビジネスを展開するか、これは、デジタルTVや動画の世界でも大きな問題ですが、PDFによる情報の販売でも、まったく同じ課題を抱えています。
投票をお願いいたします
投稿者 koba : 22:00 | コメント (0) | トラックバック
2008年03月10日
Arts PDF/Nitro PDF 物語り
先週のAIIMで、ActivePDFのブースにNitro PDFのチラシが置いてありましたので、「ActivePDFはNitroPDFを販売しているの？」と聞きましたら、「いや、単に紹介しているだけだよ。」と。
今日、PDFZoneのニュースを読んでいましたら、「2008/3/3 NitroPDFとActivePDFがパートナーシップ」という記事が出ていました。
ActivePDFは、PrimoPDFという無償のデスクトップ用PDF作成ソフトを配布しています。PrimoPDFは、日本でも良く話題に上りますので、知っている人も多いと思いますが。PrimoPDFのユーザにNitroPDFを紹介しようということのようです。
もうひとつ、
Opinion: Nitro, activePDF: Two little Davids taking on Goliath
という評論的な記事も出ています。
ところで、上述の記事を読んで、ArtsPDFとNitroPDFの関係について関心をもちましたので、少し調べてみました。
ArtsPDFは、主に、Acrobatのプラグイン・ソフトでしたが、独自にPDFを操作する機能を開発して、NitroPDFというAcrobatの代替製品を発売したようです。現在は、ArtsPDFも販売していますが、恐らくは、今後は、プラグインはやめて、NitroPDFを推進するのでしょうね。
もともとオーストラリアのBinary Thingsという名前の会社が、オーストラリアで、NitroPDFという名前の会社に変更。もともとカリフォルニアのArtsPDFという名前の会社が、おなじく、アメリカで、NitroPDFという名前の会社に変更。NitroPDFが今後の戦略商品＝会社名ということでしょう。
また、「Nitro（旧ArtsPDF）は、Adobeとのソリューション・ネットワーク（ASN）のメンバーで誰よりもAdobeに近かったが、2005年にNitroを出したとたん、一夜にして、Adobeとの関係がゼロになった。」そうです。
PDF PlanetというPDF関係のポータルサイトも彼らが運営していますが、Nitroを出したことで、「Adobeがスポンサーから降りた。」とのこと。Adobeも競争相手には容赦しませんね。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月09日
製品アップデート情報 まとめ
弊社製品のアップデート情報をまとめてご紹介します。（2月上旬～3月7日）
１．デスクトップ製品
(1) PDFスイート・リッチテキストPDF4
リッチテキストPDF4用 Antenna House PDF Driver V3.2MR3（3.2.4）改訂版のダウンロード
(2) PDFスイート・書けまっせ!!PDF3
書けまっせ!!PDF3のV3.0.0～V3.0.3までをお持ちの方向けの更新データ
２．システム製品
(1)(1) XSL Formatter V4.2MR5 3月4日公開
(2)Web Service Interface V2.1 for XSL Formatter V4.2MR2 2月29日公開
(3)PDF Tool V2.6MR3（Windows 版） 2月25日公開
(4)PDF Driver V3.2MR4 2月25日公開
(5)サーバベース・コンバータV1.4MR4 2月13日公開
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月08日
AIIM International Expo & Conferenceの参加記(続き)
OnDemandのコーナーで目立ったキーワードのひとつに、Web-to-Printがあります。
Web-to-Printは、デザインをWebブラウザ上で行って、それをPDF出力して印刷するということだろうと思います。これまでのカタログやチラシの印刷では、InDesignやQUARKなどのDTPソフトでレイアウトしてPDFを作成して、印刷するというやり方をとっていたわけです。今後は、レイアウトがWeb上に移行するいうことでしょうか？
OnDemandは出力する印刷側の話、Web-to-Printはデザインとコンテンツですので入力側の話ということ。OnDemandでは、パーソナライゼーションも結構やっていたようです。
AIIM/ECMのコーナーでは、ビューアの会社が結構がんばっていたのが予想外でした。ECM系のビューアは、以前はTIFF中心の画像ビューアが良く使われていたようですが、現在は、PDFも使われるようになってきています。画像／PDFビューアの会社としては、次のところが眼につきました。
・ViewonePro （Daeja Image Systems Ltd. ） イギリスの会社
・FlexSnap （SnowBound社） 米国
・PRIZM Viewer （Pegasus Imaging Corp.） 米国の会社
ECM関係は、スキャナーで取り込んだ画像の形式がTIFFからPDFになったということだと思います。スキャナーでデータを取り込む話が多いのは日本もアメリカも似ているように思います。でも日本の展示会ではあまりビューアの会社は見かけてないように思いますが、アメリカではビューアの会社が多いのは不思議。
あとは、XPSでしょうか。MicrosoftのブースのそばにXPSコーナーがあり、比較的新しい会社と思いますが、4社が出展していました。
XPS関係は、ビューアの会社などでも、対応ファイル形式として既にリストにあげている会社も良く見かけましたので、PDFほどではありませんが、ひとつのファイル形式として定着してきたのかな？と言う印象です。
最後に、アンテナハウスのブースの写真をご紹介します。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月07日
AIIM International Expo & Conferenceの参加記
アンテナハウスは、昨年まで、海外では、実質的にXSL Formatterのみを販売していましたので、XML関係の展示会のみに参加していましたが、今年からPDFにも参戦ということで、今年は初めて、AIIM International Expo & Conference2008に出展しました。AIIM2008には、キヤノン、シャープ、富士通、リコーなど、日本のOA機器メーカが多数出展していました。日本のソフトウエア・メーカでは日立システムなどが出展していましたが、ハードウエアと比べますと、あまり目立たなかったように思います。
聞きかじりですが、AIIM2008は、On Demand、Xplorと言った展示会を吸収・合併して大きくなったようで、会場は広いのですが、出展社の色分けでは、AIIMの中心であるECMソフトの他、On Demand関係の印刷機器・印刷関連ソフトの出展が多くありました。昨年と比べて、出展社数は多くなっているものの、規模が大きなブースは減っているとのことです。どうも、大手メーカは、近くのホテルで個展を開いているらしいです。
このあたり、COMDEXと似た傾向になっているようで将来が心配です。COMDEXも大手の出展社がCOMDEXに出展する代わりに、近くのホテルの会場を借りて個展を開くようになった結果、COMDEX本体が2004年に開催中止に追い込まれてしまったという経緯があります。
実は、以前に、そんな記事を読んだ記憶がありますが、今回、もう一度チェックしましたら、Wikipediaには違う理由が書いてありますね。
実際のところ、事の真相は、ちょっと分かりません。
それはともかく、なにかのご参考になればと思い、来場者とか、出展者について幾つか感じたことをメモしておきたいと思います。
１．XMLについて
いきなり、コアな話で恐縮ですが、XML関係の出展者はあまり多くありませんでした。弊社もXSL Formatterのバナーとちらしは用意しておきましたが、まったく関心をもたれませんでしたね。ほとんどの来場者は、XMLなんて言葉も知らない人だと思います。出展者にも少し聞いてみましたが、10人中2,3人しかXML、特に、XSLについては知らなかったようです。それでもXSL-FO関係の出展者が、アンテナハウスの他に2社、それからCSS関係で1社ありました。う～～ん。少なくとも、この展示会にXMLとかXSL-FOを前面に出した出展は金の無駄、じゃないかな？
２．PDF
PDFは出展者も多かったですが、参加者もPDFに的を絞って調べに来ている人がいるようです。ブースにやってきて、こういうことができないか？という質問をする人もいましたし、製品の説明をすると熱心に聴いてもらえたようです。
(1)PDF/A
ISOのPDF/Aの仕様作成者も見えて、PDF/Aはサポートしているかなどと聞かれました。でも、欧州から来たほかのPDFベンダに聞きましたところ、PDF/Aは欧州は熱心だが、USは欧州ほどじゃないと言っていましたが。
(2)PDFソフトのベンダ
PDFソフトの出展者は多かったですね。
以前（2008年01月10日AIIMExpo 2008に出展します）で、出展者名簿から8社リストアップしました。
これ以外に、次の会社を見つけました。
・callas software（独）
・apago
・ABBYY （スキャナソフトの会社らしい）
・Bluebeam Software
・IRIS
他の製品（ビューアなど）にPDF表示機能などを統合したり、あるいはスキャナなどからPDFを出力する機能などは、もうあたりまえなので、数えきれません。
でも、これだけPDF関連製品の出展が多いのに、Adobeが出展しておらず、Adobe PDFの姿が見えないのが、また面白いところです。AIIMって、米国で、PDFのISO標準化を推進している中心団体なのですがね。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月06日
PDF：商用ソフト、フリーソフト、オープンソース 続き
昨日の続きですが、要するにフリーソフトとは無料で使えるソフトということです。もうひとつ、オープンソースという言葉があります。オープンソースも概念がややこしいですが、これにつきましては、以前にブログで詳しくお話しましたし、それを次のところにまとめてあります。
オープンソースは、平たく言えば、プログラムのソースが公開されていて、かつ、改変・再配布・再頒布が許諾されているものということができます。このためオープンソースは、無償になりがちですが、RedHat Linux, MySQLのように複雑な（トリッキーな）利用契約を交わすことで、実質的にかなり高額な利用料を取っている場合もあります。
そうえば、MySQLは、最近Sunが買収しました。MySQL社にはベンチャ投資家がかなり投資していたようです。MySQL社が単体の会社経営としてどうなっていたかは分かりませんが、少なくとも投資家にとっては、オープンソースへの投資の成功例になったのだろうと思います。
「オープンソース・ビジネスについて考える」でも、オープンソースが投資家の対象になり始めていると指摘しましたが、こうした成功例により、今後は、オープン・ソースへの投資が増えることになりそうです。
で、まとめですが。フリーソフト＝無償ソフトと定義しますと、
・個人や有志のソフトウエア作者(達)が作って、無償で世に公開するソフトには、良いものが沢山あります。コンシューマ向けの雑誌で、こういうのを紹介するのはそれなりに有意義だし、必然性があると思います。商用ソフト側からは、そういうソフトとの共存関係を築くようにしていくべきだろうと思います。
・インターネット・エクスプローラのように、Microsoftのような大きな会社が開発して、無償で出すソフトについては、かなりな脅威になります。これは、独占禁止法などの観点から対策が必要でしょう。そういえば、NorwayのOpera Software社が、昨年12月にMicrosoftをEU独占禁止法で訴えました。事情はあまり詳しく分かりませんが、この訴訟の行方には注目が必要ですね。以前に、ネットスケープの訴訟でMicrosoftがUSで企業分割寸前まで行ったのですが、その再現になるかどうか？まあ、欧州での出来事ですが、今後の世界は欧州中心になりつつありますし、眼を離せない話です。
・プロプライエタリな商用ソフトにとっては、オープンソースはなかなか大きな脅威です。企業システム用のオープンソースの開発者は、現在は、既に個人や有志ではなく、企業に所属するプロの集団になりつつあります。そういう意味では、オープンソースは、商用ソフト開発の新事業形態になってきているということであり、オープンソースは、生半可な商用ソフトに勝る機能を備えるようになってきています。そうなりますと、オープンソースと競合したとき、どうやってそれと戦うか？これは相当に知恵を絞らねばなりませんね。でも、XSL Formatterは、50万円なんですが、無償のオープンソースFOPと同じ市場で競争して、少なくとも過去数年間は十分なお金を稼ぐことができました。ですので、無償のソフトと競合しても、商用ソフトが生き延びる方法があるということは言えます。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月05日
PDF：商用ソフト、フリーソフト、オープンソース
「日経PC21」といえば、市販の雑誌の中でも、現在、PDF関係の記事が充実しています。
で、「日経PC21」の記事では、PDFのフリーソフトが沢山掲載されているようです。そんなことで、編集の人たちと話していて、フリーソフトと商業ソフトの話になったので、ちょっと意見を述べます。
意見を述べる前に、一応、言葉の定義をしておきます。関連する言葉を上げてみましょう。
(1)フリーソフト
(2)無償ソフト
(3)コマーシャルソフト（商用ソフト）
(4)プロプライエタリ・ソフト(占有ソフト）
(5)オープンソース
フリーソフトについては、GNUは、次の定義をしています。
フリーソフトウェアの定義
「フリーソフトウェア」で問題とするのはいわゆる「自由」であり、価格ではありません。この考え方を理解するためには、「ビール・ご自由にお飲みください」の自由ではなく「言論の自由」の自由を思い浮かべてください。「フリーソフトウェア」のフリーは、ユーザがソフトウェアを実行、複製、頒布、研究、変更、そして改良する自由のことを指しています。
GNUの定義だと、商用ソフトとフリーソフトは、対比されるものではなく、GNU的にはフリーソフトの反対語は、プロプライエタリ（占有）ソフトです。
日本では昔から、無償ソフトのことをフリーソフトと呼んでいたようです。特に、シェアウエアや無償ソフトを沢山あつめた日本で一番大きいダウンロードサイトである、Vectorでは、次のように定義しています。
http://www.vector.co.jp/for_users/study/soft_type.html
使用に制限はありません。しかし、著作権はあくまでも作者に帰属します。作者から許可を得ていなければ、改変したり販売したりすることはできません。
つまり、GNUの定義とVectorの定義は、同じフリーソフトという言葉を、まったく正反対に定義しています。Ｖectorの言葉のフリーソフトはGNU的にはプロプライエタリになります。
これを理解して言葉を定義してから話をしないと、同じ言葉で別のことを意味してしまい、議論がかみ合わなくなります。
私としては、GNUの定義は論理的に自己矛盾を起こしているので認められません。GNUの一番の論理矛盾は、『「言論の自由」の自由を思い浮かべてください。』と言いながら、GNU のGPLは、プロプライエタリ・ソフト(占有ソフト）の存在を否定している点です。つまり、GNUは、自分の主張だけの世界で自由と言っていて、異なる世界を認めていない、まさしく、現在のアメリカと同じじゃないか、ということ。そういう自由は自由じゃないと思うのですがね。
そんなわけで、私は、ベクターの「フリーソフト」の定義を採用します。ベクターの定義は論理的にはかなりいい加減ですが。フリーソフトの定義って、いい加減なところが却ってフリーソフトらしくて良いのではないでしょうか。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月04日
「PDF Write 3」（書けまっせ!!PDF3のグローバル版）発売！
米国Bostonで開催の「AIIM International Exposition and Conference」の開催にタイミングを合わせて、「書けまっせ!!PDF3」のグローバル版を発売しました。
グローバル版は、次の2種類です。
「PDF Write 3」（スタンダード版相当：US$49.95）、「PDF Write 3 Professional」（プロフェッショナル版相当：US$99.95）としています。
グローバル版は、1ソースで多言語環境で動くようにしています。多言語といっても、現在は、日本語と英語だけですが。OSが日本語ロケールの時は、日本語のメニュー、OSが日本語以外のロケールの時は英語のメニューが出ます。将来は、もっと色々な言語で動くようにしたいものです。
10日間の評価版もありますので、関心をお持ちの方は、ぜひお試しください。
【ご注意】インストーラとドキュメントは英語のみで。本体のみをグローバル化した状態です。
実は、単純に、日本語のメニューを英語にしただけではなく、日本語版と比べて幾つか機能強化をしています。
１．単位系
(1)寸法の単位
日本語では余白など設定単位はミリだけでしたが、グローバル版ではインチとミリの切り替えを可能としました。
(2)通貨単位
日本語版の通貨単位は円のみですが、グローバル版ではさまざまな通貨単位を設定することができます。
２．書式
(1)日付書式
日付の書式ってかなり国によって違いますね。
(2)その他
電話番号とかZIPとか、いろいろ。
３．グローバル版のみの機能
・新しい白紙の用紙を作る機能
・テキストの進行方向の逆転
英語で、文字列を下から上に書き進める縦書き。
余談ですが、そういえば、ラテン文字列を下から上に書き進める欧文縦書は、XSL-FOにも無いんじゃないでしょうか。XSL-FOの縦書き（writing-mode="tb-rl"）はラテン文字列を上から下に書き進めるはず。
ソフトウエアをグローバル化しようとしますと、いままで知らなかったことをいろいろ勉強しなければならなくなって、それだけでも結構楽しいものです。ユニコードが使えるから、国際化なんて、ぜんぜん違います。ユニコードは国際化の必要条件ですが、十分条件じゃありません。
もう少し、大上段に構えた表現をしますと、団塊の世代が引退して、日本の労働人口が減少、その上少子化で人口も大幅減となれば、既存製品の国内市場は縮小必然。これに備えて生き残ろうとしたら、何が何でも、海外に活路を見つけなければなりません。トヨタが世界一といっても、伸びているのは輸出であり、国内販売は苦戦中のようです。自動車販売業界全体の苦境を伝えるニュースを読みますと、国内自動車市場も、まさにそうなっているのだということを肌身に感じます。
携帯電話でも、三洋電機撤退に続いて、先日は、三菱電機が撤退決断、というニュースがでました。確かに、海外に活路がなかったら長期的には撤退せざるを得ないだろうなと思います。
常にエマージング産業が出現して、産業構造（内容）は変わっていくわけですが、ソフトウエア産業はもうレガシーな産業ですからね。ソフトウエア産業も他の産業の例に漏れず、国内市場縮小は不可避でしょう。マクロで言えばそうなります。
まあ、私なんぞは、そんなに悲壮感をもっている訳じゃなくて、結構、楽しんでやっているのですけどね。ということで、今日から、Bostonにて、AIIMに参戦です。
「PDF Write」100万本売るぞお！
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月03日
電子文書と紙文書 — PDF電子署名の場合
昨日お話しましたことを整理しますと、電子署名の用途のうち、「署名者である人間が承認したという意思を確認するための署名では、署名対象文書の内容が正しく画面なり紙に可視化されていること、そして、それを署名者が認識したという事実が保証されないといけないこと」、となります。
電子文書のうち、PDF以外では、これを技術的に保証するのはなかなか難しいと思います。
PDFでは、どうでしょうか？PDFは、紙に印刷する状態を電子ファイル化したものですし、そのファイル内の命令の仕様が公開されていますので、他の電子文書よりは、保証しやすいと思います。
しかし、PDFでも次のような例外があります。
・PDFではJavaScriptを埋め込んで、可視化状態をプログラムで、条件により変更してしまうことができます。
・可視化するビューアやツールによって表示内容が変わってしまうリスクがあります。これに類似する分かりやすい例は、PDFで画面上に墨を塗って文字を消したように見せても、実はその文字がファイルの中に存在していて、他のツールで見えてしまうということがあります。
■参考
2006年08月13日 PDFで隠したはずの個人情報丸見え — について
PDFで隠したはずの個人情報が丸見えになるということは、「PDFでも可視化される状態が、状況によって変わってしまうことがありうる」、ということを示しています。
このためPDFの署名では、「法的内容証明」という機能（オプションです）があります。
■参考
PDF Reference 1.7
8.7.4 Legal Content Attestations
pp.742～pp.743
このあたりは難しいのですが、PDFの電子署名では、上に述べましたような、可視化の方法によっては、相手をミスリードする可能性があることを踏まえて、署名時に、ミスリードしそうな内容をチェックする機能が定義されているということです。この機能はオプションで、アンテナハウスPDF電子署名モジュールは、残念ながら、未対応です。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月02日
電子文書と紙文書 — 電子署名の目的と電子文書の状態
さて、電子文書は、紙文書とちがって、データの生成から可視化されるまでに複雑な過程を経過することを昨日お話しました。
電子文書を可視化する過程について考えていて、「電子文書の可視化過程と、電子署名の関係はどうなんだろう？」と疑問を持ちました。
電子署名自体は、デジタルデータであれば何にでも付与することができます。しかし、電子署名の使用用途によって、署名対象文書の種類が変わってくるはずです。
電子署名のプリミティブな役割は、署名対象文書が、署名後に改竄されたことを検出することです。電子署名を、この用途で用いるならば、どのような電子文書を対象に電子署名しても意味があると思います。この場合は、人間は介在せず、コンピュータのみで計算・処理することができますし、どのような電子データであれ、署名の付与と、署名検証のアルゴリズムは同等の意味をもつからです。
これに対して、電子署名を、署名者である人間が内容を確認して、確かに承認したことを証明する場合、すなわち署名者の意思を保証するために用いる場合は、事情が変わってきます。
この用途では、XML文書やバイナリの電子文書に人間が署名することは意味をなさない場合があるだろう、と思われます。
なぜかと言いますと、XML文書の場合は、レイアウト指定（スタイルシート）、バイナリデータの場合はアプリケーションによって、可視化され、表示される情報の意味が変わる危険があるからです。
極端な例ですが、「この色は、確かに、自分の指示した色です。」と言って承認しても、モノクロのディスプレイで見る人と、カラーディスプレイで見る人では異なった色を見ていることになります。同じカラーディスプレイでも、カラーがデバイス依存になることがあります。
そうしますと、XML文書やバイナリ文書に、人間の承認を証明する用途の電子署名をすることに意味があるかどうかは、かなり慎重に検討を要することになります。
では、PDFに電子署名することは、どうなのでしょうか？次回はこれを考えて見ます。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2008年03月01日
電子文書と紙文書 考
昨日、「紙文書と電子文書を同列に並べて議論するのは、本質的に違うものを比較しようとしているのではないか。」と申し上げましたが、このことについて、もう少し考えてみました。
人間が紙に文字を書くのは、脳や手の中はともかく、大変単純な行為だと思います。これに対して、デジタルデータが紙に可視化される過程は、かなり複雑です。次の絵をご覧ください。
これは、テキスト中心のデジタル・データ（以下、これを「電子文書」と総称します）が可視化されるまでの流れを大雑把に書いたものです。
まず、電子文書には大きく分けると3種類があると思います。
１．ワープロの文書、DTPソフトのデータのようにアプリケーションと不可分、コンテンツとレイアウト(書式）情報が渾然一体となったバイナリ形式のデータ
２．レイアウト情報をもたないデータ。XML、CSV、あるいは、EDIの中を流れる取引データなど。
３．PDF、XPS。デジタルの紙ともいえる可視化された状態を電子ファイル化したもの。
１～３によって可視化の処理がかなり異なります。
まず、ワープロやDTPのバイナリデータですが、これはアプリケーションと不可分になっているため、可視化するには、その電子文書を作成したアプリケーションが必要です。元のアプリケーションがなければ、正しく可視化できません。場合によっては、アプリケーションのバージョンが異なると可視化した結果が異なってしまいます。例えば、Microsoft Wordでは、異なるバージョンで作成した電子文書を読むと、文書のレイアウトが崩れてしまうことがあります。これは、実際に経験された方も多いと思います。
次に、レイアウト情報をもたない内容だけの情報。これを可視化するには、外部からレイアウト定義情報を与える必要があります。例えば、XMLにレイアウト指定を与える標準的方法として、XSL-FOとかCSSがあります。CSVのような情報では、なんらかの定義を与えて、可視化する必要があります。このような電子文書は、アプリケーションからは独立ですが、レイアウト定義によって、可視化結果が異なるということになります。
PDFやXPSは、プリンタ装置を使って紙に可視化するプログラム（手続き）を電子ファイル化したものということができます。このプログラム言語をPDL(Page Description Language）と言います。その手続き（PDL仕様）が、標準として公開されていれば、比較的標準的な可視化ソフト(ビューア）を作ることができます。しかし、DocuWorksのように、非公開のものもあります。
このように、電子文書というのは非常に幅広い概念であり、多くの場合、電子文書の見え方はそれを可視化するアプリケーションや装置に依存している、ということに注意しなければなりせん。
投票をお願いいたします