I love software!

5月11日～13日開催のソフトウエア開発環境展は無事終了しました。
ご来場いただきました皆様、大変ありがとうございました。
　
初日、2日目と雨にたたられて来場者数が少なく心配しました。
13日金曜日天気も良くてよかったですね。
　
今回、アンテナハウスブースは今までよりも整理して見やすく・理解しやすくしたつもりですが如何でしたか？
　

　
また、今回はOEM営業グループがPDF Viewer SDK、PDF to Excel SDKを積極的にアピールしました。
ビジネスについては「果報は寝て待て」とは行きません。SODECの活動が、5月以降の業績アップにつながることを期待します。

先日からAdobe Digital Editionsの奇妙な動作に嵌っていますが、いろいろ試したところどうやら分かってきたのは、最初に指定したプロパティがうまく働かないようだということです（CSSの場合、スタイルシートがいくつも使えるので、最初と言う言葉の定義も難しいですが）。

5/18追記：どうやらCSSにUTF-8のBOM（Byte Order Mark）が付いていたのが原因のようです。Adobe Digital Editionsの問題ではなくて、CSSの方の問題ということです。詳しくは次のTweetをご覧ください。

１．http://twitter.com/#!/MurakamiShinyu/status/70471711665033216
２．http://twitter.com/#!/MurakamiShinyu/status/70474839609180160

いやあ、やはり、@MurakamiShinyu はプロだよ!
ということで、下記は一応参考のために残しておきますが。もはや内容は単なる間違いの記録に過ぎません。皆様ご注意ください。

一応参考のために実験して分かってきたことを整理しておきます
「CSSで目的とする.fig {width}指定の前に、何らかのプロパティ指定（これは何でもよい）が入ると、Adobe Digital Editions では期待通りに表現される」

○資料
-------------------------------------------------------
１ re-Error-css-p-tuika.epub
-------------------------------------------------------
元ファイルの css にて、.fig の前に、 [.p] の backgland-color 指定を
入れる。

→正常に表示されている。

〈構文〉
.p　{
background-color: pink;
}

.fig {
border-style: solid;
border-width: thin;
border-color: black;
width: 50%;
}

（以下、元ファイルと一緒）

-----------------------------------------------------
２ re-size-of-image.epub
-----------------------------------------------------
.fig のレイアウト指定を二つに分割。width 要素を最後に持ってくる。
HTMLでは、正常に表示する。
Adobe Digital Editionsでは、イメージのサイズは期待通り表示されるがborderは表示されない。

〈構文〉
/* test */
/* re-size-of-image */

.fig {
border-style: solid;
border-width: thin;
border-color: black;
}

img.case-2 {
width:100%;
}

img.case-3 {
max-width: 100%;
}

.fig {
width: 50%;
}

-----------------------------------------------------
３ re-Error-css-fig-bunkatsu2.epub
-----------------------------------------------------
.fig のレイアウト指定を二つ分割。最初に width 要素を持ってくる。

HTMLでは正常に表現されるが、Adobe Digtal Editionでは.figにwidthが反映されない。
（しかし、2とは逆にborderは表示されている。）

〈構文〉

/* test */
/* re-Error */

.fig {
width: 50%;
}

img.case-2 {
width: 100%;
}

img.case-3 {
max-width: 100%;
}

.fig {
border-style: solid;
border-width: thin;
border-color: black;
}

これから見ると、どうやら指定順序が影響しているようだが、おそらくこれはAdobe Digital Editionsのバグではないだろうか。

１．のデータ
ファイルをダウンロード
元ファイルの css にて、.fig の前に、 [.p] の backgland-color 指定を入れる。

２．のデータ
ファイルをダウンロード
.fig のレイアウト指定を二つに分割。width 要素を最後に持ってくる。

３．のデータ
ファイルをダウンロード
.fig のレイアウト指定を二つ分割。最初に width 要素を持ってくる。

PDFに電子署名やタイムスタンプをつけるシステムを開発するためのツール　「アンテナハウスPDF電子書名モジュール」のV1.3 MR1を本日公開しました。
　
MR1では、ベリサイン社の「ドキュメントサイニング用Digital ID」によりPDFに電子書名をつける機能を追加しました。

また、いくつかの不具合の修正を行なっています。

○PDF 電子署名モジュール V13 MR1 改訂情報
○評価版ダウンロード

この前の日記は、結局、日本語の混じったCSSをUTF-8で符号化した際にBOMをつけたためAdobe Digital Editionsが誤動作したらしい、という話になりました。お騒がせしました。

