« 2007年07月 | メイン | 2007年09月 »
2007年08月31日
しおりと目次の作成ツール「アウトライナー2」予告
アンテナハウスでは、昨年末より発売しました、しおりと目次の作成ツール「アウトライナー」のバージョンアップ版「アウトライナー2」を10月中旬に出荷開始します。
9月1日以降に、現行の「アウトライナー」をお求めいただいた方は、「アウトライナー2」に無償でバージョンアップいたします。
「アウトライナー」は、現在、16,800円（税込）ですが、「アウトライナー2」は、29,400円（税込）に価格を改訂させていただきます。このため、9月1日からの無償バージョンアップ期間にお求めいただきますと、大変、お買得となっています。ぜひ、この機会に「アウトライナー」をご検討くださいますよう、お願いします。
■しおりと目次の作成ツール「アウトライナー2」新登場！
店頭販売開始予定：2007年10月13日
標準価格：29,400円（税込）
■「アウトライナー2」の主な新機能
・外部のPDFのページを取り込む機能を搭載。
・PDF中の既存の目次からしおりを自動作成できます。
・XML（UTF-8）によるしおり情報の書き出し／読み込みに対応。
・Windows Vista対応、PDF1.7のサポートなど。
・GUIによる対話形式とは別に、コマンドラインでPDFにしおりを作成する機能が付きました。
■「アウトライナー2」無償バージョンアップキャンペーン
9月以降「アウトライナー」をご購入の皆様に「アウトライナー2」への
バージョンアップを無償提供。
下記のキャンペーン購入FAX用紙なら今すぐお求めいただけます。
こちらから → http://www.antenna.co.jp/mpd/campaign/senkou-next.pdf
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月30日
9月7日のX-over Dev Con の準備中です
9月7日のX-over Development Conferenceの配布原稿締め切りがいよいよ本日（8月30日）となりました。
原稿は80%位できているのですが、今日中に仕上げて提出します。
それにしても気になりますのが、どの位、お客さんに集まっていただけるかです。なにしろ、「サーバサイドで高品質な組版とぺージ処理を実現する」というような硬いタイトルをつけてしまいましたので。
印刷業界の人を除きますと、組版という言葉は知らない人が多いのではないでしょうか。
Webブラウザの汚いプリント、それはIE7.0になってだいぶよくなりましたが、まだ、旧来の印刷物と比べればだいぶ品質が落ちます。そういう汚いプリントから、品質の良いプリントへとレベルを上げるには、組版の技術を、Webシステムへ取り込んでいくことが大変重要ではないかと思います。
サーバサイドで、綺麗な、高品質な組版をつかって、PDFで印刷レベルの配布物を作るということの重要さ、そして、XSL-FOならそれができることを、たった40分間ですが、できるだけお話したいと思っています。
入場は無料ですし、こんな良い機会はありません。
ぜひ、お立ち寄りになってみてください。
9月7日（金曜日） 11:00～11:40 B-2会場です。
参加お申込みはこちらです。
http://ac.nikkeibp.co.jp/cn/xdev/
どうぞ、よろしくお願いします。
ところで、時々、組版を表わすもう少し分かりやすい言葉があると良いと思いいろいろ考えることがあります。組版と同じような意味で、時々、ページアップという言葉を使っている文書を見かけることもあります。
しかし、組版とページアップは、印刷では、別の処理を表わす言葉として使われているようです。綺麗な組版とは言いますが、綺麗なページアップとは言わないような。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月29日
実践PDF/A (3)
今日は、昨日作成したPDF/A-1aを、XSL Formatterで直接作成してみます。XSL Formatterでは、タグ付きPDFやPDF/Aの出力機能があります。
タグ付きPDFのタグの方は、Formatterの組版結果からPDFを出力する際に、XSL-FOの構造をもとにしてPDFにタグを自動的に埋め込みます。FOの要素とタグの対応関係については、
http://www.antenna.co.jp/XSL-FO/V4/pdf.htm
の「タグ付きPDF」の項をご覧ください。
さて、昨日使用したグラフィックス・ファイルはCMYKカラーで表現されています。PDF/Aでは、CMYKカラーを使う場合、OutputIntent辞書に、Sキーの値としてGTS_PDFA1、DestOutputProfileキーの値としてICCプロフィールのストリームをもつ必要があります。
このためまずICCプロフィールのデータを用意しなければなりません。AdobeのWebページで基本的なICCプロフィールのデータ・セットが配布されています。
http://www.adobe.com/support/downloads/detail.jsp?ftpID=3145
とりあえずデータ・セットをダウンロードします。このカラープロフィールのセットには、CMYKとRGBのカラープロフィールが幾つか入っていますが、その中から、昨日使ったのと同じ、JapanColor2001Coated.iccを選択してインストールします。（ファイル名の上で右クリックして、インストールを実行します。）
そうしますと、このカラープロフィールが、Windowのシステムフォルダにインストールされます。私のWindowsXPの場合は、ここにインストールされます。
C:\WINDOWS\system32\spool\drivers\color
XSL-FOでは、カラープロフィール関係の情報をfo:declarationsの子供として指定します。
次のようになります。
<fo:declarations>
<fo:color-profile
src="url(file:///C:/WINDOWS/system32/spool/drivers/color/JapanColor2001Coated.icc)"
color-profile-name="#CMYK"
/>
</fo:declarations>
※全体のXSL-FOはここにアップしました。
ファイルをダウンロード
Formatterで上記のFOを組版し、PDF出力設定でPDF/A-1aを指定します。
PDFを出力します。
出力したPDF：ファイルをダウンロード
これをAcrobatでPDF/A-1aに適合しているかどうかチェックしますと、次のようなそっけないメッセージですが、OKです。
PDF/Aでは、このようにPDF内に出力インテントとしてカラープロフィールデータを埋め込む必要があります。
ここでは、多少厄介ですが、XSL-FOでカラープロフィールデータのありかを指定し、それをXSL Formatter4.2を使ってPDFにすることで、PDF/Aを正しく作成できることを示しました。
なお、Adobeが配布している上記カラープロフィールのデータセットのライセンス文書には次のように書いてあります。
Adobe also grants you the rights to distribute the Software only (a) as embedded within digital image files and (b) on a standalone basis （Software とはICCカラープロフィールデータ）
ということで、このカラープロフィールをPDFの中に埋め込んで配布することは問題ないと思われます。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月28日
実践PDF/A (2)
昨日は、簡単な画像の入ったPDFでさえも、PDF/Aに変換できませんでしたが、その原因を調べてみましょう。
昨日は2つのファイルを変換しようとしましたが、まず、簡単なものから。
2つ目のファイル（PDFStamp.pdf）をPDF/A-1aに変換しようとして失敗しました。その時、報告されたエラーは次の2つです。
(1) DeviceRGBを使用
(2) MarkInfoがない
このうち、(2)のMarkInfoはMarkInformation辞書を示すようです。
MarkInformation辞書というのは、タグ付きPDFであることを示す辞書です。PDFのドキュメント・カタログ辞書（最上位の辞書）にタグ付きPDFかどうかを示すオプションのキーMarkinfo（辞書）があり、その内容でタグ付きPDFを示すものです。
PDF/A-1aに準拠するためには、タグ付きPDFでなければなりません。タグ付きPDFでは、Markinfo辞書があり、その唯一のエントリMarkedは、trueでなければならないとされています。MarkInfoがないというレポートはタグ付きPDFなければならないという要求に違反しているエラーです。
次の、 DeviceRGBを使用というエラーは、PDF/Aに変換するとき、出力インテントとして「Japan Color Coated」を選択したのがどうもまずかったようです。Japan Color Coatedは、印刷用なのでCMYKカラースペースなのですが、もとの画像がRGBのため、PDF/Aでは、DeviceRGBとDeviceCMYKを両方使うことができない、というエラーに引っかかってしまったのでしょう。
そこで、今度は、PDF/A-1b形式で、出力インテントとしてｓRGBを選択して変換してみました。そうしましたら無事変換が成功しました。
次のレポートをご覧ください。
さて、次にXSL FormatterでCMYKカラーのグラフィックスをもつタグ付きPDFを作ってみました。
ファイルをダウンロード
文書のプロパティを見ますと、次の図のようにタグ付きPDFになっています。
このPDFファイルは、PDF/Aではありませんので、AcrobatでPDF/A-1aかどうかをチェックすると次のようにエラーになります。
このPDFファイルは、Japan Color Coatedの出力インテントをもつPDF/A-1aに変換することができます。
PDFファイル：ファイルをダウンロード
このことからも次のことを確かめることができます。
(1) 通常のPDFをPDF/A-1aに変換するには、そのPDFがタグ付きPDFでなければならない。
タグ付きPDFでないならば、PDF/A-1bにしか変換できない。
つまりAcrobatでタグを自動的に付けることができない。
(2) RGBカラーのグラフィックスを含むPDFはsRGB、CMYKカラーを含むPDFは、Japan Color CoatedのようなCMYK系の出力インテントをもつPDF/Aに変換できる。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月27日
実践PDF/A
PDF/Aについて、以前に、仕様の面から解説しました。
2007年07月23日 PDFと長期署名(3) — PDF/A 仕様 ～2007年07月31日 PDFと長期署名(10) — PDF/A 仕様 8 タグ付きPDF
そこで、今回は、実践的に、つまり少し実際にPDF/Aを作ることを通じて試してみたいと思います。
Acrobat7Professionalでは、PDF/Aのドラフト（仕様案）を使えましたが、最新のAcrobat8.1Professionalでは、PDF/A仕様をサポートしており、PDF/Aを実際に体験できます。弊社のXSL Formatter 4.2でもPDF/Aを作成することができます。
そこで、主にこの二つの製品を使ってPDF/Aを体験してみることにします。他にも、PDF/Aをサポートする製品が増えてきているようですので、随時、試してみましょう。
１．PDF/Aを作る
・PDF/Aを作るには、XSL FormatterV4.2のようなツールでPDF/Aをゼロから生成する方法があります。類似の方法としては、PDFLibも7.0からPDF/Aの作成をサポートしています。PDF/Aが生成できるようになったのは比較的最近ということができます。
２．PDFをPDF/Aに変換する
任意のPDFをPDF/Aに自動変換できるなら簡単な話です。そこで、まず、これを試してみました。
Webでも公開していますが、「PDF活用のための基礎知識」をAcrobat 8.1 ProfessionalでPDF-1aに変換してみます。
(1)テストデータ１
オリジナル・ファイル：PDF活用のための基礎知識 (PDFファイル)
http://www.antenna.co.jp/PDF/reference/Seminar-20070702.pdf
このPDFには、フォントを埋め込んで作成してあり、かなり簡単な内容です。
これをPDF-1aに変換して、そのレポートをPDF化したのがこちらです。
このレポートを見ますと、代替画像を削除したり、禁止されているLZW圧縮をZIPに再圧縮したりと言った、自動的にできることはやっているようですが、DeviceRBGを使用、MarkInfoがない、Type2CIDフォントに無効なCIDtoGIDMapがある、などの多数のエラーが出てしまい結局変換は成功していません。
(2)画像だけのPDF
もう少し簡単な画像だけのPDFファイルではどうでしょうか？
オリジナルPDF：
ファイルをダウンロード
これをPDF/A-1aに変換してみました。やはり、うまくいきません。
レポートPDF：
ファイルをダウンロード
このPDFファイルは、文字がありませんので、フォントのエラーは出ませんが、画像がエラーになってしまいます。また、MarkInfoがない、というエラーになります。
これを見ただけでも、PDF/Aを作るのは結構面倒そうなことが分かります。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月26日
ECOM JIS原案「PDF/Aへの長期署名の適用方法」まとめ
ECOM JIS原案「PDF/Aへの長期署名の適用方法」批判について、過去3回の記述を整理しました。
以下のリンクを辿っていただくことでご覧頂くことができます。
http://www.antenna.co.jp/PDF/reference/PDF-DS-Long.htm
最後の方にも書きましたが、現時点でPDFの長期署名仕様はまだ標準化の段階になっておらず、採用は時期的に早すぎると考えられます。
商売の上では、早いものがちとも言えますが、すくなくとも、「PDF/Aへの長期署名の適用方法」はあまりにも拙劣です。この仕様を実装すれば、実装したツールでしか、検証できず、相互運用できないものになります。
また、仮にECOMに賛同する数社が実装したとしても、PDF標準と非互換なPDF署名ができてしまうことになるため、採用したユーザにも迷惑をかける可能性があります。
JIS原案「PDF/Aへの長期署名の適用方法」にわざわざ参考資料として掲載した意図は、恐らく他者を出し抜いて、商売の利得を得ようということだろうと思いますが、それにしてももう少し勉強するべきです。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月25日
PDF/A の次期バージョンについて
PDF/Aの次のバージョンに関する国際会議は8月28日から29日にベルリン（独）で開催されます。米国、日本、スイス、英国などの代表者が参加しての会議が予定されています。
PDF/Aの次期バージョンは、当初、PDF 1.6をベースに作成されることになっていましたが、PDF 1.7をべースにしたものになり、新しい機能がいろいろ追加されることになっています。
PDF/Aの次のバージョンは、USの代表によれば、次の３つのパートにしたいようです。
パート1、パート2は、コンテンツの内容が変化しない静的なもの。そして、パート3は、ドロップ・ダウン情報をもつフォームのようなダイナミックな文書の保管を可能にする。
今回の国際会議での目標は、全メンバー国の合意を得るための委員会の投票を行うことを参加者に合意を取ることにあります（以上は、米国発の情報）。
出展：August 21, 2007 PDF/Archive to meet in Berlin
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月24日
XPSアプリケーション
MicrosoftのXPSのアプリケーションリストを見ますと、XPSをサポートするアプリケーションが徐々に増えています。
http://www.microsoft.com/whdc/xps/showcase.mspx
１．Adlib Software社のExpress Server
2007年7月3日XSPサポートの告知。
・XPSの生成、XPSからの変換。
・XPSの合成など
２．Cerenade社のVisual eForms Enterprise Server
・記入済み帳票をXPSに印刷可能
３．Directors Desk XPS Edition
・役員のためのコミュニケーション、コラボレーション・ツール
４．FinerEdge Publisher
2007年4月10日 XPSサポートを告知
・パーソナライズした製品カタログ、レポート、契約書などの組版ソフト
・XPS, PDF, PostScript, XHTML, RTFを出力
５．Informative Graphics社
・Brava！, MYRIADでXPSの表示をサポート
・Redact-ITでXPSの生成
６．Knowledge Lake
2007年3月
・多機能機、Fax、その他の文書保管機から文書をキャプチャして、XPSに変換。SharepointServerに蓄積
７．MadCapSofteare
2007年3月リリース
・Blaze/Flareでサポート
８．NiXPS
・XPSの合成、抽出などの操作ツール
９．PDFTron社のPDF2XPS
・PDFをXPSに変換する
■XPSのメリット
・XPSはPDFよりも取り扱いしやすい。
・WindowsVistaでは、XPSを生成、表示可能。
・Windows XPでは、.NETFramework 3.0またはXPS基本パックをインストールすれば、XPSの生成と表示が可能となる。
確かにPDFよりXPSの方が取り扱いは楽かもしれない。アプリケーションが増えてくるとPDFの強敵になる可能性ありです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月23日
DITA Open Tool Kit 1.4 未完成
先日、2007年08月16日 DITA、初のバージョンアップでV1.1となるで、DITAのOpen Tool Kitが、1.4になったことを紹介しました。これについて、もう少し調べてみましたので、情報を補足します。
DITAのOpen Tool KitはSourceForgeでオープンソースとして公開されています。
http://sourceforge.net/project/showfiles.php?group_id=132728
DITAをXSL-FOに変換（最終的アウトプットはPDFを想定)するツールキットは、べースはIBMが作ったものです。XSL-FOプロセサはFOP用を想定しています。現在、V1.4になっているのはこれです。
さらに、XSL-FOプロセサとしてXEPを想定するプラグイン
Plug-in: FO FO-1.2.1 November 8, 2006
があります。これはカナダのIDIOMが開発・寄贈したオープンソースです。前述のIBMのTool Kitへのプラグインとして機能拡張を提供しています。SorceForgeを見ますと、こちらの方は、まだ、1.2.1版で1.4にアップデートされていません。
[dita-users] Digest Number 1509
* A new version of the FO plugin developed by Idiom will be posted soon, with support for the new bookmap standard from DITA 1.1.
ということなので、いま、開発中なのでしょう。
アンテナハウスでは、この両方をXSL Formatterで使えるように変更したTool KITを提供しています。
IDIOM製はまだ改訂されていない、ということで、IBM製を調べてみました。
DITA Open Tool Kit 1.4をダウンロードして評価しました。一番簡単なデモプロジェクトは通り、FOPでもXSL FormatterでもPDFが作成できます。
しかし、language referenceのような本格的な文書を、ditamapから処理しようとすると、
[xslt] [DOTX031E][ERROR]: The file file://sthead.dita is not available to resolve link information. Either the file could not be found, or a DITAVAL file was used to remove the file's contents. Be aware that the path information above may not match the link in your topic. Check to make sure thefile exists and DITAVAL file isn't used to remove the contents of the file.
[xslt]
[xslt] : Warning! Failure reading file://sthead.dita Cause:
java.io.EOFExce
ption: no more input
[xslt] : Warning! Failure reading file://sthead.dita Cause:
java.io.EOFExce
ption: no more input
[xslt] : Warning! Failure reading file://sthead.dita Cause:
java.io.EOFExce
ption: no more input
[xslt] : Warning! Failure reading file://sthead.dita Cause:
java.io.EOFExce
ption: no more input
[xslt] : Warning! Failure reading file://sthead.dita Cause:
java.io.EOFExce
ption: no more input
[xslt] : Warning! Failure reading file://strow.dita Cause:
java.io.EOFExcep
tion: no more input
のエラーが全モジュールにつき山ほど出て処理がまったく出来ず、FOを作るところまでたどり着きません。
DITA1.4\tempにはstrow.ditaが出来ているので、このメッセージ（"file://strow.dita"から判断するに、Open Tool Kitのモジュールからのフォルダの参照の仕方が誤っているようです。
簡単なデモは動いているのでたぶんDITA OT 1.4のバグだと思います。
SourceForgeにバグ報告をしましたところ、下記の回答が出ています。
This is an error caused by incorrect langref packed in the toolkit.
currently the reference files hasn't been updated to DITA 1.1 standard.
だそうで、まだ、ToolKit 1.4 は未完成ですね。ニュースにあわてて飛びついた私が馬鹿だったようです。
ところで、DITAユーザズを見ていましたら、XSL-FOの推進者かつXSL Formatterの熱烈ファンのはずの、Eliot Kimberさんが、転職して、どうもInDesignの推進者に転向したようです。
Eliot Kimberさんの転職はニュース・リリースが出ています。
Really Strategies Hires Eliot Kimber to Support DITA and Other XML Services for Publishers
http://www.reallysi.com/pr_073007.htm
DITAユーザズでは、
From: "Eliot Kimber"
To: dita-users@yahoogroups.com
Date: Thu, 16 Aug 2007 08:24:21 -0400
Subject: [dita-users] DITA and InDesign
あたりをご覧ください。DITAとInDesignを研究しているようです。それにしても、XSL-FOからInDesignに宗旨替えするとは、ピューリタンからカトリックになったようなものじゃないですか。
Kimberさんのことは、このブログで先日ご紹介しました。
2006年02月12日 もっともsuckでないソフト
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月22日
PDFと長期署名(15) — ECOM JIS原案「PDF/Aへの長期署名の適用方法」は採用できない
PDFへの長期署名の仕様として、ECOMのJIS原案に参考資料として「PDF/Aへの長期署名の適用方法」という仕様案が出ています。それについて2回に渡り批判しました。
・2007年08月01日 PDFと長期署名(11) — ECOM提案のPDF/A長期署名
・2007年08月06日 PDFと長期署名(12) — ECOM提案のPDF/A長期署名を再び批判する
仮に参考資料としても、このような根本的に間違った仕様がJISの規格書に盛り込まれると、将来、大変困ることになると思います。
アンテナハウスPDFは、PDF Reference、さらに将来のISO標準PDFを可能な限り正しく実装しようと心がけています。もし、独自拡張するとしても、その場合の方針は、仕様としてあるものはそれを忠実に実装し、ないものだけを拡張するということになります。
ところが、ECOMのJIS原案のPDF長期署名仕様はPDF ReferenceとPDF/Aで決まっている項目について、それが、意図的か、あるいは、理解不足かはともかくとして、それを無視・違反した上で、自分達の都合の良い独自拡張をしています。この考え方では、標準である部分についても、互換性がなく、相互運用できないPDFが出来上がってしまうことになります。
なぜ、こんな発想が出てくるのか疑問に思い、ECOMの前年度の報告書を見ましたところ、彼らの誤れる発想の原点が少し見えました。
前年度の「長期署名フォーマット相互運用実験報告書」（平成18年3月）次世代電子商取引推進協議会発行資料のPP.45～49まで、PDF/A文書に対する長期署名の標準化という項があり、そこで予備的な検討が行われています。その中に次のような部分があります。
PDF/AのベースになっているPDF Reference1.4では電子署名についての仕様は簡単な記述になっています。
ちなみに、その時点では、PDFの電子署名は別文書「PDF Public-Key Digital Signature and Encryption Specification Version 3.2（Jim Pravetz 著）」で記述されていました。その後、この別文書の内容がPDF Reference本体に吸収されたようです。
※上記の文書は、どうも既にWebからなくなってしまっているようで、内容は私には確認できていませんので推測です。
その結果、ECOM的PDF長期署名にとっては都合の悪い記述がPDF Reference1.6に盛り込まれてしまいました。
すなわち、PDF 1.4では、署名辞書の署名ハンドラの名前（Filterキーの値）、署名の符号化方法を示す名前（SubFilterキーの値）、署名値（Contentsキーの値）について、簡単な記述しかなかったので、長期署名の形式をPDFの署名辞書に定義可能でした。
ところが、PDF 1.6でこれらの記述が詳しくなりました。具体的には、
(1) SubFilterキーの値の部分に次のパラグラフが追加されました。
Defined values for public-key cryptographic signatures are adbe.x509.rsa_sha1, adbe.pkcs7.detached, and adbe.pkcs7.sha1 (see Section 8.7.2, “Signature Interoperability”).
(2) Contentsキーの値の部分に次のパラグラフが追加されました。
For public-key signatures, Contents is commonly either a DER-encoded PKCS#1 binary data object or a DER-encoded PKCS#7 binary data object.
このふたつのパラグラフが追加されたために、長期署名の形式を表すキーの値を定義できなくなってしまったのです。「長期署名フォーマット相互運用実験報告書」の筆者は、この対策として、このインターフェイスの阻害要因である、上の二つの段落を削除する、ということを提案しています。
Adobeが作った標準仕様であるPDF Referenceを利用しておきながら、自分達に都合の悪い段落を削除し、都合の良い項目を追加する、という発想方法は、標準を認めない、ということに繋がります。その結果できるものは標準とは名ばかりで、実態は非互換の独自PDFです。
ところで、PDF 1.7で、SubFilterの項にはさらに次の一文が追加になりました。
Other values can be defined by third party developers, subject to the restriction that all names beginning with the adbe. prefix be reserved for future versions of PDF. All third party names must be registered with Adobe Systems.
これで、サードパーティが他の値を定義しても良くなり、独自拡張可能になりましたので、削除しなくても問題なくなりました。PDF 1.7のように記述を追加して拡張可能にする、というのが正当な方法でしょう。
さて、3回にわたり、ECOMのJIS原案に掲載されている「PDF/Aへの長期署名の適用方法」について検討しましたが、その目的のひとつは、アンテナハウスPDFでこれを採用するかどうかを判断することがあります。結論は、既に明らかなように、アンテナハウスPDFにはこの仕様案は採用できないです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月21日
ラオックス、ザ・コン館を9月30日に閉店
もう古いニュースですが、ラオックスのザ・コンピュータ館（ザ・コン館）が9月末で閉店になります。
ニュース・リリース
http://www.laox.co.jp/laox/press2007/070803_3.pdf
たまたま、1昨日日曜日、秋葉原に行く用事がありましたので、ラオックスのザ・コン館に立ち寄り、本を一冊買って来ました。
5階のPCフロアに立ち寄りましたが、もう品揃えがかなり減っていてとても寂しくなっています。
ザ・コン館ができたのは、1990年4月と言いますから、もう17年以上前。ラオックスの旗艦店として絶大な人気を集めたと言われていますが、私なども秋葉原でPC関連の買い物をするときは、ほとんど、ザ・コン館でした。
開館の当初は、ザ・コン館に行けば、すべてのPCソフトが揃っているということがセールス・トークだったように記憶しています。その頃は、マイナーな製品でもそこにいけば大抵在庫がある、というのは大きな魅力でした。
弊社のようなマイナーな会社ではソフト販売面でも、随分、お世話になっています。
しかし、例えば、最近のザ・コン館の売上ベスト・テンを見ますと次のようになっています。
-----------------
2007年6月1日～22日
1．ソースネクスト ウイルスセキュリティZERO新パッケージ版
2．トレンドマイクロ ウイルスバスター2007トレンドフレックスセキュリティVista優待1年版
3．シマンテック NortonInternetSecurity2007VISTA対応標準版
4．シマンテック NORTON360
5．シマンテック Norton AntiVirus 2007 VISTA対応 特別優待版
6．ソースネクスト ウイルスセキュリティZERO2台用新パッケージ版
7．トレンドマイクロ ウイルスバスター2007トレンドフレックスセキュリティVista更新
8．イーフロンティア ウイルスキラーゼロ
9．トレンドマイクロ ウイルスバスター2007トレンドフレックスセキュリティVista優待2年版
10．ソースネクスト ホームページビルダー11通常版ガイドブック付半額キャンペーン
-----------------
なんと、10位のホームページ・ビルダー以外は、全部、セキュリティ・ソフトです。これは一体どういうことなのでしょう？こんなにセキュリティ・ソフトに集中してしまうのはあまり健全な印象を受けません。詳しい事情は分かりませんが、しかし、昔のような品揃え・種類の多様さで勝負というのは通用しなくなっているのではないかと思います。
すなわち、リアルな店舗はスペースあたりコストが高いですから、品揃えを抱負にするという点では、アマゾンのようなネット上の店舗と比べると不利なことは明らかです。結局、リアル店舗は売れ筋集中で効率を上げないと、ネット店舗と勝負できないのではないでしょうか。そう考えますと、品揃えを誇ったザ・コン館の凋落と閉店は、ネット時代がもたらしたものと言えそうです。
それに関連して感じましたのが、最近手にした日経パソコンの薄さです。8月13日お盆前の号とは言え、140ページしかありません。広告主は10社のみ。これで経営が成り立つのでしょうか？IT雑誌の場合もやはり、ネット上の情報との競争となります。
そんなわけで、ザ・コン館の閉店も日経パソコンのページの薄さも両方ともネット時代がもたらしたものと改めて時代の変化を感じました。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月20日
Microsoft Open XML Formatをサポートするソフト
Microsoft のOffice 2007のXML文書形式であるOpen XML Formatをサポートするソフトウエアのリストが下記にあります。
iWork ‘08 supports the Open XML formats
http://blogs.msdn.com/brian_jones/default.aspx
・iPhone
・iWork
・Officeの旧バージョン
・OpenOffice.org
・WordPerfect
・PalmOS
・NeoOffice
・MindMapping
・OpenXML Writer
など、全部で16製品が掲載されています。
Microsoft Office 2007が発売されてもうかなりの時間が経過していますので、もっと他にもあると思いますけれども。
ちなみに、アンテナハウスでは、TextPorter V4.2は、既に、Open XML formatのテキスト抽出をサポートしています。残念ながら、テキスト抽出のみです。
また、Microsoft Office互換のレンダリング・ソフトServer Based Converterや自在眼は、次のバージョンで、Open XML形式をサポートする予定です。現在、開発中ですので、しばらくお待ちください。
ところで、iWork'08というのはMac用の統合オフィスソフトなんですね。知りませんでした。iWork'08は、8月7日に発売されたばかりです。
・Pages'08：編集ソフト
・Keynote'08：プレゼンテーションソフト
・Numbers'08：表計算
という3種のソフトのパッケージで、US$79.00（日本では9,800円）です。これまでは、編集ソフトとプレゼンテーションソフトのみでしたが、今回('08)から表計算が追加になりました。iWork'08ではPDFの出力も可能です。オフィス・ソフトにはPDF出力が標準になるのでしょう。
Macは、Intel アーキテクチャに移行していますが、インテルMac版のMicrosoft Office 2008のリリースは、2007年後半の予定が、2008年に遅延するとのことです。
Office 2008 Coming January 2008（Office for Macチームのブログ）
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月19日
Acrobat8 半透明がPDF表示に与える影響
PDFに半透明の画像や透かしをつけると、本文の文字が太く表示されたり、カラーがくすんだりします。
この問題はAcrobat7/8（だけかどうか定かではありませんが）の表示の問題ですが、弊社の製品サポートによく質問が寄せられます。先週は1週間で2回もその手の問題がサポートに報告されました。
XSL FormatterでPDFを作成している客先から、PDFをAdobe Readerで表示すると、一部のページの文字が濃く表示されるというクレームがありました。これは、そのページにαプレーン(透明）がついたPNGがあるため、そのページの文字が他のページの文字よりも濃く表示されてしまいます。同じ現象をAcrobatで半透明の透かしを埋め込むことでも再現させることができます。
下の画像をご覧ください。これはPDFのページに「Acrobatで不透明度50%の透かしをつけたページ」と「すかしのないページ」をAcrobat8で表示して比較したものです。
オリジナルPDFはこちらです：PDFファイルをダウンロード
文字が太くなるだけではありません。
半透明の透かしを付けると、カラーもくすんでしまいます。
カラーの場合は、色にもよりますが、かなり激しくくすんでしまう色があります。下記の図をご覧ください。これは、1ページ目は透かしなし、2ページ目は1ページ目に不透明度50%の透かしを付加したものです。透かしの付加処理は、Acrobat 8.1 Professionalで行ったものです。わざとかなりくすみの激しい色を選んでみました。
オリジナルPDFはこちらです：PDFファイルをダウンロード
そんなわけで、半透明の色が付加されますとAcrobat8の表示が影響を受けてしまうのは、弊社の製品の問題ではなく、Adobeの責任なのです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (1) | トラックバック
2007年08月18日
広告配信モデルの無償ソフトの将来は？
最近、広告収入を当て込んで、無償でソフトを配布する動きが幾つか見られるようになっています。
第1は、キングソフトの「Kingsoft Internet Security free」 7月19日から無償でのダウンロードを開始しています。セキュリティ業界初の触れ込みですが、キングソフトが現在販売している有料のプログラムと全く同じ品質でありながら、ユーザーにかかるコストは0という業界初の広告モデルとされています。セキュリティソフトの場合、ウイルスのパターンデータを更新するのですが、その更新のタイミングで広告を配信する、とのことで、オーバチュアやアフィリエイト広告パートナーと提携して、広告収入を当て込んでいます。
広告収入を増やすには、ダウンロード数が増えて、広告媒体価値が高くなることが、前提条件になります。無償ダウンロードを初めて約1ヶ月ですが、どの位のダウンロードがあったのでしょうか？
その第2は、クセロが最近配布を始めた「クセロReaderZERO」。これは、PDFのビューア・ソフトですが、1週間ほど前から無償ダウンロードで配布を始めました。触れ込みでは、年間200万ダウンロードを目指すとか。
クセロ社のニュース・リリース自体には、広告を収入源とするとは一言も書いてありません。ネット上のニュースを見ても、無償配布のことしか書いてありません。しかし、日経産業新聞の8月16日の記事によりますと、「ファイルの起動時に別画面で広告を表示。広告収入を得ることで利用者への無償提供を可能にした。年間3億円の売上を目指す。」とあります。
日経産業新聞の記事には次のような図までついています。ということはクセロの森社長が、日経の記者だけに計画を話したのでしょうか？
しかし、クセロのWebページを見ても、掲載を期待する広告主や製品は何かなど何も出ていません。（本当に広告ビジネス・モデルを考えているのでしょうかねえ。）
いづれにせよ、パッケージソフト・ビジネスを広告配信収入で維持できるものなのかどうか？この二つのビジネスの今後の展開がどうなるか。まずは、興味深々といったところです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月17日
PDFと長期署名(14) — 長期署名は記録保存モデル
前回は、電子証明書が失効したり有効期間を過ぎてしまうような長期にわたって電子署名の有効性をたもつことが必要になることがあり、そのような事情には署名時点での信頼性を保全するA型、と現時点での信頼性の確認を必要とするB型の2つの立場があるとお話しました。
2007年08月14日 PDFと長期署名(13) — 長期署名はどうあるべきか
このように分けますと、現在の長期署名の多くは、A型の要求に基づくものになっているようです。これは、長期署名が必要とされる動機として、裁判などの証拠性を高める、あるいは、行政からの要求による証拠の保全などに基づくものだからでしょう。
ECOMの「電子署名長期保存に関するガイドライン」（平成14年3月）には、次のような定義があります。
「本ガイドラインでは、長期に渡り、デジタル署名の有効性を再確認することを可能とすることにより、デジタル署名の有効性を保証するモデルを検討し、デジタル署名の有効性を維持することを、以下のような事象が発生しても過去に有効性を検証したデジタル署名の再検証を行うことにより、デジタル署名の有効性を確認可能としておくことと定義する。
・公開鍵証明書の有効期限を過ぎた
・公開鍵証明書が失効された
・暗号アルゴリズムが脆弱化した」
（pp.10～11）
ECOM推奨長期署名形式であるCAdES/XAｄESも、記録文書に署名を付与し、その署名の検証に成功したら、そのときの情報をカプセルに封印して保全する技術といえると思います。
一方において、B型の例として、有価証券類への署名を考えますと、このような証拠の保全としての長期署名では、その要求を満たすことができないのではないかと思います。有価証券類への署名は、それを評価・検証する時点において信頼できるものと判断できなければ、その有価証券類の取引は成立しないと考えられるからです。有価証券類に限らず、その時点の価値に基づいて取引されるような証書に署名をつけるとすると、その署名の信頼性は、検証する時点の実在環境で確立させる必要があると思われます。このような有価証券型の長期署名モデルも、検討の価値があると思われます。しかし、この論点は少ないようです。
なぜ、このような話を持ち出したかと言いますと、私には、PDFの電子署名の基本的な考え方は、カプセルに封印して保全する型の長期署名とはかなり異なっているように思われるからです。PDFの電子署名モデルは、文書を変化するものとして捉えています。PDFの電子署名は、いわば、変化する文書のスナップショット・モデルです。
前回、最初にPDFの長期署名がどうあるべきかを考えるのは難しいと申し上げましたが、これは、ECOMなどで議論しているA型長期署名形式であるCAdES/XAdESと、PDFの電子署名仕様は、どうも基本の考え方が違うという印象があるからです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月16日
DITA、初のバージョンアップでV1.1となる
OASISは、DITA（Darwin Information Typing Architecture）V1.1が標準として承認されたと発表しました。
DITAが、最初にOASISの標準として承認されたのは2005年6月です。そのとき以来、欧米でのDITAへの関心の高まりは、燎原の火のごとくに広がっています。このことは、以前、このブログでも紹介しました。
第312話 2006年08月24日 DITA への関心が急激に高まっています
V1.0承認から約2年でV1.1にバージョンアップしたことになります。
新しいバージョンでは、see、see-alsoなどの参照用の新しい要素が追加になって、索引機能が協力になりました。
また、多言語によるコンテンツ配布の機能が強化されているようです。DITAのトピックを翻訳して、言語指定のDITA Mapを使って、簡単に言語単位で組み立てることができます。これによって、多言語（ローカリぜーション）サービスでの有効活用がし易くなりました。
また、OASIS DITA 翻訳小委員会というのができて、次の分野での実践的活用法を準備しています。
- 多言語での索引
- 既存の翻訳メモリをDITAに移す手段
- 翻訳された文章で、conrefを取り扱う方法
- 多言語の文書を管理する
こうしてみますと、DITAを多言語、翻訳に活用しようと言う動きが強化されているようです。
また、DITAのOpen Tool KitはV1.4になりました。
ところで、前回に続いて、YahooのDITAユーザ・グループの月別メール数（発言数）をカウントしてみました。
次の図のように、まだ趨勢としては、DITAへの発言は増えていると言えそうです。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月15日
藤島雅宏の「バッチ組版のためのXSL-FO指南」を発売！
アンテナハウスの関連会社である株式会社エクスイズムでは、XSL1.1勧告で更に進化したXSLFO仕様をプロの立場で纏めたバッチ組版のための「XSL-FO指南書」の販売を開始しました。
イーエイド元代表・藤島雅宏氏が執筆した電子書籍で、アンテナハウスでも編集に協力しています。
イーエイドのホームページ：
http://www.eaid.jp/index.html
ご希望の方は、下記のエクスエイズムのWebページからお申し込みいただければ、「XSL-FO指南書」見本版を入手できます。
ご希望の方
http://www.exism.co.jp/contact/form/forminq.html
XSL-FOは、非常に強力な日本語組版の機能をもっており、DTPで作成するようなページをバッチ処理、オンライン処理で制作することができます。
内容の詳細はこちらをご覧ください。
バッチ組版のための [XSL-FO指南書」 藤島雅宏 編著
印刷業界では、最近、InDesignで自動組版という動きも多くなってきているようですが、InDesignとXSL Formatterではその自動組版の生産性には大きな開きがあります。
しかし、残念ながら、XSL-FOでどのようなページレイアウトが可能かについて、十分に説明した本は、日本のみならず、海外まで通じても数少ないのが実状です。
藤島氏は、XSL-FOのJISTR版の翻訳に携わっておられますので、XSL-FOについては非常に詳しい知識をお持ちですし、元写研のキャリアからもお分かりになりますように、日本語組版についても長い経験をお持ちです。
そういった知識、経験、熱意をもって作成されたのが、この「XSL-FO指南書」です。
ぜひ、ご活用くださいますよう、お勧めします。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月14日
PDFと長期署名(13) — 長期署名はどうあるべきか
さて、次にPDFへの長期署名をどのようにすべきか、ということを考えてみたいと思います。しかし、これは非常に難しい問題です。
電子署名は技術ではなく、社会のシステムであること
なぜかと言いますと、電子署名は技術ではなく、社会的なプロセスだからです。技術という点で言いますと、例えば、RSAの公開鍵暗号アルゴリズムは、既に、特許も失効しているほどの古い技術です。そのアルゴリズムを使う限りでは新しいソフトウエア開発などは必要ありません。電子署名をつけたり、検証するプログラムを開発するには、無論、ノウハウは必要ですが、取り立てて新しいものを研究開発するというものではありません。
難しいのは、電子証明書という”証明書”の存在であり、その証明書を信頼するかどうか、という問題です。これは、社会システム的な、もっと具体的に言えば、例えば、電子帳簿保存法という法律、あるいは、その法律に基づいて業務を執行する国税庁の判断、あるいは、電子署名の証拠性という観点でいえば、裁判所がどのように判断するか、という問題です。
すなわち、電子署名の難しさは、技術面にあるのではなく、社会面にあるのです。電子署名について本当に議論するとするなら、特にメーカの技術者や研究者ではなく、もっと利用者、あるいは、経営者や政治家が議論するのが本筋のように思います。
技術的な観点のみの、すなわち仕様のみの議論ではなかなか良いものは作れないでしょう。もともと曖昧なものを、技術で押さえこもうとしますと、どうしても高度で複雑な要求仕様を出すことになりがちです。しかし、実際に裁判になる可能性が少ないのに、最悪の場合の証拠を用意するために多額のお金をかけてシステムを作るのは無駄でしょう。コスト面から考えますと、必要最小限の仕組みを考えなければなりません。しかし、裁判になったときのことを考えると、技術者の立場から、必要最小限を提案するのは、どうしても難しくなります。
電子署名のしくみであるPKIが導入されたのは、2000年～2001年頃と思いますが、現時点で、一部を除いて、まったく普及していないのは、現在のPKIが技術者と役人が考えた社会システムであって、現実の要求に応えていないということがその理由でしょう。注意しないと長期署名でも同じことを繰り返しそうです。
電子署名の検証者の立場を考える
さて、電子署名では、文書に署名する処理と、その文書の署名を検証する処理が対になっているわけです。署名者が署名したものを、受領者が受け取って直ちに検証して、そこで処理が完了するものであれば、あまり大きな問題はないのですが、署名から検証までの時間が長くなりますと、署名と検証の間に時間が経過して、次のような状況になることがあります。
電子署名を付与したときは、電子証明書の信頼性を確認できた。しかし、検証時には、既に、電子証明書が有効ではなくなっている、または有効性を確認できないことがある。
さらに、それ以外に、アルゴリズムが脆弱化してしまう可能性もあります。
二つの異なる要因を同時に考えるのは、話が複雑になりますので、とりあえずは、証明書問題だけを考えて見ましょう。
電子証明書が、署名時は信頼できると判断できたのですが、検証時に、信頼できない、または、信頼性を判断できないというのは、次のケースがあります。
１．証明書の有効期限が過ぎてしまった。
２．証明書が有効期限が来る前に、失効してしまっている。
３．証明書を発行した機関が信頼できない状態になった、あるいは機関がなくなってしまった。
他に、電子証明書は、本来は有効なのだが、システム上の要因で判断できないことがあるかもしれません。例えば、システムがネットワークに繋がっていないなど。こうした要因を別にして、上の１～３のようなときは、検証者はどう判断すれば良いのでしょうか？
これは、明らかに、文書の内容と検証者の立場によって変わります。
A. 過去に署名された書類のその時点での信憑性を確認するのが目的であれば、署名時点に遡って、署名と証明書の信頼性を確認できれば良いことになります。
B. それに対して、例えば、有価証券、土地や家屋の権利書のような証書であれば、検証する時点で有効でないと意味がないことになります。そうなりますと、長期にわたって、常に現時点で署名が検証できる状態を保たねばなりません。
このAとBでは立場が相当に異なるのではないかと思います。AとBのどちらを目的にするかによって、同じ長期署名でも、要求仕様、さらには、実現する社会システムはまったく別のものとなるでしょう。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月13日
テクニカルコミュニケーションシンポジウム2007に参加します
8月28日～29日（東京会場）に開かれる、テクニカルコミュニケータ協会主催の「テクニカルコミュニケーションシンポジウム2007」での講演と出展いたします。
なお、大阪会場は、10/18です。
◎「テクシカルシンポジウム2007」詳細
http://www.jtca.org/sympo/
弊社では、両会場ともに60分程度の商品説明のセッションを行います。
内容は、「XSLFormatterによるマニュアル作成の紹介」、および「アウトライナー」についての説明を予定しています。
展示会では、「XSLFormatterV4.2」「PDFToolV2」など弊社製品のデモを実際に見ていただけます。
有償のシンポジウムですが、ご来場賜ります様よろしくお願いいたします。
「テクニカルコミュニケーションシンポジウム2007」概要
東京会場
○開 催 日 程 ： 平成19年8月28日（火）、平成19年8月29日（水）
○開 催 場 所 ： 工学院大学（新宿）
地図 http://www.jtca.org/sympo/07sympo/map_t.html
○出展商品 ： XSLFormatterV4.2、PDFTool他
大阪会場
○開 催 日 程 ： 平成19年10月18日（木）
○開 催 場 所 ： 大阪産業創造館
地図 http://www.jtca.org/sympo/07sympo/map_o.html
○出展商品 ： XSLFormatterV4.2、PDFTool他
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月12日
PDFと署名(46) — PDFに署名をするとどういう効果があるか？(2)
さて、次のふたつのスライドは、PDF電子署名独自のものです。
PDFの内容を更新する方法には、内部のオブジェクトを整理し直して保存する（普通の）方法と、増分更新という方法があることを以前にお話しました。
詳しくは、こちらをご覧ください。
2007年06月11日 PDFと署名(39) — PDFの増分更新
2007年06月12日 PDFと署名(40) —PDFの増分更新（続き)
増分更新では、PDFが更新されるとき過去の履歴が全部そのまま残っています。
そして、PDFに一旦電子署名を施すと、その後は、増分更新しなければならない、ということが決まっています。PDFを編集するアプリケーションはそのように作成しなければならないのです。
詳しくはこちらをどうぞ。
2007年08月06日PDFと長期署名(12) — ECOM提案のPDF/A長期署名を再び批判する
ですので、きちんとPDFの仕様に準拠して開発したアプリケーションであればPDFを更新する度に電子署名を施すことによって、その電子署名をした時点のPDFバージョンを復活させることが簡単にでき、電子署名をつかってバージョン管理ができることになります。
これは比較的新しくPDF 1.5から仕様として盛り込まれた機能です。Acrobat8では、「署名を使って証明する」というメニューになっています。
未署名のPDFに最初のひとつめの署名をする場合に限りますが、署名後のPDFへの変更を不許可にしたり、署名のみを許したり、あるいは、注釈と署名のみを許すように設定ができます。
これによって、署名をしたPDFを配布し、その受領者は署名のみをして戻すことができるというようなワークフローを構築することができます。この機能はPDF独自の機能です。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月11日
PDFと署名(45) — PDFに署名をするとどういう効果があるか？(1)
さて、先日の「アンテナハウス PDF 電子署名モジュール V1.0 」の新製品発表会でのスライドを使って、PDFに電子署名をつけるとどんな効果が得られるかをお話してみます。
PDFに電子署名をつけるメリットは、上の5項目に集約できると思います。
1項は、署名の対象になるコンテンツに関する保証で、PDFに限らず電子署名一般にあてはまります。
2項は、電子署名に付随する電子証明書がもたらす効用と言えます。これもPDFに限りません。
3項は、PDF独自のものです。
4項も、PDF独自のものです。
5項は、タイムスタンプの機能であり、PDFに限らず一般的にあてはまります。
このように、PDFへの電子署名はいろいろな要素がもたらす複合的な効果があります。それだけに仕組みを完全に理解しようとするとなかなか難しいことになります。
一般の人は仕組みを知らなくても、簡単に利用できれがそれで良いと思います。
しかし、このブログは、ある程度専門的なことを仕組みまでお話するのが趣旨ですので、もう少し立ち入ってみたいと思います。
これは電子署名の大きな意味そのものです。
PDFと署名(4) — 公開鍵暗号方式を署名に使うあたりでお話しています。
PDFの電子署名では、署名したPDFには署名者の電子証明書が埋め込まれることになっていますので、その電子証明書を手がかりにして、署名者の信頼性を確認できます。
AdobeのAcrobatもそうですが、アンテナハウスのPDF電子署名モジュールも、自己署名証明書を発行することができます。自己署名証明書は、個人が自分で秘密鍵と公開鍵を作成し、公開鍵証明書（電子証明書）を作るものです。PKIの専門家には、あまり評判が良くない（？）自己署名証明書ですが、企業内のようなクローズドな集団内のように電子証明書を確実な信頼性をもって配布する手段があれば、そうやって入手した電子証明書とPDFに埋め込まれている電子証明書を比較してみるなどの方法でPDFに署名した人の信頼性を確認することができます。ですので、自己署名証明書でも十分な意義があります。
電子署名の検証で、難しい問題はこの電子証明書の検証問題です。PDFコンテンツが改竄されているかどうかは、ハッシュ・アルゴリズムと暗号アルゴリズムというコンピュータによる単なる計算の問題に過ぎません。ところが、電子証明書の検証には、有効期限、失効情報、証明書の認証機関、ルート証明書への認証パス構築など、やたらに難しい問題がいろいろあります。難しい問題の大半は、電子証明書に起因するといっても過言ではありません。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月10日
書けまっせ!!PDF2 フォームの入替
アンテナハウスでは、2月から6ヶ月間、「書けまっせ!!フォーム」を提供してまいりましたが、先日から、「書けまっせ!!フォーム」の内容を一新しました。
実際に数多くダウンロードされているものを中心に数を絞って、新しくフォームを作り直しました。
また、新しいフォームには、「書けまっせ!!PDF2」で、入力枠を定義したプロジェクトファイルを作成して、フォームをダウンロードしていただくと、ご自分で入力枠を作らなくても、直ぐにデータを入力できるようにしました。
例えば、Fax送付状のページをご覧いただきますと、次のようになっています。
この、拡張子prjのファイル名をクリックしていただきますと、Windowsで対応するアプリケーションで開くことができます。
お使いのPCに「書けまっせ!!PDF2」がインストールされている場合は、ダウンロード完了と同時に、「書けまっせ!!PDF2」が起動して、直ぐに文字を入力できます。
このように、「書けまっせ!!PDF2」と連動して、「書けまっせ!!フォーム」が、より使いやすい形になりました。
今後は、フォームの種類をもっと充実していきたいと考えています。ぜひ、一度お試しくださいますよう、よろしくお願いします。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月09日
外字（表外字）（２）
外字の話の続きですが、実際に Antenna House PDF Driver がどのように外字を PDF へ出力しているのかを簡単に説明します。
ユーザが各々の環境で作成する EUDC フォントは他の環境に存在することは通常ありませんので、Antenna House PDF Driver は Unicode のコードポイントからそのグリフを外字と判断した場合、自動で PDF にフォントを埋め込みます。EUDC フォントは TrueType 形式のフォントファイルですので、ここからは通常の TrueType フォントを埋め込むのと同じ手順となります。
まず、フォントファイルからグリフのアウトラインデータを取得して PDF 埋め込みますが、PDF の本文内ではグリフ番号だけになり、文字コードによる検索ができませんので、ToUnicode CMap を作成して、フォントに付加します。これで外字を検索することができるようになります。
ToUnicode CMap については、2006/5/18 のブログをご覧ください。
PDFからテキスト抽出のために ToUnicode CMap
投稿者 numata : 08:00 | コメント (0) | トラックバック
2007年08月08日
XSL Formatter V4.2をリリース
アンテナハウス株式会社は、8月7日より「XSL Formatter V4.2」の出荷を開始しました。
XSL Formatter V4.2 は下記の点が強化されました。
1. Unicode 5.0 に対応しました。
2. サロゲートペアに対応しました。16ビットで32ビットの漢字を扱えます。
3. 欧文ペアカーニングができるようになりました。欧文組版の品質が向上します。
4. 欧文リガチャができるようになりました。欧文組版の品質が向上します。
5. 日本語の漢字の字体変更ができるようになりました。JISの改訂による字体変更に関するオープンタイプのフィーチャ・テーブルをサポート。
6. JIS X 0213:2004の全文字を処理可能になりました。
7. （Hindi言語の）Devanagariスクリプトに対応しました。従来は、Windowsの機能を使っていましたが独自処理により、Unix,LinuxでもDevanagariスクリプトの組版が可能となりました。
8. Arabic処理を強化し、Arabic Typesetting （フォントのフィーチャ）に対応しました。
9. PDF1.7に対応しました。
10. PDF/Aに対応しました。PDF/A-1a、PDF/A-1b準拠PDFの出力ができます。
11. PDFのフォームに対応しました。
12. （PDF電子署名モジュールをお使いの場合に限り）PDFに電子署名を付けることができるようになりました。（Windows版のみ）
13. PostScript(R)出力ができるようになりました。
14. GUIで、見開きページ表示ができるようになりました。
◎プロパティの拡張、要素の追加
・以下のプロパティが新設または拡張されました。
* axf:field-apply-signature
* axf:field-button-face
* axf:field-button-face-down
* axf:field-button-face-rollover
* axf:field-button-icon
* axf:field-button-icon-down
* axf:field-button-icon-rollover
* axf:field-button-layout
* axf:field-checked
* axf:field-checked-style
* axf:field-default-text
* axf:field-description
* axf:field-editable
* axf:field-maxlen
* axf:field-multiline
* axf:field-multiple
* axf:field-name
* axf:field-password
* axf:field-readonly
* axf:field-required
* axf:field-scroll
* axf:field-submit-coordinates
* axf:field-submit-method
* axf:field-top-index
* axf:field-type
* axf:field-value
* axf:japanese-glyph
* axf:kerning-mode
* axf:ligature-mode
* axf:line-number-text-align
* axf:line-number-width
* axf:line-continued-mark
* axf:line-continued-mark-offset
* axf:line-continued-mark-color
* axf:line-continued-mark-background-color
* axf:line-continued-mark-font-family
* axf:line-continued-mark-font-size
* axf:line-continued-mark-font-style
* axf:line-continued-mark-font-weight
* format
* text-align
・要素の追加
* axf:form
* axf:form-field
* axf:form-field-option
詳細な情報はこちらをご覧ください。
◎ニュース・リリース
・XSL Formatter V4.2 2007年8月7日出荷開始
・Webページ
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月07日
アンテナハウスPDF電子署名モジュール 評価版を公開
アンテナハウスでは本日より、アンテナハウスPDF電子署名モジュールV1.0の販売を開始します。
本製品は、、既存PDFを対象として、サーバサイドでのオンデマンド処理やバッチ処理で、電子署名やタイムスタンプをつけたり、既存のPDFに付けられている電子署名やタイムスタンプを検証するライブラリ製品です。次のような特徴をもっています。
１．PDFに電子署名やタイムスタンプをつけることができます。Acrobatなど他のPDFツールは不要です。
２．PDFの電子署名やタイムスタンプを検証することができます。Acrobatなど他のPDFツールは不要です。
３．PDF標準仕様準拠の電子署名を付けます。アドビ製品のPDF電子署名と互換なのでAcrobat 7/8と相互運用ができます。
４．署名に使用する証明書の設定、署名外観の設定、検証方法の設定などの設定ファイルを作成するための、「GUI版設定プログラム」が添付されています。
５．「電子署名モジュール」は、コマンドライン・インターフェイス、.NET、JAVA等のプログラム言語用APIとして機能を提供します。
６．サーバサイドでのバッチ処理やオンデマンド処理のためのライブラリーとしてアプリケーションに組み込んでいただけます。
７ ．既存PDFに対してパスワード方式のセキュリティ設定、電子証明書によるセキュリティ設定、リニアライズもできます。
８．「XSL Formatter V4.2」以降と連携し、XSL-FO内で指定した署名領域に電子署名を付けることができます。
詳しい、製品のニュースはこちらです。
http://www.antenna.co.jp/news/Psg10-20070807.htm
また、Webページはこちらです。
アンテナハウスPDF電子署名モジュールWebページ
Webページからは評価版をダウンロードしていただくことができます。評価版は30日間の期限で、製品と同等の機能をお試しいただくことができます。
本日、午後、製品の説明会を行いますが、そのとき、できるだけ具体的に製品の機能についてデモをご覧いただきながらご説明をしたいと考えています。
なにとぞ、よろしくお願いします。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月06日
PDFと長期署名(12) — ECOM提案のPDF/A長期署名を再び批判する
前回、PDFと長期署名(11) — ECOM提案のPDF/A長期署名で、ECOMのJIS原案を批判しました。
このJIS原案少し改訂になったようで、現在は、
附属書E
（参考）
PDF/Aへの長期署名の適用方法
となっています。
この付属書Eを書いた人は、PDF/Aの仕様をまったく理解していないと言いましたが、それだけではないようです。PDF Reference の電子署名に関する規定も理解していないようです。
PDF Referenceには、1.4以降1.7まで、一貫して次の一文があります。
Once a document has been signed (see Section 2.2.6, “Security”), all changes made to the document must be saved using incremental updates, since altering any existing bytes in the file will invalidate existing signatures.
(PDF Reference 1.4 p.69)
つまり、PDFに電子署名を施すと、その後、PDFは常に増分更新をしなければならなくなります。
電子署名を施したPDFに添付文書をつけると、その添付文書は、署名後のPDFファイルへの増分更新となります。
ECOMのJIS原案には、次のような一文があります。
E.3 時刻付き署名データ及び長期保存署名データの格納方法
e)長期署名の延長（アーカイブタイムスタンプの再取得）は，添付ファイルに格納された長期保存署名データに対して行い，添付ファイルを差し替える。
しかし、増分更新である以上、添付ファイルの差し替えはできません。
ちなみに、Acrobat 8で、署名したPDFに添付ファイルをつけます。これは、PDF/Aとしては許されませんが、PDFとしては許可されます。
その添付ファイルを削除しようとしますと、次のような警告がでます。
つまり、PDFに電子署名を施したあと、添付ファイルをつけると、その添付ファイルを削除することは、PDF Reference1.4以降の仕様上許されません。追加はできますが、差し替えはできないのです。仮に、差し替えするようなツールを作ったとしますと、そのソフトはPDFの標準を無視したソフトということになります。
前回は、PDF/Aでは、添付ファイルが許されないと言いましたが、仮に、PDF/AをPDFに変更したとしても、この附属書E（参考）PDF/Aへの長期署名の適用方法はPDF Referenceに不適合となってしまいます。
この付属書は全面撤回する方が良いのではないでしょうか。
ところで、ここまで書いて、もしや、と思い、ISO DIS 32000を見ますと次のようになっています。
Once a document has been signed (see 12.8, "Digital Signatures"), all changes made to the document may be saved using incremental updates, since altering any existing bytes in the file invalidates existing signatures.
must beがmay be に入れ替わっています！PDF Reference 1.7とISO DIS 32000は技術的に同等なはずなんですが。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (1) | トラックバック
2007年08月05日
PDF電子署名モジュール 発表迫る！
既に、製品発表会のご案内を掲載してます通り、アンテナハウスでは、8月7日に「PDF電子署名モジュールV1.0」を発表します。また、同日から評価版をダウンロードをしていただけるように準備中です。
とりあえず、プレビュー的な製品ページをこちらに用意いたしました。
ご期待ください。また、リセラー様向けの発表会はまだお申込みは若干の余裕がありますので、関心をお持ちの方は、ぜひ、ご参加ください。
また、同時に、「XSL Formatter V4.2」を発表します。
XSL FormatterV4.2では次の新機能が追加になります。
・PostScript出力
・PDF/Aの出力
・PDFのAcroForm出力
・PDF電子署名モジュールとの連携による電子署名の付加
など。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月04日
外字（表外字）
外字を作成することで使用するフォントに定義されていない文字を独自に登録して使うようにすることができます。Windows では Windows 付属の「外字エディタ」で EUDC（エンドユーザ定義文字、End-user-defined characters）としてあらかじめ定められた領域にグリフを定義することができます。
この定められた領域とは、Unicode では PUA（Private User Area：U+E000 - U+F8FF）領域であり、この先頭の一部範囲が Shift-JIS の [F040 - F9FC] に対応します。
さて、「外字エディタ」でグリフを作成した場合、そのグリフは EUDC フォント（EUDC.tte）に格納されます。これは TrueType 形式のフォントファイルです。
「外字エディタ」には作成したフォントの使用方法を指定する、「すべてのフォントにリンクする」「指定したフォントにリンクする」というオプションがあります。前者はデフォルトの EUDC フォントになります。「指定したフォントにリンクする」とは、特定のフォントと EUDC フォントを対応付けて、デフォルトの EUDC フォントに定義されている外字より優先して使用されます。これらの対応は、レジストリの [HKEY_CURRENT_USER\EUDC\932] に定義されます。デフォルトの EUDC フォントは次のように定義されています。
"SystemDefaultEUDCFont"="C:\\WINDOWS\\fonts\\jeudc.tte"
「指定したフォントにリンクする」の場合、たとえば「ＭＳ 明朝」に他の EUDC（kakunin.tte）を使用するようにすると次のように定義されます。
"ＭＳ 明朝"="C:\\WINDOWS\\Fonts\\kakunin.tte"
このように定義されている場合、「外字エディタ」で U+E000 に なんらかのグリフを作成し、kakunin.tte として、保存してあれば、「ＭＳ 明朝」で U+E000 の文字を使用した場合、kakunin.tte に定義した文字が表示されます。
投票をお願いいたします
投稿者 numata : 08:00 | コメント (0) | トラックバック
2007年08月03日
PDFの標準
・PDF 1.7に基づくISO 32000の標準化作業が始まりましたが、他にPDF関係の標準化は次のものがあります。
・PDF/X
1998-99に標準化作業開始、2001年にISO 15930として発行。
・PDF/A
2002年10月標準化作業開始、2005年にISO 19005-1として発行。
現在、PDF/A-2の作業中
・PDF/E（Engineering）
2004年6月作業開始、2007年秋にISO 24517-1として発行予定。
･PDF/Universal Access
2005年1月より作業開始。2008年に投票予定。
・PDF/H（Healthcare）
2006年6月作業開始。2007年秋にベスト・プラクティス・ガイドと実装ガイドを発行予定。
PDFに関する標準化のためのＷｉｋｉ
PDF Standards
http://pdf.editme.com/Home
早速、登録しましたが、どうやらこれは、USの標準化委員会が開設したものようです。USの標準化委員会は、USに住所を持つ人でないと参加できませんので、入れてもらえるかどうかは分かりません。
投票をお願いいたします
投稿者 koba : 08:03 | コメント (0) | トラックバック
2007年08月02日
米国事務所を拡張
アンテナハウスは、8月1日より米国事務所を拡張しました。
8月よりデラウェア州のGreenvilleという町に第二のオフィスを開設、営業を始めました。
この事務所は、いままで借りていた会社が、契約期間を残して別の建物に移転したため、その会社からサブリースの形で借りています。
アメリカとかカナダは、オフィスを長期契約で借りることが多いようで、途中で移転すると、残りの契約期間を他の会社にサブリースすることになります。
このオフィスで、新しいスタッフを採用して、PDF製品の販売を強化する予定です。いままでは、XSL Formatterの販売が中心でしたが、人員も増員しましたし、いよいよPDFも販売強化したいと考えています。
海外市場ではAntenna House PDFは思いっきり後発なので、相当優れた製品を出さないと難しいと思います。しかし、既に、多少の実績は上がってもいますので、無残な敗北にはならないと思います。PDFは、これからISO標準にもなりますし、やはり、長い眼で見ますと、日本国内のみではなく、全世界で展開していかないと生き残れないでしょうから。
時々、話を聞きますと、日本のソフトハウスの経営者はやはりUSの市場で製品を売りたいという夢をもっている人が多いようです。しかし、皆さん、必ずしも成功しているとはいえません。同業他社でもUSに販売の会社を作って、何億も損失を出して撤退するケースがしばしば見られます。
当社の場合は、2003年に資本金500ドルでスタートし、2005年に資本金を10万ドルに増資するという形で一歩一歩進めてきました。2007年3月期米国法人は売上高136万ドル、純利益14万ドルを出すことができました。まあ、小さいながら、一応、合格点を取っていると、喜んでるところです。
知らない市場にいきなり多額の資本を投下するのではなく、少しずつ伸ばすという方法も考えてみるべきじゃないでしょうか。とにかく日本のソフトウェア・メーカも国際展開は必須です。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2007年08月01日
PDFと長期署名(11) — ECOM提案のPDF/A長期署名
日本では長期署名については、ECOMで熱心に取り組んでいることは、一番最初にお話しました。
ECOMでは、長期署名について、調査を行い、また相互運用実験を行い、さらに、JIS規格化に向けて提案を行っています。この活動自体は高く評価されるべきと思います。
ところが、このJIS規格案の付属書Bに次のような参考資料があります。
附属書B
（参考）
PDF/A への長期署名の適用方法
冒頭に「ISO / DIS 19005-1 において規定された、長期保存のための電子文書フォーマットであるPDF/A は、。。」とあって驚きます。まず、ISO 19005-1は、DIS（仕様草案）ではなくIS（仕様）じゃないでしょうか。それを知らないはずはないにも関わらず、DISと言っているのは、PDF/A-2を狙っているのでしょうか。意味深です。
さて、それはともかく、本文はかなり問題があるように思います。
B.1-d)この附属書では，PDF/A への長期署名適用のために，次の名前を定義する。
とあり、
「B.3 時刻付き署名データ及び長期保存署名データの格納方法」
時刻付き署名データをPDF コンテンツの署名タグ内に格納し，可変長の長期保存署名データは添付ファイルとして格納する（図B.1 参照）。
とあります。このような文脈から、この参考資料では、PDF/Aで添付ファイルを使おうと意図していることが明確です。
しかし、このブログをお読みいただいた方は、既にお分かりと思いますが、PDF/A-1では添付ファイルは許されていません。
従いまして、この案は、ISO 19005-1（PDF/A-1）に対して不適合です。いくら参考資料とはいえ、なぜ、わざわざPDF/A-1に不適合な仕様を提案しているのでしょうか？
そこで、ECOMに問い合わせましたところ、次のような回答をいただきました；「電子署名に関し，昨年始めからISO/TC171国内委員会と連携してISO/TC171/SC2/WG5（PDF/Aの標準化WG）に対して，問題提起を行なってきました。この結果，今年１月の会議で各国の賛同を得て，電子署名部分がPDF/Aから切り離され別の仕様になることが決まりました。JISの附属書はこの経緯を踏まえたものとなっています。」
なんだそうです。しかし。。。将来、PDF/A-2で添付書類が許される可能性があるのでしょうか？
私の理解したところでは、 ISO 19005-1を書いた人たちの頭では、PDFの長期保存性を実現するために、PDF/AはPDFファイルの外部環境に一切依存しないで自己完結型のPDFとする、という基本方針に基づいて仕様が作成されているように思います。それに対して、PDFの添付ファイルは、PDFとは異質の別形式のファイルを、PDFの後ろに取り外し可能なアタッチメントのように取り付けたものです。
このように考えますと、PDF/Aの設計思想と、添付ファイルは本質的に相容れないのではないかと思います。従って、将来、PDF/A-2になったとき、（すくなくとも無制限には）添付ファイルを許可する可能性はないように思います。
2番目の大きな問題：長期署名対象のPDFをPDF/Aに限定する必要があるのでしょうか？
このブログをお読みになったかたは、理解されると思いますが、PDF/Aファイルを作るのはかなり大変です。つまり、通常のPDFに比べて、PDF/Aというのは、PDFに対してものすごく大きな制約をかけているものです。ですので、世の中にPDFが100個あったとして、PDF/Aにできるのは、恐らく1個未満じゃないかと思います。
Acrobat8 Professionalをお持ちのかたは、プリフライト機能で、あるPDFがPDF/Aに適合しているかどうかをチェックしてみたら良いと思います。現在、流通しているPDFの99%以上は、PDF/A不適合になるでしょう。いや、もしかすると、WebにあるようなPDFは、ほぼすべて（100%に限りなく近く）がPDF/A不適合となるかもしれません。
PDF/A仕様に適合するPDFを作ろうとしますと、オリジナルのコンテンツからそのことを配慮して作らねばなりませんし、世の中に広く流通しているプリンタ・ドライバ形式のPDF生成ソフトでPDF/Aを作るのは困難、もしくは不適切だろうと思います。
なぜ、そういう性格をもつPDF/Aを前提に長期署名を考えるのでしょうか？普通のPDFに長期署名をつけるのではだめなのでしょうか？
この二つの問題点から、ECOMのJIS案の附属書Bを書いた人達は、PDF/Aについて正しい知識を持っていない、あるいは、全く勉強しておらず、ご都合主義でPDF/Aという単語をつかっているにすぎないと思います。
投票をお願いいたします