« 2006年03月 | メイン | 2006年05月 »
2006年04月30日
サーバベース・コンバータのテスト変換サービス開始
サーバベース・コンバータを使ったテスト変換サービスを開始しました。
デモサイトはこちらです。
Server Based Converter V1.2 MR2 テスト変換申し込み
このシステムではブラウザからアップロードされたファイルの先頭ページを、サーバ側で、PDFまたは指定の画像形式に変換します。
サーバ側で変換して作成したPDF/画像ファイルは、指定の電子メールアドレス宛てに、メールに添付して返信します。
入力できるファイル形式は次のものです。
a. ドキュメントファイル
* Microsoft Word 97/2000/2002(XP)/2003
* Microsoft Excel 97/2000/2002(XP)/2003
* Microsoft Powerpoint 97/2000/2002(XP)/2003
* Microsoft Powerpoint 97/2000/2002(XP)/2003
b. ベクター画像
* SVG（Tiny/Basic）
c. ラスター画像
* EMF/WMF/BMP/PNG/GIF/TIF/JPG/JP2
d. PDF
* PDF 1.0/1.1/1.2/1.3/1.4/1.5 （SVG、JPEG、PNGへの変換のみ）
出力形式は次のいづれかです。
a. PDF 1.4
b. SVG Tiny
c. JPEG
d. PNG
変換時は入力されたファイルの1ページ目のみ変換します。先頭ページが空白の場合は読み飛ばし、1ページのPDFまたは画像を作成します。
このシステムでは、サーバ側にMicrosoft OfficeまたはAcrobatなどは一切使っていません。ですので、変換結果は殆ど1秒以内で、クライアント側に戻ります。この高速性を、ぜひ、お試しになってみていただけばと思いまます。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月29日
PDFとフォント(20) マルチプルマスターType1フォント
マルチプルマスター・フォントというのは、Type1フォントの拡張で、ひとつのフォント・プログラムから様々な書体のフォントを作りだすことができるものです。
フォントのウエイト（ライトから極太）、幅（コンデンスからエクスパンド）などのフォントのデザインの次元を使うことで行います。
※参考
マルチプルマスターダイアログ
アドビとアップルはそれぞれ独自の技術を開発したようです。
マルチプルマスターType1フォントはアドビが開発した方法。アップルのはTrueType用ですので別のものです。
アドビの方法では、フォントのウエイト、幅、サイズなどのデザイン軸について、両極端の全てのフォントを用意しておき、その間に入るものを自動的に生成するもののようです。
中間のデザイン特性をもつフォントの生成は、ATMなどのフォントのラスタライザが行います。PDFにマルチプルマスター・フォントを埋め込む場合は、実際にラスタライザが補完して作り出したフォントを埋め込みます。マルチプルマスター・フォントそのものをPDFに埋め込むことはありません。
なお、CFF/Type2では、最初は用意されましたが削除されてしまい、これらの仕様ではマルチプルマスター・フォントは廃止された状態になっています。
PostScript fontsによりますと、アドビは、1999年にマルチプルマスター・フォントの開発を止めるとアナウンスしたようです。今までに制作されたマルチプルマスター・フォントは、約50種類と少ないようということを見ても、マルチプルマスター・フォントはあまり成功したフォント形式とは言えないようです。
2006/5/2 追記
"TrueType, PostScript Type 1, & OpenType: What’s the Difference?"Thomas W. Phinney
の最後の方にも、MMType1について成功していないと書いてあります。成功しなかった理由として、サポートする（MMType1を読んで、ラスタライズ、画面表示できる）アプリケーションが少なかったことを挙げています。
MMtype1を実現するには、各軸にそった極端なグリフセットを作らないといけないのですが、3軸だと8種類になります。それなら、最初から、8家族からなるフォント・ファミリーを制作するほうが手っ取りばやいという訳です。
私は、最初にMMtype1についての説明を読んで、なんてすごいアイデアだと思ったことを覚えています。しかし、どうやら現実の方が厳しかったようです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月28日
PDFとフォント(19) CFF/Type2 フォント
CFF（Compact Font Format)は、Type1フォントのグリフアウトラインなどのプログラム容量を小さくするために開発されたものです。
CFFは通常Type2文字記述手続き(charstring)と一緒に使い、Type1フォントは、CFF/Type2セットと完全に（情報のロスなしで）相互変換ができます。Type1フォントからCFF/Type2に変換すると容量が30%～40%少なくなるそうです。
CFF/Type2フォントはAcrobat3.0（PDF1.2)のPDFにType1フォントを埋め込むのに使われており、Type1フォントをPDF1.2に埋め込む時は、CFF/Type2に変換してから埋め込みます。
逆に、PDFに埋め込まれているCFF/Type2のフォントは、PDFから取り出した後、Type1に変換してからリーダで表示したり、プリンタで印刷されます。
参考資料
CFF / Type 2 Q & A
なお、CFF/Type2というフォントの形式は、単独のフォント形式名としては存在しないようです。むしろCFF形式は、OpenTypeの中でType1フォントを保存する形式として使われることで普及しています。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月27日
PDFとフォント(18) TrueType
次はTrueTypeです。今は、TrueTypeと言いますと、Microsoft Windowsに標準搭載のフォント技術という印象があります。しかし、TrueTypeフォント技術は、もともとAppleがOSレベルで拡大・縮小可能なフォントを実現しようとして開発を始めたものです。Microsoftは別途TrueImageという技術を開発していました。
TrueImage
これを見ますと、TrueImageは、Cal BauerとBauer Enterprisesが開発して、1989年にMicrosoftが買収した、PostScript互換のインタープリタとされています。
Microsoftとアップルは、TrueImageとTrueTypeをクロスライセンスして、TrueTypeがWindowsで使えるようになったのだそうです。
TrueImageは、PostScript互換のプリンタ用に商品化されましたが、結局あまり成功することなく終わってしまいました。
現在、Webで検索しますと、TrueImageは、他の会社の何の関係もない（？）製品名になってます。こうして見ますと、なんとなくアップルは庇を貸して母屋を取られたのではないかという印象がありますね。
このあたりの経緯は、JAGATの研究会の報告にも見られます。
アドビの最初のつまずき ： 1989年
TrueTypeとType1のアウトラインデータの形式の特性、ラスタライザの性能特性などのグリフのデザインとその可視化の技術的な優劣については、いろいろな議論があるようです。この点はまた、別途、機会をみて検討してみたいと思います。
TrueTypeフォントのファイル形式としての特長をまとめますと、次のようなことになると思います。
・Type1フォント形式と違い、アウトライン情報とメトリック情報はひとつのファイルに収容されている。
・アップルのMacintosh System7.0 とWindows3.1以降のOSに、TrueTypeラスタライザが標準で搭載されていてOSレベルでサポートされている。この点で、Type1はPostScriptプリンタという高品位印刷の領域から始まったのと違い、TrueTypeは最初から非常にポピュラーな存在である。
・Microsoft Windowsには、多数のTrueTypeフォントファイルがバンドルされている。このファイルの拡張子は、.TTF、と.TTCがある。.TTCは、True Type Collectionの略でひとつのフォントファイルに複数のフォントを含んでいるもの。CJKフォントにこの形式が見られる。例えば、MS明朝とMS P明朝がひとつのフォントファイルにまとめられていたり、MSゴシックとMS Pゴシックがひとつのフォントファイルまとめられているなど。
※参考資料
A History of TrueType
Microsoft Typography TrueType
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月26日
PDFとフォント(17) Type1 フォント
アウトラインフォントと言いますと、なんといっても、Type1フォントを筆頭に挙げなければならないと思います。
2005年11月24日 消え去るType1フォントを参照してください。そこに、Type1フォントの簡単な歴史を紹介しています。
一部繰り返しになりますが、Type1フォントは、次のようなものです。
・1980年代にアドビシステムズが、PostScript言語用のフォント形式として開発し、1985年アップルのレーザライターに採用されて普及した。
2005年11月03日 PDFの作成方法（2） – PostScriptの登場をご覧ください。
・Type1は、PostScriptでアウトラインフォントを効率的に表現したもの。PostScriptの仕様は公開されて、サードパーティがクローン製品を作ることができた。しかし、Type1フォントの仕様は公開されず、それらのクローン製品でType1フォントをラスタライズすることができなかった。
・Type1フォントは、印刷用に用意されたものでPSプリンタ用に使われた。
・1989年12月に出たATM（Adobe Type Manager：Type1フォントのラスタライザ）によって、初めてType1フォントをパソコンの画面やビットマップ・プリンタで出せるようになった。それに続いて、1990年3月にType1フォントの仕様が初めて公開された。Windows9x/ME、MacOS 8/9で、Type1フォントを表示するにはATMが必要。
・Windows2000以降、アップルのMacOS X以降では、Type1フォントのラスタライザが標準搭載されているのでATMは不要になった。
・Type1フォントは、グリフのアウトラインデータを収録したPFB(Printer Font Binary)ファイルとフォントのメトリック情報を集録したファイルのペアで使う。このためフォントファイルがOS独立でない。
- Windowsの場合は、PFM (Printer Font Metrics)ファイル
- UnixなどではAFM(Adobe Font Metrics)ファイル。
Type1フォントは、このような特徴をもちパソコンのアウトライン・フォントの草分けとして大きな影響を及ぼしました。しかし、アドビシステムは、既にType 1フォントの販売を終了しています。
他のフォント・ベンダもType1フォントの販売を終了しつつあるようです。このようにType1フォントの重要度は、歴史的な存在になりかけているようです。
※参考資料
"TrueType, PostScript Type 1, & OpenType: What’s the Difference?"Thomas W. Phinney
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月25日
PDFとフォント(16) アウトラインフォントのタイプ
昨日は、アウトラインフォントがグリフのアウトラインを数学的な曲線で表わすものであること、そして、曲線で囲まれた領域のドットを塗り潰すことでグリフを可視化することを説明しました。
アウトラインフォントの中核はグリフのアウトラインデータですが、フォントファイルには、グリフの幅や高さを表すメトリック情報、あるいは、文字コードとグリフ番号の対応表、などのデータも含まれます。
アプリケーションがフォントを利用するための様々なデータを含めて、フォントファイルにどのような状態で収容されているかの仕様がフォントファイル形式と言います。
現在、普及しているアウトラインのフォントファイル形式には次のものがあります。
・PostScript Type 1
・TrueType
・OpenType TrueTypeアウトライン
・OpenType CFFアウトライン（PostScriptアウトライン、Type1アウトラインなどということもあります）
実際のところ、私が多少なりとも知識をもっていますのは、上の4つなんです。
ところが、PDF Referenceを読みますと、他にもいろいろ出てきます。
PDF Reference 5.4項に、PDFで定義するフォントの種類一覧（表5.7）がありますが、ここでは、
・Type0
・Type1
・MMtype1
・Type3
・TrueType
・CIDFontType0
・CIDFontType2
が出ています。（表5.7にはOpenTypeという言葉は出てきません）。
この他、
・Type42
フォントという言葉も聞いた覚えがあります。
PDF ReferenceあるいはPDFをAdobe Reader で表示したときのフォントの属性の用語と、一般に使われる用語に少しずれがあるような気もします。
そこで、これから少しフォントの種類について、調べて、整理してみたいと思います。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月24日
PDFとフォント(15) アウトラインフォント
昨日は、ビットマップフォントについて説明しました。これは、点滅するドットのパターンを予め用意しておく、という単純な方法でフォントを作成するものです。
２．アウトラインフォント
アウトラインフォントのアウトラインとはグリフの輪郭のことです。アウトラインフォントのファイルには、各グリフのアウトラインを描くためのデータ（パラメータ）が収録されています。
そこで、グリフの可視化は次のステップで行うことになるはずです。
（1）可視化したいグリフのデータを取り出す。
（2）データを元にグリフのアウトラインを描く。
（3）アウトラインで表現したグリフの状態から、塗り潰すべき点を見つける。
（4）塗り潰すべきを塗り潰す。
結局、アウトラインフォントをコンピュータのディスプレイに表示するには、全てのグリフについて、（1）～（4）のステップで点滅するドットのパターンに置き換えていきます。この処理を行うプログラムをフォントのラスタライザと言いWindowsのGDIやPostscriptを印刷するプリンタなど様々な機器にフォントのラスタライザが搭載されています。
アウトラインフォントについての詳しい説明は、次のページをご覧ください。
FontForgeアウトラインフォントエディタ（概要）
この中の「アウトラインフォントとは何か? ビットマップフォントとは何か?」あたりにアウトラインフォントについての詳しい説明が載っています。
グリフのアウトラインを記述する方法の中で、現在、最もポピュラーなのは、PostScript（Type1）フォントで使われている3次ベジエ曲線、およびTrueTypeフォントで使われている２次ベジエ曲線のふたつの方法です。
FontForgeの中に、ベジエ曲線についての分かりやすい説明があります。
Bézier1 スプライン
アウトラインフォントでは、グリフの輪郭を多数の線分に分割し、各線分をベジエ曲線で表します。ベジエ曲線は、二つの端点とそれに加えて曲線の曲がり具合を制御する制御点のデータで表現することができます。従って、アウトラインフォントのグリフデータの中核は、多数の線分の端点と制御点の集合ということになります。
アウトラインフォントの良い点は、グリフをベジエ曲線という数学的な曲線で表していますので、拡大・縮小が自由にできるということです。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月23日
PDFとフォント(14) ビットマップフォント
昨日は、グリフを可視化する方式として、(1)点滅するドットのパターン、(2)ペンで線を描く、(3)光学的方式を説明しました。
今日は、その中で、フォントのデータから(1)点滅するドットのパターンをどうやって作り出すか、という観点からどのような方式があるかを整理してみたいと思います。
１．ビットマップフォント
一番単純なものは、フォントのデータ自身の中に、グリフをドットのON/OFFのパターンとして表したデータとして持つ方式です。
※参考
ビットマップフォント
次の例は、縦方向12行、横方向12列（12×12ドット）の塗り潰しパターンで「阿」という文字を表した例です。
※実際のフォントのデータではありません。
ビットマップフォントでは、このようなパターンデータを文字毎に用意するわけです。
ビットマップフォントの最大の問題は、拡大、縮小をすると汚くなってしまうことでしょう。すなわち、12×12ドットで最適な形になるようにデザインされたフォントを、例えば1文字あたり24×24ドットで表示すると奇麗ではなくなります。このため、文字を表示・印刷する装置のドット密度と表示したい文字の大きさ毎に適切なドット数のフォントを選択しなければなりません。
このためフォント供給者は、様々なサイズのフォントを品揃えしています。例えば、リコーのビットマップフォントの案内を見ますと、次の種類があります。
・ゴシック体 10×10、12×12、14×14、16×16、18×18、20×20、24×24、32×32、40×40
・明朝体 12×12、14×14、14×14 (ボールド)、16×16、16×16 (ボールド)、18×18、20×20、24×24、32×32、40×40
リコーのビットマップフォントには、この他にゴシック体を低解像度用に改良したNewゴシック体、丸ゴシック体も紹介されています。
ビットマップフォントは、パソコンの画面表示、携帯機器（PDA）、携帯電話、あるいは様々な電子機器などメッセージ表示用に使われます。実際のところ、ビットマップフォントが今一番使われているのは、携帯機器ではないでしょうか。しかし、家庭用の電子機器、複写機、FAXなども液晶画面でメッセージを表示するようになっていますので、ビットマップフォントの利用範囲は非常に広範囲に渡っていると思います。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月22日
PDFとフォント(13) 文字（グリフ）の可視化方法
2006年03月11日 PDFとフォント(1) 書体、グリフ、フォントでは、「フォントとは、書体が同じグリフを集めたもの」と定義しました。
ここでは、文字のグリフを可視化する方法という観点から、コンピュータで使用するフォントの種類について、まとめて見ます。
いま、グリフを可視化するという難しい表現を使ってしまいましたが、その方式として、幾つかあります。
１．点滅するドットのパターンでグリフを可視化する方式
一番簡単な例としては、電光掲示板がその典型的な例としてあげられます。
新幹線の車両や、JRの車両などにはニュースを伝える電光掲示板を良く見かけます。また、野球場のスコアボードにも電光掲示板があります。電光掲示板は、ランプの点滅のパターンで文字を表す仕組みです。
コンピュータの画面、携帯電話の画面、またはプリンタでの印刷などにおいて文字を表す仕組みは電光掲示板方式を精密にしたものです。点滅させるドットを小さくしていくことで、精密さを増しています。
２．ストロークでグリフを可視化する方式
点滅するドットのパターンで表す方式と比べますと、使用される頻度は少ないと思いますが、コンピュータを使ってペンや筆に相当するツールを制御して文字を書くという方式もあります。典型的な例が、プロッタ（ペンプロッタ）と呼ばれる出力装置を使うものです。
この方式は、建築や機械などの設計図面を紙に出力するのに使われる方式で、PDFとは親和性が小さいように思います。
※参考
プロッタ 【plotter】とは
３．その他の可視化方法
グリフの可視化の伝統的な方法として活字などがあります。というよりも活字は可視化されたグリフそのものというべきかもしれません。
この活字の発展形として、日本で開発された独自技術に写真植字（写植）があります。これは、文字盤に記載された文字を、写真の技術を使って、拡大・縮小して印画紙に焼き付けていく、という方法です。
※参考
写真植字機（手動写植機）
活字や手動写植は、コンピュータ技術以前のもので、いわばアナログ方式です。現在は使われることが少なくなっています。
この中で光学的方法で可視化する方式をコンピュータで自動化したものとして、デジタルフォント＋電算写植機があります。これは、現在でも新聞の印刷などに使われているようです。
※参考
電算写植
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月21日
Antenna House PDF Tool V2 (3)
今日は最後の PDF Tool API を紹介させていただきます。
PDF Driver、PDF Driver API は PDF を生成する機能でしたが、PDF Tool API は 既存の PDF の編集・加工を目的としています。
PDF Tool V2 では、現行の PDF Tool の機能に対して「注釈の取得・作成（リンク注釈、テキスト注釈、スタンプ注釈、ファイル添付注釈）」機能が追加される予定です。また、PDF Tool ではサンプルプログラムとしてご提供していたコマンドラインインターフェイスを正式にサポートする予定です。
PDF Tool API の機能リスト
PDF をページ単位に分割・結合
・PDF をページ単位で分割・結合します。
・分割： 指定したページ位置で PDF を分割して、新たな PDF にします。
・結合： 複数の PDF を結合して、ひとつの PDF にします。
PDF のセキュリティを設定・変更
・PDF を暗号化します。
・PDF に各種の制限（閲覧、印刷、文書の変更、コピー＆ペースト等）を設定します。
・PDF に設定されているセキュリティ情報を取得します。
PDF のメタ情報（文書情報）を取得・設定
・PDF のメタ情報（文書情報）の取得・設定をします。
・PDF の開き方の取得・設定をします。
PDF のしおり取得・作成
・既存のしおりの取得・削除をします。
・新規のしおりの作成をします。
PDF の注釈の取得・作成
・リンク注釈、テキスト注釈、スタンプ注釈、ファイル添付注釈の取得・作成をします。
- リンク注釈：HTML のリンクの動作と同じ感覚で、ページ内移動や他の PDF やウェブサイトへのリンクができます。
- テキスト注釈：文書内の任意の位置にコメントを追加することができます。コメントはポップアップウィンドウに表示されます。
- スタンプ注釈：実際の紙にスタンプを押すのと同じように、PDF にスタンプを表現することができます。
- ファイル添付注釈：文書内の任意の位置に、添付したいファイルを注釈として PDF に埋め込むことができます。
PDF のリニアライズ（Web 表示用に最適化）
・PDF をリニアライズ（Web 表示用に最適化）します。
この PDF Tool API を利用することで、開発者は以下のような要望に対応することが可能となります。
・PDF をまとめて Web 表示用に最適化（リニアライズ）したい！
・社外用に PDF をまとめて暗号化（パスワード・制限の付加）したい！
・サーバのバッチ処理で大きな PDF 文書を分割して読み易くしたい！
・分類した複数の PDF をひとつの PDF にまとめたい！（結合、マージ）
・既存の PDF にしおり（アウトライン）を付加したい！
・Office 文書や画像ファイルを PDF に添付したい！（添付ファイル注釈）
・大量にある PDF から添付ファイルを抜き出したい！（添付ファイル注釈）
以上、Antenna House PDF Tool V2 の事前紹介でした。現在、鋭意開発中のため評価版や仕様書のご提供ができませんが、リリース日には評価版も一緒にご用意させていただきます。ご興味を持たれた方は、しばらくお待ちください。
Antenna House PDF Tool（V1）は評価版をご用意しております。詳細はウェブサイトでご確認ください。
投稿者 numata : 08:00 | コメント (0) | トラックバック
2006年04月20日
Antenna House PDF Tool V2 (2)
昨日に引き続いて、今日は PDF Driver API を紹介させていただきます。
PDF Driver API を使うと、プログラムの中からAntenna House PDF Driver と連携して、Microsoft Word（WordML、RTFを含む）/ Excel / PowerPoint（各2000以降）、一太郎 などの文書の形式を自動的に判別して適切なアプリケーションを起動・制御して、PDF を作成することができます。その際、指定したページを PDF にすることも可能です。
PDF Tool V2 では、現行の PDF Tool に対して以下の機能が追加される予定です。
・PDF 出力するページの指定（Excel ではシートの指定）
・ページ単位（Excel ではシート単位）に PDF 出力
・あらかじめ Antenna House PDF Driver で作成した PDF の出力設定ファイル（*.printSetting2）の指定
この PDF Driver API を利用することで、開発者は以下のような要望に対応することが可能となります。
・コマンドラインから PDF を作成したい！
・大量にある Office 文書をバッチ処理で PDF 化したい！
・作成する PDF ごとに透かしを変更したい！
また、PDF Tool V2 よりご要望の多かったコマンドライン、COM などのインターフェイスの追加を予定しています。
※ PDF Driver API は、Windows 版のみの提供となります。
Antenna House PDF Tool（V1）は評価版をご用意しております。詳細はウェブサイトでご確認ください。
投稿者 numata : 08:00 | コメント (0) | トラックバック
2006年04月19日
Antenna House PDF Tool V2 (1)
現在、アンテナハウスでは発売中の Antenna House PDF Tool の機能を強化し、より使いやすくした Antenna House PDF Tool V2（以下、PDF Tool V2） の開発を公開に向けて進めています。その機能の紹介をします。
PDF Tool V2 では、以下のようにご提供する API を PDF を生成する API と、PDF を編集・加工する API に分離して開発者の利便性を高めます。
・Antenna House PDF Driver：Acrobat なしに PDF の生成を実現
・PDF Driver API：アプリケーションをオートメーションで動し PDF の一括生成を実現
・PDF Tool API：既存の PDF への編集・加工を実現
まず、Antenna House PDF Driver の機能についてですが、Antenna House PDF Driver は普通のプリンタと同様にアプリケーションから印刷することにより PDF ファイルを作成する仮想プリンタドライバです。Antenna House PDF Driver では以下のようなきめ細かい設定項目を用意しています。ユーザはこれらの設定を設定ファイルとして保存しておくことで、次回からその設定ファイルを指定するだけで、再度設定する必要はなくなります。
また、Microsoft Word、Excel、PowerPoint（各2000以降）で作成したファイルを、アドインボタンを使用することで作成元のアプリケーションから簡単に PDF を作成できます。このアドインボタンを使用して PDF にすることで、変換元ファイルに含まれているリンクやしおり等を PDF 反映することもできます。
一般
PDF 出力一般に関する設定です。以下の設定が可能です。
・PDFのバージョン（PDF 1.3-1.5）の指定
・PDF の作成後、その PDF を自動で表示するかどうかの設定
・同名のファイルがある場合、上書きするかどうかの設定
・文中の URL にリンクをつけるかどうかの設定
・テキストなど、用紙サイズの設定が無いアプリケーションから PDF を作成する場合に用紙のサイズおよび方向を設定
・グラフィックスの解像度と、倍率を指定
圧縮
PDF の圧縮方法に関する設定です。以下の設定が可能です。
・カラー画像のダウンサンプリング、圧縮、JPEG画質の設定
・グレースケール画像のダウンサンプリング、圧縮方法、JPEG画質の設定
・白黒画像のダウンサンプリング、圧縮方法の設定
・テキストとラインアートの圧縮
・オブジェクトレベルの圧縮
・ASCIIフォーマット
フォント
同一フォントが存在しない環境でも同じフォントで表示するための設定です。以下の設定が可能です。
・「使用されているすべてのフォントを埋め込む」、「選択して埋め込む」のいずれか
・埋め込みができなかったフォントがあった場合の処理
・欧文基本14フォントも埋め込むかどうかの設定
セキュリティ
閲覧、編集に関するパスワード、権限設定を指定します。PDF 1.3 と PDF 1.4以降では設定できる内容が異なります。ここでは PDF 1.4 を指定している場合で紹介します。以下の設定が可能です。
・「閲覧用パスワード」と「編集用パスワード」の設定
・テキスト、画像、およびその他の内容のコピーを許可する指定
・スクリーンリーダデバイスのテキストアクセスを許可する指定
・「変更を許可」の指定
- 「許可しない」
- 「ページの挿入、削除、回転を許可」
- 「フォームフィールドの入力と署名を許可」
- 「注釈の作成、フォームフィールドの入力と署名を許可」
- 「ページの抽出を除くすべての操作を許可」
- 「すべての操作を許可」
・「印刷を許可」の指定
- 「許可しない」
- 「低解像度の印刷を許可」
- 「高解像度の印刷を許可」
透かし
透かしに関する設定を行います。PDFファイルの各ページに画像・テキストのいずれかを「透かし」として挿入することができます。以下の設定が可能です。
・画像（BMP、JPEG、GIF、TIFF、PNG）の透かしの設定
・テキスト透かしの設定
- 文字列、フォント、サイズ、色を指定
- 水平方向、あるいは対角線上に配置するかの指定
・ページ上の透かしを格納する位置を指定
・透かしを本文の前面/背面いずれに配置するか指定
・挿入する透かしの透明度を設定（PDF 1.4以上）
開き方
PDFを開いたときに、どのように表示されるかを設定します。以下の設定が可能です。
・ページレイアウト（「デフォルト」「単一」「連続」「連続見開き」「見開き」）の指定
・綴じ方の指定
・ページをどのように表示するか（「デフォルト」「全体表示」「幅に合わせる」「高さに合わせる」）の指定
・ファイルを開いた場合に表示するページを指定
・ページのほかに、初期表示するパネルを指定（「デフォルト」「ページのみ」「しおりパネルとページ」「ページパネルとページ」）
・ビューアの設定
情報
PDF に格納する文書情報として、以下の設定が可能です。
・タイトル
・サブタイトル
・作成者
・キーワード
Antenna House PDF Tool（V1）は評価版をご用意しております。詳細はウェブサイトでご確認ください。
投稿者 numata : 08:00 | コメント (0) | トラックバック
2006年04月18日
PDFのメタデータ (4) — XMPメタデータの埋め込み
昨日は、XMPについて、(1)様々なリソースの特性に関するメタデータを記述する仕様を決めていることを説明しました。
XMPの仕様書では、さらに、(2)メタデータをリソースに埋め込むための仕様、および、(3)ファイルのフォーマットについて知らないアプリケーションが、ファイルをスキャンしてメタデータを取得する方法などについて記述しています。
XMPの仕様書でメタデータを埋め込む方法を説明しているリソースの種類は次のものです。
・TIFF
・JPEG
・JPEG 2000
・GIF
・PNG
・HTML
・PDF
・AI (Adobe Illustrator)
・SVG/XML
・PSD (Adobe Photoshop)
・PostScriptとEPS
・DNG（Digital Negative）
これらのリソースにXMPメタデータを埋め込むときは、次のようにXMPメタデータの前後を<?packet ..?>という命令で囲ってパケット化します。
<?xpacket begin="バイト・オーダー・マーク" id="W5M0MpCehiHzreSzNTczkc9d"?>
XMLテキスト化したXMPメタデータ
<?xpacket end="w"?>
上のバイト・オーダー・マークの部分は、U+FEFFをXMPメタデータと同じ符号化方式（UTF-8、UTF-16、UTF-32)で符号化したデータとなります。
パケット化したデータは、各リソース・ファイルの中に埋め込むことが推奨されています。画像ファイルのようなバイナリ・ファイルに埋め込んだ場合、画像ファイルの形式について知らない場合でもファイルのバイナリ・データをスキャンしてXMPパケットを見つけ出すことができなければなりません。
XMP仕様書には、<?packet ..?>命令を見つけてXMPメタデータを認識するための、スキャンの方法についても説明されています。
また必要であれば、XMPメタデータを埋め込まずに、リソースの外部においてリソースと関係つけることもできます。外部に置く場合、XMPメタデータ・ファイルの拡張子は.xmpとし、MIME タイプが必要な場合は、application/rdf+xmlを使うことになっています。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月17日
PDFのメタデータ (3) — XMP仕様について
PDFのmetadata streamにXMPパケットを埋め込むと言いましたが、このあたりをもう少し詳しく、見ておきます。
まず、XMPの仕様書とツールキットは、アドビシステムズからオープン・ソースライセンスで提供されています。ライセンス文書によりますと、ツールキットについては誰でもソースコートを改良してアプリケーションに組み込んで再頒布できるとされています。
そこで、早速、ダウンロードしたものを再配布することにしました。こちらにあります。
XMPは、次のようなXMLテキストです。
ルート要素はxmpmeta（オプション）でその下位の唯一の要素としてrdf:RDFをもちます。（恐らく、xmpmetaは旧バージョンとの互換性のために残されているもので、最新版では、rdf:RDFがルート要素として取り扱われると思います）。
rdfの名前空間宣言は、xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'です。ここから分かりますが、XMPではW3CのRDF（Resource Description Framework）を利用しています。
rdf:RDFの子供の要素としてrdf:Descriptionを複数記述できます。このrdf:Description毎にひとつのメタデータ・スキーマを利用して、リソースの属性を記述することができます。
現在のXMPの仕様書では、メタデータ・スキーマとして、次のものが定義されています。
“Dublin Core Schema”
“XMP Basic Schema”
“XMP Rights Management Schema”
“XMP Media Management Schema”
“XMP Basic Job Ticket Schema”
“XMP Paged-Text Schema”
“XMP Dynamic Media Schema”
“Adobe PDF Schema”
“Photoshop Schema”
“Camera Raw Schema”
“EXIF Schemas”
これ以外にも、独自の新しいスキーマを定義したり、既存のスキーマを拡張することができます。
XMP仕様書（72ページ）に載っている記述例をひとつ紹介しておきます。
EXIFはデジタルカメラで使用するイメージファイルの標準です。上の例はEXIFで作成されたリソースの特性について、TIFFのスキーマによる属性、EXIFのスキーマによる属性のふたとおりで記述されていることが分かります。
【参考資料】
EXIFについて
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月16日
PDFのメタデータ (2) — メタデータストリーム
メタデータはPDFの属性(プロパティ)に示されるような、著者、主題、作成日、などファイル内容に関して把握するための情報です。
PDFでは、昨日説明しましたように、ドキュメント情報辞書を使ってファイルにメタデータを付与できます。さらに、もう一つ別の方法で、PDF文書全体、または、PDF文書の中の部品にメタデータを付加することができます。それが、今日説明しますmetadata streamです。
PDFのコンテンツの種類の一つにストリーム・オブジェクトというものがあります。ストリームオブジェクトは、簡単に言いますと一塊のデータに相当します。metadata streamはストリーム・オブジェクトの中の一種類です。
metadata streamについてはPDF Reference 10.2.2 Metadata Streamを参照してください。
metadata streamの内容には、その対象となるメタデータをXMLで記述します。XML形式の仕様は、Extensible Metadata Platform (XMP)として、別途、定義されています。
PDFドキュメント全体を管理する部分にmetadata streamを付けることもできますし、PDFドキュメントを構成する部品単位でもメタデータを付与することができます。
metadata streamをどのように作成するかは、XMP仕様書の中の、XMPパケットをPDFに埋め込むという項を参照してください。
XMP仕様書
原則として、実際の情報を含むような、あらゆるPDFのストリームにはメタデータを付与することができるとされます。このため、却って、どのストリームにメタデータを付与するべきかが曖昧になってしまいますので、データを実際に持っているオブジェクトにできるだけ近い位置にメタデータをつけるべきとされています。
PDF Referenceでは、メタデータをつけるのに適切と思われるコンポーネントには、Metadataのエントリが示されていますが、PDF Referenceに示されていないコンポーネントにメタデータを付与することも可能です。
さらに、コンテントのデータ中のmarked content（タグ付）というコンテンツにメタデータを関連付けることもできます。
このようにmetadata streamをPDF中のコンポーネント・データ毎に付与して、大きな文書の中に埋め込む部品単位メタデータを持たせることができるのは、PDFワークフローを構築する際に部品の管理などに使うことを意図しているようです。
これは、アドビの提唱するメタデータ仕様XMPが、PNG、JPEG、GIFなどのグラフィックスファイルに付与できるものとなっていることとも関係します。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月15日
PDFのメタデータ (1) — ドキュメント情報辞書
PDFのメタデータは、二通りの持ち方になります。
ひとつは、ドキュメント情報辞書としてもつもの。他のひとつは、メタデータ・ストリームとしてもつものです。
ドキュメント情報辞書には次の情報を設定できます。
・Title（タイトル）
・Author（著者）
・Subject（主題）
・Keywords（キーワード）
・Creator（オリジナルのドキュメントを作成したアプリケーション）
・Producer（PDFを作成したアプリケーション）
・CreationDate（作成日）
・ModDate（修正した日）
・Trapped（トラップ処理が行われたかどうか）
このドキュメント情報の多くは、Adobe ReaderでPDFを表示したとき、文書の属性として確認することができます。
この中で、トラップ処理が行われたかどうかちょっと異色です。これは印刷のワークフローで使うものなので、一般向けではなく、Adobe Readerでは確認できないようです。
分かったつもりの印刷用語：Trappingによりますと、Trapとはオフセット印刷で、インキを重ねて刷っていくときに、印刷時の紙の伸縮や位置ずれで、白い間隔ができたりしないようにする処理のことのようです。
新しいPDFにプリプレスはどのように対応するか?－－PRNCOM '99から
は、少し古いですが、GATF(Graphic Art Technical Foundation)の調査を紹介しています。これによりますと、DTPデータの問題の中で、トラップミスが12%で第二位なんですね。
2001年に、ハイデルベルグのPDFトラップ・エディタ「Prinect Trap Editor」がGATFの技術賞を受賞しています。
PDFの仕様では、10.10 Prepress Supportの中に、10.10.5 Trapping Supportという項があり、トラップ・ネットワーク注釈という注釈の一種類としてトラップの内容を記述していくようです。なかなか奥が深そうなところです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月14日
PDF/A とはなにか？
PDF/Aは電子文書を長期に保管することを目的して作成されるPDFが満たすべき仕様です。PDF/A－１とPDF/A-2のふたつの仕様があります。
PDF/A-1は、PDF 1.4仕様に基づいています。この中でふたつの準拠レベルを定義しています。
・PDF/A-1a レベルＡは、ISO 19005-1完全準拠
・PDF/A-1b レベルBは、ISO 19005-1の一部準拠
PDF/A-1bは、PDFを表示できることが保証されれば良い。これに対して、PDF/A-1aではテキスト抽出ができることが求められます。この時のテキストはドキュメントの論理的な順序どおりになっている必要があります。これはTaggedPDFとも呼ばれます。
■経過等
米国のAIIM他の団体が中心になって、2002年から策定作業を開始、2005年9月にPDF/A-1がISO標準になりました。
なお、PDF/Aには、ISO 19005-2（PDF/A-2）という新しいパートも策定作業中ですが、PDF/A-2は、PDF1.6仕様にもとづくものでデジタル署名などを含んでいます。
■PDF/Aの目的
・デバイス独立
・表示に必要な全ての情報を含む
・自分自身の記述を含む
・基本的なツールで直接解析できる
・技術的に保護しない（パスワード、暗号化なし）
・仕様の公開
・広く普及
■PDF/Aツールの現状
・現在の時点で公式にサポートしたツールはない（と思われます）。
■PDF/A-1とPDF1.4の関係
PDF1.4をベースとして、全体、グラフィックス、フォント、アクション、注釈、メタデータ、論理構造（PDF/A-1aのみ）、対話フォームについて要求項目、勧告項目、制限項目、禁止項目を設定しています。
・やるべきこととしては、大雑把には、フォントの埋め込み、デバイス独立カラー、XMP準拠のメタデータ、タグ付け（PDF/A-1aのみ）があります。
・禁止事項として、大雑把には、暗号化、LZW圧縮、外部コンテンツの参照、透明、マルチメディア、JavScriptがあります。
■メモ
なお、PDF/Aは、電子文書保管のひとつの部品にすぎず、すべてを解決するわけではなく、ソリューションにすることが必要です。
■参考資料
・ISO 19005-1 仕様書（2005年9月出版）
Document Management - Electronic document file format for long term preservation - Part 1: Use of PDF 1.4 (PDF/A-1)
・PDF/Archive Secures ISO Approval
・PDF/Archive
投稿者 koba : 08:00 | コメント (2) | トラックバック
2006年04月13日
オープンソースのビジネスモデル (17)
さて、そろそろ、この話題も一段落としたいと思います。
それにしても、今回初めて、ビジネスモデルという観点からMySQLのWebページをチェックしてみましたが、MySQL ABには随分多くのベンチャ・キャピタルが投資しています。
MySQL AB投資者
Benchmark Capital： http://www.benchmark.com/
Institutional Venture Partners： http://www.ivp.com/
Index Ventures： http://www.indexventures.com/
Holtron Ventures： http://www.holtron.fi/ (フィンランド)
Intel Capital： http://www.intel.com/capital/
等々
う～～ん。MySQLの経営者は、ベンチャ・キャピタルから投資を引き出すのが上手なようですね。こうして投資資金が集まれば、ソフトウェアの開発を加速することができますから、開発競争という面では非常に有利です。
ベンチャ・キャピタルは通常の企業と違い、経営目標の第一優先順位は、投資先の企業の株式市場への公開と、それによるキャピタルゲインの取得にあります。この点、MySQLは、まだ公開していないと思いますが、果たして公開できるかどうか、また、その後、オープンソース・ビジネスモデルでRedHatに次ぐ（企業としての）成功例になるか興味深深ですね。
このように、欧米では、オープンソース・ビジネスに投資をするベンチャ・キャピタルが増えているようです。GPLは、元はといえばStallmanのプログラマ共産主義を実現するためのライセンスとして考案されたものですが、それが、回りまわって資本主義の権化ともいえるベンチャ・キャピタルの金儲けの手段として使われるとは世の中は面白いものです。
ところで、そういえば思い出しました。オープンソースのビジネスモデルとして適切かどうか、わかりませんが、UnysisのLZW特許のようなモデルもあります。つまり、
(5) プログラムをオープンソースで頒布し、普及した頃を見計らって、特許使用料を得る。
LZW特許は、既に米国でも日本でも失効して過去の話になりました。しかし、最近では、JPEGの特許が猛威を振るって問題になっています。
JPEGのプログラムは、BSD/MIT類似のオープンソース・ライセンスで頒布されていますので、著作権上は誰でも自由に使えます。そこで、多くの製品・ソフトウェアで採用しています。しかし、特許は著作権とは別の問題になりますので、オープンソースだからといって採用すると危険という見本です。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月12日
オープンソースのビジネスモデル (16)
完全にボランティア・ベースのプロジェクトを起こすならともかく、優れたプログラムを開発して、世の中で大勢ユーザに喜んで使ってもらうことを目標に据えるならば、そのプロジェクトを継続するための資金をどうするかが大きな課題になります。
いままで調べてきました例で、オープンソース・プロジェクトの資金を獲得する方法として次のようなものが見られます。
(1) Apacheのように寄付金を募り、あるいは、企業からのボランティアに頼る。
(2) オープンソース・ライセンスと占有ライセンスのデュアルライセンス方式を採用する。
(3) RedHatのように、プログラムを商標権によって頒布制限する。
(4) W3Cのように会費制を取って開発する。できあがったものは、後で、オープンソースにする。
オープンソース・プロジェクトのビジネス・モデルを考える場合、どのようなライセンスを選ぶかは重要なポイントの一つです。一般的には、(2)のデュアルライセンス方式を選ぶケースが多いようです。PDF関係では、QhostScriptやXpdfがそうですが、この他に、欧米のオープンソースで成功している企業にはこのようなケースがよく見られます。
例えば、今、脚光を浴びているオープンソースDB MySQLはGPLと商用ライセンスのデュアルライセンス方式です。MySQLのライセンスの説明には、(1)MySQLを自己のアプリケーションと組み合わせて顧客に販売したり、(2)お客さんがMySQLをインストールして使うことを要求するアプリケーションを販売したり、(3)MySQLを組み込んだハードウェアを販売するのは、再頒布と看做し、MySQLの商用ライセンスを買わねばならないと書いてあります。
実は、いま、初めて、MySQLのライセンスの説明について読んでみたのですが、MySQLのライセンス説明のページには少し問題がありそうに思います。
本来、GPLと占有ライセンスは、矛盾するライセンスです。GPLは占有ライセンスと同時に頒布することを認めていません。ですので、GPLで頒布されるMySQLと、占有ライセンスのプログラムを一緒に頒布するとGPL違反になります。従って、MySQLの商用ライセンスが必要となります。これは分かります。
しかし、本来GPLは、頒布に関する条件ですので、ユーザが自社内で使う分にはどんな使い方をしようがGPL違反ではないはずです。そうなりますと、ユーザが、自己の判断で、例えば、アンテナハウスのXSL FormatterをMySQLと組み合わせてシステムを作っても問題はないと思います。
XSL Formatterは占有ライセンスですので、両社を組み合わせて販売したらGPL違反で、ユーザが自己の判断で組み合わせてシステムを作成したらGPL違反にならないということになるはずです。しかし、MySQLのライセンスの説明では、このあたりが曖昧に書かれているような印象を受けます。
いずれにしても、占有ライセンスのソフトウェア供給者は、GPLのMySQLをサポートすると表明すると、まずいことになりそうです。MySQL ABと商用ライセンス契約を交わせばもちろん問題ありません。
このように、デュアルライセンス方式には一種の胡散臭さが残ります。ひとつのソースプログラムを2種類、あるいはそれ以上のライセンスで頒布するというのは、潔くないと思うのですが（日本語では二枚舌と言いますね）。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月11日
オープンソースのビジネスモデル (15)
６．７ W3C License
World Wide Web Consortium (W3C) は、Web関係の標準化を進めている産学共同のコンソーシアムです。米国のMITのCSAIL（Computer Science and Artificial Intelligence Laboratory）、日本の慶応大学、フランスのERCIM（European Research Consortium for Informatics and Mathematics）の3組織がホストになって、世界の企業・団体を組織化しています。
W3Cは、プログラムの実装よりは、むしろ、標準の仕様を策定する方に重点を置いているようです。策定した仕様は公開されていますし、誰でも自由にその仕様を利用してプログラムを実装することができます。そういう意味ではオープンソース・プロジェクトに似ています。
多くのオープンソース・プロジェクトと異なるのは、参加企業・団体にかなり高額の年会費を賦課していることで、それにより、フルタイム専属スタッフを多数擁していることでしょうか。
オープンソース・プロジェクトも、W3Cのように参加会員を募って、プログラムの共同開発を行い、できあがったプログラムは最終的にオープンソースで公開するという仕組みを取ることを考えても良いのではないかと思います。
W3Cの仕様は開発の過程では、会員企業と特定の専門家の内部だけで議論をして進めていきます。W3Cの会員になるメリットは、(1)仕様策定に参加できること、(2)仕様に関する情報を早期に入手できること、(3)各種のPR支援を得られることがあります。
ちなみに、アンテナハウスも会員になっています。当社ではW3Cの仕様の中では、XSL-FO、SVG、MathMLという3種類の仕様を実装しています。W3Cは、そういった仕様に関する情報源として、また同時に、W3CのWebサイトで当社製品をPRしてもらえることは大きなメリットになっています。
話が横道にそれましたが、W3C License はW3Cが開発したソフトウェアを、改造の有無に関わらず、再頒布する際のライセンスです。著作権の表示を明記し、このW3C License 文書を添付すれば、自由に使用を許可するという、プログラム使用者に対して寛容なライセンスになっています。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月10日
オープンソースのビジネスモデル (14)
６．６ Apache： Apache Software License, Apache License, 2.0
(1)Apacheとは？
Apache Software Foundation （ASF）は、現在、もっとも広い範囲にわたるオープンソース・プロジェクトを運営している非営利団体です。
プロジェクト領域だけでも、HTTP Server, Ant, APR, Beehive, Cocoon, DB, Directory, Excalibur, Forrest, Geronimo, Gump, iBATIS, Incubator, Jackrabbit, Jakarta, James, Lenya, Logging, Lucene, Maven, MyFaces, Perl, Portals, SpamAssassin, Struts, TCL, Tomcat, Web Services, XML, XMLBeans, XML Graphicsの31があります。
例えば、XML Graphicsには、FOP（XMLからPDFなど）、Batik（SVG関係）のふたつの活動中のプロジェクトがあります。さらに新しいプロジェクトとして、Graphics Commonを計画しており、FOPのPDFライブラリーをGraphics Commonに移すことも検討しているようです。
このように各領域には一つ以上のプロジェクトがありますので、プロジェクト総数は100を超えると思います。ASFは、単にオープンソースのプロジェクトを集めているだけではなく、プロジェクトの活動についてASFの理事会で討議して一定の水準を保つ努力をしているようです。
毎年米国と欧州でApache Conという会議を継続して行っています。
米国歳入庁（IRS)への報告が公開されていますが、これを見ますと、収入は、1999年約45,000ドル、2000年約86,000ドル、2001年約1万ドルとなっています。2003年から2005年は2万5千ドル以下です。ASFには、コンピュータ・メーカからハードウェアやソフトウェアの寄贈があるようですが、これだけの大きな非営利団体の活動を、たった数百万円のキャッシュ・フローで支えることができるのでしょうか？これはなぞです。
(2) Apache License, Version 2.0
・原文
・日本語訳
このライセンスは、ASFの成果物を頒布するために用いられているものです。Apache Licenseで頒布されているプログラム及びその派生物を、そのソースプログラムであれ実行形式であれ、Apache Licenseを添付し、必要な通知文をつければ自由に頒布することができます。
BSD/MITライセンスに似ています。ASFに寄贈されたプログラムも対象とすること、寄贈者が保有する特許の許諾も含めること、など追加されています。
Apache Licenseはこのように寛容なライセンスであることから、ASFの成果物を改良し、自己の製品として販売しているソフトウェア会社も世界には沢山あるようです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (2) | トラックバック
2006年04月09日
オープンソースのビジネスモデル (13)
６．５ MPL：Mozilla Public License
MPLはネットスケープ（Netscape Communications Corp.）が作成したものでネットスケープが改訂権を持っています。Mozillaプロジェクトで使われており、最近、脚光を浴びている新しいブラウザFireFoxはMPL1.1で公開されています。
歴史を簡単にまとめますと；
(1) Netscape Publicライセンス NPL 1.0
マイクロソフトのインターネット・エクスプローラとのブラウザ戦争で、劣勢になったネットスケープが、1998年にNetscape CommunicatorのソースプログラムをオープンソースしてMozｉｌｌａプロジェクトを起こしました。
その時、作られて適用されたのがNetscape Publicライセンス（NPL1.0）です。NPL 1.0はGPLに似ていて、Mozillaのソースコードを入手したプログラマが、それを改良したアプリケーションを作成して頒布するときは、改良したソースコードを公開・寄贈することを要求していました。
NPL1.0はNetscape Communicator用の修正条項（Amendments）があります。ここで、ネットスケープは、公開・寄贈されたソースコードをネットスケープ自身の他の占有ライセンス製品にも自由に使うことができるとした上、それらの占有ライセンス製品はNPL１．0で公開しなくても良い、というネットスケープに都合の良い条件をつけたことです。これはオープンソース関係者からの批判を招いたようです。
ちなみに、Netscape Communicatorのソースプログラムは複雑すぎて改良できないことが判明し、Mozillaブラウザはゼロから書き直す、ということになりました。Mozillaプロジェクトは失敗したオープンソース・プロジェクトと言えるでしょう。
(2) Mozilla Public License （MPL) 1.0
Mozilla Public License1.0は、ＮＰＬ1.0にあるネットスケープ専用の修正条項を削除したものです。Mozillaのソースコードを修正した寄贈者が使うためのライセンスです。
(3) Mozilla Public License （MPL) 1.１
MPL1.0の表現を改訂したもので、実質的な変更はないように思います。
(4) MPLの特長
MPLの特長は、次の通りです。
・オリジナルのソースプログラムを修正してアプリケーションに使用した場合、その修正したプログラムをMPLで公開する必要があります。
・GPLと違って伝染性はありません。自分でゼロから書き起こしたプログラムは、修正プログラムには該当しません。仮にそれをMPLのプログラムと結合したアプリケーションを作成して頒布しても、自分のソースプログラムを公開することは要求されていません。
MPLは、Copyleftという点では、GPLとBSD/MITライセンスの中間のライセンスということができます。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月08日
オープンソースのビジネスモデル (12)
６．３ BSD：The BSD License
このライセンスでは、修正の有無に関わらず、ソースプログラムまたはバイナリを頒布するときは次の条件を満たすこととされています。
BSDは非常に制限条件の緩いライセンスで、BSDで頒布されるオープンソースのプログラムは、修正したり、あるいは、修正なしで、占有ライセンス、あるいは、GPL/LGPLライセンスのものと一緒に組み合わせて頒布できます。
(1) ソースプログラムを頒布するときは、ソースプログラムに、著作権、BSDの条件、免責事項を含める。
(2) バイナリを頒布するときは添付のドキュメントに著作権、BSDの条件、免責事項を含める。
(3) 許可なく、オリジナルの開発者の名前を自分のプログラムの宣伝に使わないこと。
６．４ MIT：The MIT License
MITライセンスで頒布されるプログラムを入手した人は、著作権表示とライセンス契約を添付するという条件を守れば、どのような使用でもできます。実質的に、BSDライセンスと同じです。
BSDライセンス、MITライセンスともおおらかなライセンスで、ビジネスモデルという表題の下で、取り上げるのが恥ずかしくなるくらいです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月07日
オープンソースのビジネスモデル (11)
LGPLで提供されているオープンソース・ライブラリーを自分で作ったアプリケーションから利用したとき、そのアプリケーションを占有ライセンスで、つまり、ソースプログラムを公開することなく頒布できるでしょうか？
LGPLの契約書はとても難しいのですが。第5節を見ますと次のようなことが書いてあります。
LGPLライブラリーをまったく含まないが、それと一緒にコンパイル、リンクして動作するプログラムはLGPLライブラリーを利用するプログラムといいます。コンパイルというのはプログラムをオブジェクト（バイナリ）にすること。リンクはプログラム同士を結合すること。
契約書第5節
(1)LGPLライブラリーのいかなる部分も含まないで、LGPLライブラリーと結合して一緒に動作するだけのプログラム単体は、LGPLライセンス契約の対象外です。
(2)LGPLライブラリーを利用するプログラムに、LGPLライブラリーをリンクして実行形式を作ると、その実行形式はLGPLライセンスの対象となります。
(3)LGPLライブラリーを利用するプログラムをコンパイルするとき、LGPLライブラリーのヘッダから取られたプログラムが組み込まれると、オブジェクトコードはLGPLライブラリーの適用対象となる可能性があります。但し、組み込まれたプログラムが極少ない分量であれば、LGPLライセンスの対象としなくても良いとされています。
要するに、自分で作成したプログラムにLGPLライブラリーのプログラムをある程度含んでいるか、LGPLライブラリーを静的にリンクすると、自分で作成したプログラムにもLGPLライセンスが適用されます。
そうしますと、頒布するとき、次の条件（第6節）に従わねばなりません。この第6節がまた、難解で、何度読んでも良くわかりません。
契約書第6節
どうやら、この第6節では、次のようなことを言っていると思います。
(1) LGPLライセンスに感染したアプリケーションを占有ライセンスで頒布するときは、アプリケーションのリバースエンジニアリングを許可しなければならない。
(2) さらに、LGPLライブラリーをユーザが改変してから自分のアプリケーションと再リンクして実行形式を作成できるか、あるいはコンピュータのシステム上でLGPLライブラリーを、他のアプリケーションど共有して使えるようにするなどの配慮をする必要があります。
(3) 第6節の条件が、自分の占有ライセンスの条件と矛盾する場合は、元のLGPLライセンスのライブラリーを自分で作成したアプリケーションの実行形式で使うことができません。
LGPLライセンスの第6節で要求しているリバースエンジニアリングは、通常の占有ライセンスでは許していないことが多いと思います。従って、多くの場合、第6節の条件で自分のアプリケーションを頒布することはできないのではないでしょうか。
結局、第5節の(3)の「但し」以降に該当する場合のみ、自分のアプリケーションを占有ライセンスとして、LGPLライセンスのライブラリーと一緒に頒布できる、と解釈します。安全な側に解釈しておかないと危険ですしね。
実を言いますと、この解釈はあまり自信がありません。どなたか、良くご存知の方にコメントしていただきたいものです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月06日
オープンソースのビジネスモデル (10)
６．２ LGPL：GNU Lesser General Public License
次にLGPLライセンスについて検討してみたいと思います。
LGPLはGNU Lesser General Public Licenseの略語です。
・原文
・日本語訳
これは、主にソフトウェア・ライブラリー（ソフトウェア関数やデータを集めた部品）用に使われるライセンスの種類です。
ライブラリーはソフトウェアの部品ですから、機械を組み立てるのと同じように、様々な部品を集め、さらにそれを有機的に統合して、アプリケーションを作るのに使います。
そうしますと、ひとつのアプリケーションには、様々なライセンス条件で提供されているライブラリーが混ざることになります。例えば、LGPLで頒布されているライブラリーを、他のプログラムと結合してアプリケーションを作成するとします。
そうするとできあがったアプリケーションを頒布するときのライセンスはどうなるのでしょうか？
(1)他のプログラムの中に、GPLライセンスで頒布されているものが一つでもあれば、当然、それらを結合したアプリケーションはすべてGPLライセンスを適用してオープンソースとして頒布しなければなりません。
(2)では、LGPLで頒布されているライブラリーを、占有ライセンスのプログラムと結合してひとつのアプリケーションを作成したとします。できあがったアプリケーションを占有ライセンスで頒布することができるのでしょうか？
もしこれができるのであれば、LGPLライセンスで頒布されているオープンソース・プログラムを、占有ライセンスで提供する製品のための部品として採用できます。
できないとすると、LGPLライセンスのライブラリーは、占有ライセンスのソフトウェアを開発するために採用できないことになります。
占有ライセンスで販売する市販パッケージ・ソフトウェアの開発者にとっては、上の質問(2)の答えによってLGPLライセンスのオープンソース・ライブラリーを採用できるかどうか、が決まります。大変に重要な問題です。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月05日
オープンソースのビジネスモデル (9)
RedHat のLinuxビジネスは、サービスを売っていると言われます。確かに表面上はそう見えます。
占有ライセンスでは、顧客がプログラムをインストールした台数に応じて、使用料が多く課金されるというビジネスモデルになります。しかし、RedHat Enterprise Linux （RHEL）はGPLライセンスで提供されますから、顧客は、RHELを自由に複製してインストールできます。
顧客が自分でRHELを複製してインストールすれば、インストールしたRHELの台数が増えてもサービス収入の増加には繋がらないでしょう。要するに工夫無しにサービスを売っても儲からないだろうと思います。
収入を増やすには、RHELのインストール台数が増えれば、自然にサービス契約が増えて、サービス料金を多く課金できる仕組が必要です。
このあたり、RedHatは、一体どうやって実現しているのでしょうか？
そこで、同社のサービス購読契約（Subscription Agreement）を見てみました。
ざっとみた結果ですが、うーーん。さすがに、なかなかのものです。多分、優秀な弁護士をそろえて知恵をひねったんでしょう。GPLライセンスのプログラムを頒布して収益を上げるための契約の枠組みを見事に作りあげています。
大雑把に紹介しますと、
１．付録1-1
RHELは、GPLライセンスで提供していますので、契約書では顧客がプログラムの部品を改変したり、コピーしたり、再配布する権利を制約していません。（制約したらGPL違反になりますから。）
２．付録1-2
知的所有権という項目で、顧客がRedHatという商標を使ったソフトウエアを頒布することを禁止します。RHELを第三者に頒布するには、RedHatの各種の商標やマークを削除しなければなりません。但し、単に削除するとソフトウェアが壊れるかもしれないと脅す。（商標権で規制してRHELの頒布をさせません。）
３．本文I-A 定義
最初のインストール・システムとは、最初に顧客がお金を払って購入したRHELの枚数。（RHELは公開の場で無償入手できないように規制していますので、1枚目は購入しない限り入手できません。購入した段階で契約が成立して、顧客に契約を守る義務が発生。）
４．本文I-１ 契約期間
サービス契約は１年契約で、自動更新。（これは曲者）。
５．本文I-２ 価格、請求
RedHatは、契約時、契約更新時に定価の請求書を発行します。顧客は30日以内に支払わねばなりません。（自動更新なので知らないうちに請求が来ます。）
５．本文I-４ 報告と監査
インストール・システムを増やすには、RedHatに1台毎に報告して、サービス契約を増やさねばなりません。
RedHatは、契約期間中、顧客企業のインストール・システム数がサービス契約の数と一致しているかどうか1年1回未満で監査する権利があります。
監査結果で不正が見つかったら、顧客企業は20%分のペナルティを払わねばなりません。
大まかなところは以上ですが、これを見ますと、サービス契約を一旦締結すると、インストールした台数が増えたらそれを申告しなければならず、しかも自動更新なので定期的にRedHatに定価で支払いをしなければなりません。これはもしかするとRHELの方がWindowsよりも運用コストが高くつくかもしれません。
この仕組みだと確かにRHELは儲かるでしょう。こんな殆ど悪知恵のような仕組みを良くも考えたものです。
この契約書は、Webページに公開されているものです。オープンソース・プロジェクトを考えている人は、ぜひご自分で研究することをお勧めします。私の理解が間違っているかもしれませんしね。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月04日
オープンソースのビジネスモデル (8)
GPLライセンスが対象とするのは、GPLライセンスで配布されているプログラムを入手して、それを組み込んだり・改変して、それを第三者に頒布する行為です。
自分だけで使う分には無論、いくら改変しようが公開する必要はありません。
では、GPLライセンスのプログラムを、開発会社が入手して、受託開発で作成するシステムに組み込んで、客先に納品した時はどうなるのでしょうか？
GNUのQ&Aに次のような質問項目があります。
GPLは、私が機密保持契約の下で改変されたバージョンを開発することを許可していますか?
この質問への回答を読むと、客先のために機密保持契約を結んで、GPLライセンスのプログラムを組み込んだシステムを開発して納品しても、それを公開する必要はないように感じます。
但し、このあたりは、私の解釈にすぎませんので、もし、GPLを受託開発のシステムに使うならご自分で判断するか、専門の弁護士と相談してもらいたいと思います。
GPLは、Stallmanの、いわばプログラマ共産主義とでもいうべき思想を反映したもの。これを嫌う人も多いようです。しかし、著作権法に基づく私的契約としては、大変良く考えられた方式です。
GPLがこのように有名になったひとつの理由は、LinuxがGPLライセンスで頒布されていることにあります。では、Linuxの成功はGPLライセンスを採用したことが理由でしょうか？
Linuxの開発過程を研究して、「伽藍とバザール」（The Cathedral and the Bazaar）というオープンソース開発モデルについての有名な論文を発表したEric Raimondは、2005年6月の6th International Free Software Forum で、「もうGPLは必要としない」という基調講演を行ったとのことです。彼はインタビュー（ESR: "We Don't Need the GPL Anymore"）に応えて次のように述べています。
GPLがLinux成功の主要な理由とは思わない。むしろ、それは1991年Linusがソフトウェアの分散開発の正しい仕組みを最初に見つけた人だったからだろう。それ以前は安価なインターネットがなかったのでできなかった。それ以後は、新しいOSのプロジェクトを起こそうという人の多くは、Linuxを改善するのが最小コストの方法だということを発見したのだ。
ところで、このインタビューにRedHatについても話題になっています。2006年03月29日 オープンソースのビジネスモデル (2)で、話題になりましたようにRedHat Linux の主要部分は、GPLで公開されています。
でも、RedHat LinuxをCDまたはDVDで入手し、それをそのままインタネットに公開すると訴訟されるそうです。また、コンピュータ雑誌がおまけにRedHatのCDをつけるにはRedHatの許可が必要です。しかし、雑誌社がRedHatに申し込んでも絶対に許可しないそうです。
要するにRedHat Enterprise Linux (RHEL)を入手するには、RedHatに代金を支払って、Subscribe（購読)するしかないということになります。
どうやら、RedHatはRHELを複製再頒布をさせないように商標権で守っているようです。しかし、RHELはGPLで公開されているのでGPL違反ではない、ということになります。
「商標権で保護するとは賢い！」とEric Raimondは感心しています。Ericってすなおな人だねえ。
GPLプログラムを複製されないように商標権で守るというのは確かにオープンソースの新しいビジネスモデルです。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月03日
オープンソースのビジネスモデル (7)
さて、ようやく準備ができましたので、オープンソースのライセンスについて検討してみます。
６．オープンソースライセンスの検討
2006年04月01日 オープンソースのビジネスモデル (5)で代表的なライセンスを幾つかあげました。順に簡単にレビューしてみます。
オープンソースでは、ソースプログラムを入手した人に、著作権者が持つのと同じような権利を付与するのですが、その時の条件が、ライセンス毎にそれぞれ違います。
６．１ GPL：GNU General Public License
GNU ProjectのGPLはオープンソースライセンスとして最も有名なものです。GNU Project以外に、さまざまな、オープンソース・プロジェクトが、そのプロジェクトで作成したプログラムを公開する時に、GPLライセンスを採用しています。現在使われているのはGPL Version 2（1991年6月版）です。
なお、GPLのV3のドラフトが2006年1月に公開されて大きな論議を呼んでいるようです。
Welcome to GPLv3
GPLの特長はCopyleftというメカニズムです。これは、「誰でもソースコードを修正することができるようにするため、GPLを利用・改変したプログラムを頒布する場合はGPLライセンスで公開しなければならない」ということです。
このため、自分で開発したプログラムにGPLライセンスのオープンソースを結合すると、自分で開発したプログラムを頒布する場合、自分で作成した部分を含めて全てのソースプログラムをGPLライセンスで公開しなければなりません。
GNU ProjectをはじめたのはFree Software Foundation (FSF) のRichard Stallmanです。彼はエッセイCopyleft: Pragmatic Idealismで次の例を挙げています。
GNUのC++コンパイラはMCCが、GNUのCコンパイラを元にして開発したもの。MCCは普通は製品を占有ライセンスで提供している。MCCのC++コンパイラのフロントエンドには新しいファイルが沢山あったが、GNUのCコンパイラとリンクするために、新しいファイルにもGPLが適用された。こうしてMCCはC++コンパイラのフロントエンドを無償で出すことになった。
このようにGPLは感染するライセンスと言われます。GPLで公開されているオープンソースを使って、頒布用のプログラムを開発する時は、GPLは占有ライセンスとは一緒に使えないライセンスであることに注意しなければなりません。
GNU C/C++ コンパイラには例外があります。これらはGPLで公開されています。そして、自分で開発したソースプログラムをGNU C/C++でコンパイルすると、バイナリ・プログラムにコンパイラの標準ライブラリー（すなわちGPLの一部）が結合されてしまいます。そうなると、自分で開発したプログラムをGNU C/C++でコンパイルして頒布すると、自分のソースまで全部公開しなければならないということになりそうです。しかし、これはしなくても問題ありません。標準ライブラリーのソースプログラムのファイルに、標準ライブラリーをリンクしても、実行形式のバイナリはGPL感染から除外されるという例外規定が書かれています（runtime exceptionと言います）。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月02日
オープンソースのビジネスモデル (6)
昨日、オープンソースのライセンスについて代表的なものをあげました。それを読んで考えているうちに、特に複製権（第二十一条）と利用許諾権（第六十三条）の違いに考えて、もう少し、見ないといけないということに気が付きました。
３．複製権と利用許諾権
３．１ 複製権と利用許諾権を同一の主体が行使
プログラム利用の一番典型的な例は、エンドユーザ（企業・個人）が、ソフトウェアの著作権者から複製物を入手して、自己のコンピュータの上でそのプログラムを動作して利用するものです（図１）。
この場合、プログラムの複製権・使用許諾権を行使しているのは著作権者（またはその許可を得た者）のみとなります。
図1 自己のコンピュータでプログラムを動かして利用
３．２ 複製権と利用許諾権を異なる主体が行使
ところが、次の図２のように、プログラムは公衆または公共のコンピュータ上で動作させ、エンドユーザはその機能のみを利用する場合があります。例えば、いわゆるASP（Application Service Provider）の利用形態がこれに該当します。この場合、複製する行為と、利用許諾する行為の主体が別になっています。
図２ 公衆用コンピュータでプログラムを動かして利用
すなわち、ASP形態の場合は、エンドユーザとプログラムの使用契約を交わすのは、ASP(事業者)となります。しかし、ASP事業者は（著作権者でない限り）、使用許諾を交わす権利はもっていません。いま、こうして改めて見ますと、ASP事業者は、著作権者と契約を交わして、第三者に使用を許諾することができる権利を得る必要があるように思います。
４．商用ライセンスと占有ライセンス
４．１ 商用ライセンス
次に商用ライセンスという言葉を少し考えて見ます。このブログで商用ライセンスという言葉を既に何回か使いましたが、これは英語のWebサイトに頻繁に出てくるCommercial Licenseの訳として使いました。
商用ライセンスは、プログラム著作者のもつ権利を使って何らかのビジネス行為を行うことを意味していると思います。しかし、商用ライセンスはオープンソースと対比するべき言葉ではありません。
４．２ 占有ライセンス
オープンソースライセンスをざっくり言いますと、ソースプログラムを公開し、かつ、そのソースプログラムを入手した人に、著作権者と同等の権利を、一定の条件付きで、権利使用料を取らずに許諾するというものです。
そうしますとオープンソースでないライセンスとは、次のようになると思います。
ソースプログラムを公開しないか、あるいは、著作権者のもつ権利の一部を権利使用料をとって許諾する。
以下、このブログでは、後者を占有（Proprietary）ライセンスと言いうことにします。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年04月01日
オープンソースのビジネスモデル (5)
昨日、著作権法の概略を簡単に説明しましたように、国が定める著作権法が著作権者にいろいろな権利を認めています。
２．２ オープンソースの著作権者
特にオープンソースで少し気になりますのは、著作権者が誰になるかということです。個人でやっている場合は別として、団体、特にネット経由でお互いに協力しながら開発を行う場合、できあがったプログラムの著作権者が誰になるかは自明とは言えないように思います。
もし、特定の組織に著作権を帰属させるのであれば、参加者と組織の間で著作権の帰属についての契約を結んでおかないといけないでしょう。例えば、ApacheのFOPのプロジェクトを見ていますと、SI会社に帰属するプログラマや個人と思われるプログラマが参加しています。しかし、開発者が会社の許可を得て、オープンソースの開発に従事した場合、職務著作物にはあたらないでしょう。ですので著作権の帰属についてきちんと契約を結んでおかないと問題が発生しそうです。
２．３ ライセンス契約の根拠
オープンソースに限らず、ソフトウエアの使用許諾契約（ライセンス契約）は、著作権者が利用者に対して、一定の条件でソフトウエア著作物の使用を許諾するものです。
ライセンス契約では、著作権者は、特に使用許諾を与える権利を行使しているということになります。
プログラムの使用許諾を受ける側は、著作権者から提示された条件を承認して契約を結ぶわけです。従って、約束としてそれを守らねばならないということになります。
２．４ ライセンス契約の種類
Open Source Initiative (OSI)のWebページには、オープンソース・ライセンスとしてOSIが承認したもののリストがあります。
ABC順にAcademic Free License からzlib/libpng license まで58種類がリストされています。
この中で普及している、有力なものは、
・GPL GNU General Public License
・LGPL GNU Library or "Lesser" General Public License
・BSD New BSD license （MITライセンスと同等）
・MIT MIT license
・MPL Mozilla Public License
・Apache Apache Software License, Apache License, 2.0
・W3C License
あたりでしょう。
独断、偏見、多少の経験に基づく判断で選びましたが、次にこれらのライセンスについて、少し検討してみましょう。
投票をお願いいたします