実はこのCSSはいまお勉強中のスタッフにいろいろ試してもらったものなのですが、彼女が使っているテキストエディタにはUTF-8をBOM付きで保存するメニューがあって、日本語テキストを保存するにはBOMが必要だろうと考えた彼女がBOM付きで保存してしまったようなんです。そんなこととはつゆしらず。大騒ぎしてしまいました。ゴメンナサイ。

でも、UTF-8にはBOMは本来必要ないんです。

BOMはByte Order Markの略で、UnicodeではU+FEFFのコードポイントが与えられています。次はUnicodeのコード表の一部。

http://www.unicode.org/charts/PDF/UFE70.pdf

※BOMのコードポイントが誤っていましたので訂正しました。

BOMのもとはByte Order（バイトオーダー）ということですが、これは例えば16ビット（2バイト）単位でデータを扱うとき、２つのバイトをどういう順序で扱うか（CPUのレジスタに取り込むか）ということを表すマークとして用意されています。UnicodeをUTF-16、UTF-32で表すときは意味がありますが、UTF-8は2バイト固定長ではなく1バイトずつの可変長でデータを扱うのでバイトオーダーは意味がありません。

私は10数年前、シフトJISとかISO-2022-JP全盛の時代で、XMLが出てきてUnicodeが使われ始めた時代にテキスト判別モジュールを設計した経験があります。これからはUnicodeの時代になるので、XML Editorのテキスト文字コード自動判別でも、シフトJISやISO-2022-JPだけではなく、UTF-8、UTF-16、UTF-32を自動判別できないとまずいだろうということで調べました。で、その当時はUTF-8にBOMをつけると言う発想は無かったと記憶しています。

でもいつの間にか、UTF-8にBOMをつけるテキストエディタが普及していたのですね。

最近は、UTF-8にBOMをつけて、これがUTF-8であることを示したり、UTF-8にASCII文字以外が入っていることを示すために使うとしているようです。しかし、これはBOM本来の意味ではありませんし、UTF-8はもともとASCIIコードだけのときにはASCIIコードと同じになるように設計されているわけだからBOMをつけるのはUTF-8の精神に反するような気もします。

それはともかく、古くからのソフトの中にはUTF-8にBOMがついていると、"想定外"ということで破綻するものがいろいろあります。Adobe Digital Editionsだけではないんです。

実はCAS-UBの中核になっているデータ処理系もUTF-8にBOMがついていると破綻します。このことは、ユーザーガイドに書いてないので早速追加しなくっちゃ。

「CAS-UBで扱うテキストや各種スタイルシートやテキストはUTF-8固定です。しかし、BOMはつけないでください。」

http://d.hatena.ne.jp/cassupport/20110518/1305751974　から転載。

アンテナハウスでは、オフィスソフトなどのアプリケーションがPDF Driver V5.0を使用してPDFを出力する機能を、プログラムから利用するためのAPIである「PDF Driver API V5.0」を新発売しました。
　
本製品は、「アンテナハウスPDF Driver API V3.1」のバージョンアップ版（後継製品）にあたります。

「PDF Driver V5」は既に昨年末に発売済みで、アンテナハウスの「瞬簡PDF4」などの製品に組み込んで販売しています。

今回の「PDF Driver API V5.0」により、システム・インテグレータが、「PDF Driver V5」を使ったシステムを構築することができるようになります。

○今回のバージョンアップの項目
・新バージョンではPDF 変換処理を複数の呼び出しで並行して行うことができるようになりました。これによって、Citrixなどのシンクライアント環境で使うシステムを構築することが可能になっています。
　
・詳しくは：
「PDF Driver API V5.0」改訂情報
　
○製品情報のページ
・PDF Driver API
・インストール・ライセンス・一般的なお問い合わせについて
　
○PDF Driver V5.0のページ
・PDF Driver
※PDF Driverは、単体での販売を行なっておりません。次のアンテナハウス製品に組み込んでおります。
・「瞬簡PDF4」
・「瞬簡／リッチテキストPDF6.1」
・「アンテナハウスPDF スイート4.1」
　
また、アンテナハウスPDF Driver V5.1は、サードパーティのアプリケーションに組み込んで再頒布するライセンスの販売を行なっています。
・OEMのページ
　
○PDF Driver API V3.1は販売終了しました
今回のPDF Driver API V5.0の発売に伴い、旧バージョンであるPDF Driver API V3.1は新規の販売を終了いたしました。今後は、保守サービスを継続して提供いたします。