« 2006年04月 | メイン | 2006年06月 »
2006年05月31日
グーグル・クリック詐欺集団訴訟和解案は、モラルを喪失した米国経済界の象徴
2006年05月23日 グーグル・アドワーズ広告集団訴訟和解案についての通告についてと2006年05月25日 グーグル・クリック詐欺集団訴訟の和解案についての検討で、2回グーグルのクリック詐欺訴訟の和解案について書きましたが、ついでにもう少し言いたいことがあります。
クリック詐欺とは、クリック数課金方式の広告のヒット数データを不正に操作することです。グーグル自身、クリック詐欺は同社のビジネスにとって非常に大きな脅威である、と認めています。
About invalid clicksには、グーグルは不正クリック問題を深刻な問題として考えていて、優秀な人的資源を割いてこれに対処している。不正クリックの多くは、グーグルの自動フィルターによって、広告主に広告費用として請求される前に排除されている、と書かれています。
しかし、「私がグーグルのアドワーズ広告を止めた理由」で報告したケースでは、図表をご覧いただいても分かりますが、明らかにクリック数に異常が現れたにも関わらず、その異常なデータは請求前に排除されていません。このような明白な異常さえも検出できないのであれば、グーグルの自動フィルターは、（少なくとも半年前の時点では）性能が悪いものであったと断言できます。
今回の訴訟の和解に際して、原告側弁護団に3千万ドル（約33億円）もの大金を支払うことにグーグルが同意したのは、過去においてかなりの不正クリックがあったことを認めていることにもなります。
そうして、本来であれば広告主に返済すべきものを弁護団に支払うことは、弁護団が不当な利得を得ることを認めているわけです。
自己の利益のみを得るために不正なクリックする人、不正クリックという不当な手段から得た利得を、本来返すべき相手である広告主にできる限り多く返済しようとせず、弁護団に不当な利得を与えるような解決をとるグーグルの経営陣、恥ずかしげもなく3千万ドルもの不当利得をむさぼる弁護団。
こうした、信義にもとる行動パターンは、拝金主義そのものであり、アメリカ型資本主義のモラルを喪失した側面の典型的な例といえるでしょう。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (2) | トラックバック
2006年05月30日
さまざまなフォントについての概要
「PDF 千夜一夜」で、グリフ、フォントについての説明を「さまざまなフォントについての概要」としてまとめてみました。
こちらからご覧いただくことができます。
さまざまなフォントについての概要
こうしてみますと、ほとんど、アウトライン・フォントのアウトラインの説明に終わってしまっています。
いづれ、もう少し詳しく検討してみたいと思いますが、現在の時点では、私の知識ではこの程度が限界です。もっと詳しく説明するには、さらなるインプットが必要です。
ところで、今回、連休を機にブログで書いた記事を整理してみましたが、記事のリライトというのは、結構、時間がかかるものです。
ワンソース・マルチユースというのは、言うのは簡単、実践はなかなか難しいという経験を積ませてもらいました。
自分では、まとめる際の手間がかからないように、毎日のブログのお話をうまくつなげてきたつもりなのですが。
投稿者 koba : 08:00 | コメント (2) | トラックバック
2006年05月29日
PDFとFlashの統合？
少し古くなりますが、今年の4月に米アドビシステムズのCEOブルース・チゼン氏が来日し、戦略説明会を行って、今年(2006年)中にPDFとFlashを統合したいと述べたということです。
2006年03月04日 Macromedia吸収後のアドビ、次のステップでも話題にしましたが、アドビがマクロメディアを買収した最大の狙いはFlashです。
一方で、PDFは、サードパーティの無料ソフトの出現と、来年発売されるOffice2007のPDF作成機能などで、このままではアクロバットから得られる収益が先細りになってしまいます。そこで、アドビはこれまで、アクロバットとPDFに独自の付加価値をつける努力を行ってきています。
PDFとFlashの統合が、この二つの戦略の延長上にあるのは明らかです。収益を求めるビジネスとしては、そのような方向は自然でしょう。また、PDFとFlashの統合で、Webの表現力が増すことも期待できます。
しかし、紙を電子化したメディアとしてPDFを考えたとき、Flashとの統合が諸手を挙げて歓迎できるものなのかどうか？
アドビPDFの仕様が、毎年のように改訂され、だんだん複雑になっていくのを見ていますと、これのアンチ・テーゼとして、紙に代わる電子媒体としてのシンプルで使いやすい、新しいPDFの必要性が生まれているのではないか、と思えてなりません。
収益性という観点からは、この新しいPDFが大きな収益を生むものではないとは、思いますけれども。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月28日
サーバサイドPDF (6)
サーバサイドPDF製品にどんなものがあるか、続けて最後まで見ていきたいと思います。
・Server Based Converter V1.2
えー、これはアンテナハウスの製品です。先日までV1.0になっていたのですが、実は一昨日、V1.2に修正しておきました。今日、見ましたらV1.2に更新されています。ですので、PlanetPDFの製品DBに登録すると、直ぐに情報が公開されるようですね。
・SetaPDF-Encryptor
PHPで書かれた、PDFの暗号化用のAPI。40ビットと128ビットの暗号が可能。
・SetaPDF-Stamper
Encryptorの兄弟製品。PDFに対して、テキスト、JPEG、PNGでスタンプ注釈をつけることができる。
・Smart JPrint
米国のActiveTree社の製品で、JAVAでPDFを生成したり、印刷するライブラリーのようです。
・StampPDF Batch
サーバ上でPDFにスタンプ注釈をつけるプログラム。Plug-inですので、Acrobatが必要です。サーバ上でAcrobatのプラグインとして使うソフトというのは既に時代遅れになっているのではないかと思いますが。
・TallPDF.NET
.NETのPDFライブラリー。XMLからPDFを生成します。XSL-FOではなく独自のドキュメント・レイアウト・モデルを使っているようです。
・TWiST
ワークフロー管理用
・UltimatePDF Server
PDF Formによるデータ収集用の製品
・WebCharts3D
2次元または3次元のチャートをPDF形式で生成する。チャートのデータはXMLで記述するか、データベースと接続して取り出すことができる。
・WISeSign PDF
サーバ上でPDFに署名する
・XSL Formatter V3.4
サーバサイドPDFのカテゴリーの最後は、アンテナハウスのXSL Formatter。先日、登録したものが公開されていました。
PlanetPDFのサーバサードPDFカテゴリーに登録されている製品を見てきました。最初、116(現在は、私が一つ追加したので117種類）あるということでびっくりしましたが、よくよく見ていきますと、有力なソフトは意外に少なそうに思います。
もちろん、PlanetPDFに登録されていないものも沢山ありますので、PlanetPDFだけでは動向を語るのは片手落ちでしょう。続けてもう少し調べてみたいと思います。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月27日
サーバサイドPDF (5)
サーバサイドPDFの続きです。昨日は、競合製品が出てきたので、さっそく自社製品を登録したところで終わりました。
・Saffron Document Server
この製品は以前から名前だけは知っていましたが、サーバ上でドキュメントをPDF、HTML、RTF、SVG（予定）に変換するとあります。
驚いたことに、JAVAで書いたPostScript互換インタープリターを持っているとあります。本当でしょうか。JAVAのPostScritp互換インタープリターがあるなんて、初めて見ました。
会社は、Dynalivery Corporation（http://www.dynalivery.com）です。
しかし、webページの情報は、以前に見たときとまったく変わっていません。宣伝文句はすごいですが、売れてるような気配が見えないんですね。
そういえば、5月22日 サーバサイドPDF (2)のArgusは、なかなかすごそうでした。
こんなことが書いてあります。
「ドキュメントとマルチページのTIFFにレンダリングする。動作環境は、Solaris (Sparc), Linux (x86), MacOSX, Windows」とあります。これを素直に解釈しますと、Linux、Solarisで、PDFをTIFFなどの画像にできるということになります。
これはすごいと思って評価版をダウンロードして調べてみたのですが。結果は、
画像をPDF化したものは確かに画像にできるのですが、文書+画像のPDFを変換したところ、
1.PDFファイル内にある画像のみを変換し、ファイルに出力
2.文字列は、テキストファイルとして出力しているが、2バイト文字は無視している
ということでした。
Webの宣伝文句は嘘（？）でした。百聞は一見にしかず、百行のWeb広告は評価版にしかずです。
Windowsであれば、文書(文字)をラスタライズして画像にするのは簡単です。これは、WindowsのGDIが文字のラスタライズ機能を備えているので、Windowsの機能を使えば、ドキュメントの画像化は簡単なのです。しかし、LinuxやSolarisでは文字のラスタライズも簡単ではありません。ですので、ドキュメントの画像化をLinuxやSolarisで実現するのは、簡単ではないのです。
例えば、GhostScriptやGSViewではPDFを画像にできるようです。またハーレクインRIPなどのRIPではできるようですが、それ以外、LinuxやSolarisでPDFを画像化できるソフトは知りません。
Windows以外の環境で、PDFを画像化するのは困難。上に述べたもの以外のソフトでこれができるとすると、すごいということなのですが、いまのところお眼に掛かったことがありません。どなたか、ご存知でしょうか？
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月26日
サーバサイドPDF (4)
サーバサイドPDFの続き。
・PDF Chart Creator Command Line Tool
コマンドラインからチャート（グラフ）をPDF形式で作成するツール。そういえば、最近は、チャートをSVGで作成するツールもあります。MathMLをSVGにするツールもありましたね。
・PDF Command Line Suite
様々なコマンドライン・ツールを集めたもの。
・PDF Library SDK
PDF製品メーカのためのOEM用の部品と書いてあります。こういうのを使うと、PDF製品が直ぐに開発することができます。
欧米のPDF製品を見ていますと、ゼロから自社開発している会社は以外と少なく、OEM調達した部品を使って、商品化しているケースが多いようです。それにしても、PDFについては、部品メーカが多いですが。
・PDF Multi Print Server
アドビのリーダ、またはAcrobatを使って大量のPDFを黙って印刷するツール。
1サーバ495ドル。これは、機能に比べると良い値段に思います。
・PDF Signer Autonomous
PDFにサインをしまくるソフト
・pdf-FieldMerge
PDFのフォームに可変データやグラフィックスをマージ。表計算やデータベースのデータをPDFにマージするソフト
・PDF.net、PDFNet SDK
PDFに関する様々なアプリケーションを作るための基盤になるソフト
・PDFlib Personalization Server
これは、かの有名なPDFLibの製品。
・PDFlib PLOP
PDFlibで作成したPDFをリニアリライズ、最適化、暗号化・暗号解凍など後処理する。
・Prince
XML＋CSSからPDFを生成する。
・PuzzleFlow PDF-Workflow Basic
PDF WorkFlowを構築するためのソフト
・RenderX XEP
XSL-FOからPDFを生成する。弊社XSL Formatter の不倶戴天のライバル。
う～ん、このあたり幾つかライバル製品が出てきます。しかし、XSL Formatterはここには登録されてない。さっそく登録しておかなくっちゃね。
というわけで、今日はXSL Formatter V3.4 を登録しました。ここのシステムは、誰でも製品情報を送信できるようです。編集者がチェックして、1週間以内に公開されるのだそうです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月25日
グーグル・クリック詐欺集団訴訟の和解案についての検討
5月21日に受け取った（グーグルの広告主全員に配布したと思われる）集団訴訟和解案について検討してみました。
まず、この集団訴訟では、2002年1月以降にグーグルからオンライン広告を購入した広告主全てが原告側に参加したことになります。原告側から除外されるためには、通知文を受け取ってから30日以内（消印有効）に下記の住所に自分を除外して欲しいという通知をする必要があります。
Google Settlement Opt Out
c/o Gilardi & Co. LLC
P.O. Box 808070
Petaluma, CA 94975-8070
もし、なにもしないと原告側に参加したことになりますので、今回の和解がどのようなかたちになるにせよ、和解の条件に縛られることになります。すなわち、端的に言いますと、今後グーグルに対して、クリック詐欺についてのクレームを出す権利を失うということです。
さて、今回の和解で一番大きな一人あたり利益を得るであろう人は原告側の弁護団です。原告側弁護団は、最低3千万ドル（約33億円）を得るとされています。
この多額の弁護団への報酬については、Click Settlementに用意されたFAQ（PDF）には書かれていません。
次に利益を得るのは、グーグルでしょう。和解金は最大9千万ドル（約100億円）であり、かつ、広告主への支払いは将来の広告支払額の50%以内のクレジット（割引といって良いと思います）で支払われますので、グーグルにとってはほとんど損失にならないでしょう。
広告主が得る金銭的利益は、和解基金から、弁護団への報酬と、裁判所の費用を除いた金額となります。個別の広告主へは、グーグルの広告収入に対する当該広告主の広告費の構成比で割り当てるようですので、1社あたりでは微々たる金額となるでしょう。
また、当社のように既にグーグルに見切りをつけてしまった広告主は、今回の和解で得るものはありません。
こう見てみますと、この和解案は、グーグルと集団訴訟の原告側の弁護団の間の八百長取引と考えても不思議はないように思います。本当に八百長かどうかは、実態を調べて見なければ判断できないと思いますが、しかし、原告側弁護団への3千万ドルの支払いはどう考えても大きすぎるように思います。
今回のケースでは6月20日までになにも言わなければ、その広告主は、自動的に原告側弁護団を信任したと看做されます。しかし、本来、原告側の弁護団が広告主を本当に代表しているかどうかは、何も言わなければ信任と看做すのではなく、信任投票を行って例えば50%の信任を得たら代表と看做す、あるいは、信任すると意思を表示した人だけを代表するものと看做す、という手続きを踏んで決めるべきことではないでしょうか。このように、私には、この和解手続も間違っているように思うのです。
しかし、反対意見を述べるのも原告側弁護団信任になります。当社の場合、どうやら、集団訴訟の適用除外を要求するしかなさそうです。そうして反対意見はブログで述べるしかないということかな。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月24日
サーバサイドPDF (3)
PlanetPDFに登録されているサーバサイドPDF製品の主なものを紹介しています。
・GhostScript
すでに何度も紹介しましたが、サーバサイドでPostScriptからPDFに変換できます。ライセンシーは世界で80社と書いてあります。
・ImagerSDK Server Based Document Conversion
サーバサイドで、文書変換を行う。DOC, HTML, PDF, XLS, PPTからTIFFなどの形式に変換できる。
当社のServer Based Converterに似てるな！と思ったのですが、製品マニュアルを見ましたら、Nativeのアプリケーションを使って、プリンタ・ドライバで文書を画像化する。検索できない画像ベースのPDFを作るようです。あまりたいしたことのないソフトのようです。
・Jaws PDF Server
PDF作成、最適化、配信用のサーバ。ドラッグ＆ドロップでワークフローを設定できるGUIが特長。Distillerと同じPostScriptペースなのでEPSの処理ができる。また、WordなどのOfficeがインストールしてあれば、プリンタ・ドライバでOffice文書のPDF化ができる。PDF1.4ベース。これは基本的にAdobeの Document Serverみたいなものです。
・jPDF Template, jPDF Merger, jPDF Viewer, jPDF Signer, jPDF Encryption
Crionics社の一連のJAVA用ＰＤＦツール。jPDF Viewer のみデスクトップ用で、他のはサーバサイドもあり。用途は、大体名前からわかりそうですが。
・LuraDocument.jpm PdfCompressor Server
TIFF, JPEG, BMP and PNMファイルをPDF化。テキストをＣＣＩＴＴ Ｇ４形式で圧縮、画像は、JPEG2000/Part 6で圧縮できる。
開発者はドイツの人ではないかと思いますが。ドイツ人的パーフェクトさを感じます。
※参考
ＰＮＭ： Portable aNy Mapの略。モノクローム画像形式 PBM (Portable BitMap)、グレースケール画像形式PGM (Portable Grayscale Map)、カラー画像形式PPM (Portable PixMap) を総称していう。
(続く)
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月23日
グーグル・アドワーズ広告集団訴訟和解案についての通告について
5月21日（日）に、Clicksettlementという団体から 「Important Legal Notice Regarding Your Google AdWords Account（グーグル・アドワーズの口座についての重要なお知らせ）」という電子メールが届きました。
これを読んでみて初めて知ったのですが、アドワーズ広告の不正クリック問題について、米国で、2005年2月に集団訴訟が始まっていたのです。
私は、昨年末から年初にかけて、「私がグーグルのアドワーズ広告を止めた理由」をこのブログで書いた時、グーグルが訴訟される可能性が大きいと思っていました。しかし、どうやら実際の動きの方が早かったということ。
この添付されている通知文によりますと、2002年にアドワーズ広告が開始されてから現在までの全ての広告主は、なにもしないと自動的に集団訴訟の原告側に入ってしまいます。
和解案の大筋は既にグーグルのブログで公開されていました。
グーグルの公式ブログの記事：Update: Lane’s Gifts v. Google
上記の記事に基づく日経BP社ITProの記事：
米Googleのクリック詐欺訴訟，最高9000万ドル分の広告提供で和解
この記事と重複する箇所もありますが、和解案の大筋は次の通りです。
(1)グーグルは9千万ドル（約100億円）の和解基金を作り、広告主にアドワーズ広告が不当にクリックされた分に相当する広告費を無償で提供する用意をする。
(2)広告主は、6月19日から8月4日までの期間に、グーグルが用意したフォームに不当なクリックと思われる額を、申請しなければならない。
とりあえず英語の通告文書をご紹介します（日本語も配布しているとのことです）。
また、詳細情報は下記にあります。
この和解案には、幾つか問題があるように感じますので、もう少し資料を集めて検討してみましょう。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月22日
サーバサイドPDF (2)
昨日の続きですが、サーバサイドPDF製品にどんなものがあるか、PlanetPDFで見てみます。
・ActiveReports for .NET
レポートツールです。一見するとデスクトップ用じゃないかと思いますけど、こういう製品もサーバサイドPDF生成に使われるのでしょうか。
・Adlib Express Server
ドキュメントをPDFやJPEGなどに変換する。
・Adlib Envision OCR
Adlib Express のアドオンツールとして、画像、あるいは画像PDFをOCRして検索可能なPDFに変換する。
・Aloaha PDF Suite (Server Edition)
PDF生成。しおりを編集したり、Fax送信できることなどに特長がありそう。
・AquaPDF Developer Library for Java
JAVAのPDF生成ライブラリー。ローレベルの整形機能をもつ。バーコード作成可。
・Argus
PDF再利用のためのツール。PDFからテキスト出力、画像出力ができる
・ARTS PDF Split Pro
PDFの分割。ページ内容によるインテリジェント分割。分割後のリンクやしおりの情報を保持する。
・CaslonFlow
PDFのワークフローを構築するソフト
・Datawatch|ES
ERPにレポート蓄積・配信機能を付加する。レポートをPDFファイルとして出力できる。
・Elfima Capsule
PDFのメタデータ（XMP）を自動的に取り出すソフト。
・eRez Imaging Server 3.0
イメージを管理して、配布する。ひとつのイメージを多様な目的に使う。
・Evenlogic eForms Server
サーバーサイドのPDF帳票処理。
・FileOpen WebPublisher
サーバ上でPDFを暗号化して配信する。パーミッション（許可）サーバを使って、PDFの閲覧許可制御などができる。アドビのAcrobatが必要。
（続く）
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月21日
サーバサイドPDF (1)
以前にも、PDFLibやiTextを中心に、少し、サーバサイドPDFについて取り上げましたが、今度は、少し本格的にサーバサイドPDFについて考えてみたいと思います。
企業内システムやグループウエアなどもデスクトップからサーバサイド中心のシステムに移ることで、PDFの作成もかなりの部分がデスクトップからサーバサイドに移っているようです。
これに対して、リッチクライアントという動きもありますので、リッチクライアントとPDF作成という課題も考えられます。まあ、それはそれとして、今回は、サーバサイドという点を中心にします。
サーバサイドPDFに使われる製品は、それこそ星の数とは言いませんが、数え切れないほどあるように思います。
2005年10月24日 PDFソフトの種類を覚えていますか？ここで、PlanetPDFに登録されているPDF関連ソフトの分類に、サーバサイド：100種類と紹介しました。
約半年過ぎた今では116件に増えています。半年で16%の増加ということになります。ここに登録されているのは極一部でしょうから、恐らく数百種類はあるのではないでしょうか。
どんなものがあるか、ざっと挙げてみます。製品名の50音順です。
・3-Heights™ PDF Analysis & Repair Service
フォルダーに入れられたPDFを解析して、問題があるものを修正する。
・3-Heights™ PDF Optimization Service
フォルダーに入れられたPDFをWeb最適化、サイズの圧縮、印刷用に最適化する。
・3-Heights™ PDF Security Service
フォルダーに入れられたPDF暗号化したり、暗号を解いたりする。
・3-Heights™ PDF to Image Converter
PDFを画像に変換する。
※Antenna Houseでも同じものがあります。
・3-Heights™ Image to PDF Converter
画像をPDFに変換。
・3-Heights™ PDF Extract Tool
PDFから様々な要素(テキスト、画像など）を取り出し
・3-Heights™ PDF Printer Service
監視フォルダーに入ってきたPDFを印刷する
・activePDF Server
PDF生成を自動化するサーバ。COMとWindowsNTサービスを使用。
・activePDF DocConverter
フォルダを監視して、入ってきたOfficeファイルなどをPDF化。activePDF Serverのアドオン。
・activePDF Printer
activePDF Serverのアドオン。PDFを木目細かく出力描ける。
・activePDF WebGrabber
activePDF Serverのアドオン。HTMLからPDF化を行う。
・activePDF Toolkit
分割・結合・スタンプなど。アンテナハウスのPDF Tool APIに似てます。
まだ2社ですが、こうしてみますと、海外のPDF製品ベンダは、PDF関連製品の品揃えをしていますね。(品揃えは海外だけじゃないでしょうけど）。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月20日
XSL Formatter V4 βリリース
弊社では、新しい XSL-FO 仕様である XSL 1.1 (Extensible Stylesheet
Language (XSL) Version 1.1) に対応した XSL Formatter V4.0 の発売を予定しております。つきましては、それに先立ち、βバージョンを公開し評価していただくことにしました。
XSL Formatter V4.0 では、次のような新しい機能がつきました。
１．Extensible Stylesheet Language (XSL) Version 1.1 に対応しました。
２．PDF1.6の出力ができるようになりました。
３．次の種類のPDF/Xが出力できるようになりました。
* PDF/X-1a:2001 (ISO 15930-1:2001)
* PDF/X-3:2002 (ISO 15930-3:2002)
* PDF/X-1a:2003 (ISO 15930-4:2003)
* PDF/X-2:2003 (ISO 15930-5:2003)
* PDF/X-3:2003 (ISO 15930-6:2003)
４．タグ付きPDFに対応しました。
５．40言語以上のハイフネーション処理に対応したハイフネーションオプションが標準機能となりました。
６．「XSL Formatter チャートオプション」により、Microsoft(R) Excel のチャートを描画できるようになりました。チャートの描画では、Excelを使用しませんので、Linux、Solarisなど、Windows以外の環境でもExcelと互換のチャートの描画ができます。
７．hyphenation-keep、keep-* の
８．以下の拡張プロパティが新設されました。
・axf:hyphenation-minimum-character-count
・axf:printer-marks-line-length
・axf:printer-marks-zero-margin
・axf:repeat-page-sequence-master
９．GUIで次の機能がつきました。
・浮動定規を表示して、組版オブジェクトの寸法を画面上で測定できるように
なりました。
・連続ページ表示ができるようになりました。
【ご注意】
XSL1.1 は、現在、勧告候補の段階です。これが勧告となるときに仕様変更の可能性があります。 XSL1.1 が仕様変更された場合は、XSL Formatter も勧告に合わせて仕様変更した版を速やかに出荷する予定です。
詳しくはこちらをどうぞ。
XSL Formatter V4.0 β1 公開中！
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月19日
セミナー ご参加ありがとうございました
今週は、17日に「XMLデータベース＆XSL Formatterによるシステム事例紹介セミナー」(メディアフュージョン様と共催）、18日に新製品セミナー（デジタルコミュニケーションズ様と共催）と2日連続でセミナーを開催しました。
両日とも、セミナールーム満員のご参加を賜りました。ご参加いただいた多くの方々、お話をいただきました方々に、改めてお礼申し上げます。
XSL Formatter関連の話題が全体の7割近くなりましたが、「PDF Tool V2」についてもご紹介のお時間をいただくことができました。
ところで、18日冒頭に、簡単にご挨拶させていただきましたが、そこで、お話したかったことの要点につきまして、以下に紹介させていただきます。
----ここから----
アンテナハウスは、1984年創立ですので、今年で23期目になります。23年経過したのにもかかわらず、会社の規模があまり大きくなっていないことにつきましては、私の力不足を感じています。さて、20年ほど前と比べて、ソフトウエア製品の環境変化は隔世の感があるように思います。これに関しまして、最近のふたつのキーワードを挙げてみます。
第一のキーワードはオープンソースです。オープンソースの台頭により、商用ソフトウエアを開発して、ライセンスを販売するというビジネスモデルはもう衰退するのではないか、と良く耳にします。
第二はソースネクストを初めとするソフトウエアの低価格化、さらには、Googleがやっていますが、ソフトウエア無償化という動きがあります。エンドユーザ向けのデスクトップ・パッケージはもう売れないのではないか、という声を聞きます。
このふたつは、ソフトウエア・メーカの経営という観点からは、いづれも非常に大きな課題です。これに関しまして、私は次のように考えています。
第一点では、オープンソースに負けない商用ソフトウエアを作らねばならない。そうして作れば売れるというということです。これにつきましては、XSL Formatterの競争相手に、類似機能をもつFOPというオープンソースがあります。しかし、実際にFOPを使ってシステムを作ろうとして、うまくいかず、XSL Formatterを採用していただくケースが相次いでいます。このことは、無償のオープンソースと競争しても、高額の商用ライセンスを売ることが可能である、ということを証明できていると思います。
第二の点につきましては、仮にパッケージ1本の付加価値が1,000円であったとして、日本の市場であれば、1万本販売して、付加価値1,000万円にしかなりません。しかし、世界の市場は日本の市場の10倍の大きさがあります。世界の市場で販売できる製品を作って、10万本売ることで低価格化の波を乗り切ることができると考えます。弊社は、このために世界で最も優れたソフトウエアを作り、世界の市場で売る、ということに挑戦していきたいと考えています。
---ここまで---
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月18日
PDFからテキスト抽出のために ToUnicode CMap
PDFにおけるフォントの取り扱いに関連して、ToUnicode CMapというものがあります。今日はこれについて説明します。
アウトライン・フォントについての説明でお分かりいただけたかと思いますが、PDFにアウトライン・フォントを使って記録された文字を表示する仕組みは、フォントの中にあるグリフのアウトラインをラスタライザで可視化することになります。
これに対して、もう一つのPDFの利用方法として、PDFを読み上げたり、あるいは、検索エンジンで検索したり、あるいはテキスト情報を取り出して他のアプリケーションで使用する、などが考えられます。
通常、上で述べたような処理にはテキストが必要です。テキストについては、2005年12月15日 PDFと文字（4) – 文字の取り扱いで説明しましたので、初めての方は12月15日の話をお読みになってみてください。
PDFの中では、文字を可視化するための情報が入っているのですが、可視化するための情報からテキストを取り出す方法には幾つかあります。
ToUnicode CMap（オプション）は、このための手段の一つとして用意されているものです。
CMapについては、2006年01月17日 PDFと文字 (25) – CMapで文字コードからCIDへ変換で説明しましたが、通常は、文字コードからアドビが定義した、CIDに変換する用途で使います。
ToUnicodeCMapは、CIDへの変換ではなく、PDFの中に入っている表示用の文字列情報をUnicodeに変換するためのテーブルです。CMapの仕様に準拠して作成されています。
PDFの中の情報をUnicodeに変換する方法は他にも幾つかありますが、ToUnicodeCMapは最優先で使われます。また、CJKのTrueTypeを埋め込んでいる場合、ToUnicodeCMapがないとUnicodeテキストを利用できないと思います。これを用意するのは、PDFを作成する生成ソフトの責任です。
投稿者 koba : 08:00 | コメント (1) | トラックバック
2006年05月17日
さまざまなPDFの作成技術の概観
主に、「PDF千夜一夜」でPDFの作成方法のカテゴリーの話題を集めて整理してみました。
こちら「さまざまなPDFの作成技術の概観」でお読みいただけます。
整理の過程で、まだ、書き足らないことが多いな、と感じました。
現在は、デスクトップPDFよりもサーバサイドでのPDF生成が重要な課題になっているように思います。
しかし、ブログでは、サーバサイドPDFの作成については中途半端な状態になっていたように思いましたので、全部削除してしまいました。
近いうちに、サーバサイドPDFについて、少し調べてみようと思っています。
投稿者 koba : 08:00 | コメント (1) | トラックバック
2006年05月16日
PDFとフォント(29) エレメント方式フォント
アウトラインフォントのお話は、ほとんど、アドビシステムズが開発したフォントと、Microsoftが開発したフォントで終始してしまいました。
しかし、他にフォントがないのか？と言われるとそのようなことはないでしょう。
他の方式のフォントがないのか、とWebを探していましたら、リコーのエレメント方式フォント（（JetFont)というものが見つかりました。
これは、文字を書き表すストロークを、約700種類に分類しておき、そのストロークを組み合わせて文字を表す仕組みです。
詳しくはエレメント方式フォントのWebページをご覧ください。
漢字のように何万種類もの文字があるときは、小さな部品から組み立てていく方式は、有効なように思います。JetFontは漢字だけではなく、ラテン系の文字やハングルなども文字として用意しているようです。
このフォントは、フォントデータとラスタライザ(ソースプログラム）で提供されるようですので、Linuxなどにも載せて使えそうです。
PDFに使うのはどうなんでしょう？PDFの仕様を拡張しなくてもPDFに埋め込んで使えるのかな？フォントのラスタライザが問題ですが、こういう技術をPDFと一緒に使えるようにしていくと、マルチプラット・フォームのPDF配信ができるようになるかもしれません。
大いに期待したいものです。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月15日
オープンソース・ビジネスについて考える
XML資料室に、「オープンソース・ビジネスについて考える」という文書を公開しました。
これは、「PDF千夜一夜」の2006年03月25日から2006年04月13日のでのお話を元に、オープンソースのビジネスモデルについて整理してみたものです。
ブログをもとに、読みやすく、分かりやすいように再構成したものです。参考にしていただければ幸いです。コメントもお待ちしています。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月14日
サーバベース・コンバータ V1.2 Mｒ2ｃをリリース
5月12日夜サーバベース・コンバータV1.2 Mr2cをリリースしました。
MRというのは、メンテナンス・リリースの略で、主にバグ・フィックスを目的としたリリースです。
但し、今回は、Microsoft Word文書の解読・組版処理を見直し、高速化を行いました。これにより、文書によりますが、入力からPDF出力までに要する時間が半分以下に短縮されたものもあります。
ちなみに、PDF Tool Driver APIとサーバベース・コンバータ（SBC)で同じ文書をPDF化してその処理に要する時間を比較すると次の図のようになります。
Word-A(13ページ）は、PDF Tool では約20秒に対し、SBCでは約4秒でPDF化できます。SBCの方が1/5の処理時間。ところが、Word-B（14ページ）は、PDF ToolもSBCも共に8秒程度ということでWord文書はまだばらつきがあり、改善の余地があるようです。
これを見ますと、SBCの方が、PDF Tool を使うよりも、一般に数倍高速になります。それは、下の説明にありますように、Microsoft Officeを起動してOfficeをCOMを使って自動的に動かすという方法と比べて、SBCの方法の方が早いという方法の違いによって生まれるものです。将来性を考えてみても、Office文書のPDF化を高速にしようと思っても、Microsoft Officeに依存する限り、Microsoft頼みになりますので限界があります。これに対して、SBCの方が、自力で改善できるという良さがあります。無論、自力でMicrosoftよりも良いプログラムができる、ということが前提になりますが。
【説明】
・SBCでは、Office文書を独自に解読して、ページネーション処理を行い、処理結果をPDFにしています。
・PDF Tool Driver APIを使う場合は、入力された文書の種類を判別して、該当するMicrosoft Officeのアプリケーション（例えば、Word文書であれば、Micorosoft Word）を起動して、そのアプリケーションにPDFをDriverを経由で印刷させます。
【比較方法】
両方ともコマンド・ラインから使用しました。ちなみに、コマンド・ラインは次の通りです。
・SBCのコマンドライン
sbccmd -d （変換元ファイル・パス） -p @PDF -o （出力PDF・パス） -pdfver 1.5 -pea -prr 300
・PDF Tool （V1.0)のコマンドライン
AHPDFToolCmd -convertFile -in （変換元ファイル・パス） -o （出力PDF・パス）
*ドライバ設定で、解像度、フォント埋め込みなどはSBCと同等に設定。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月13日
PDF/X カラー印刷はじめの一歩 展示会出展など
もう、来週の月曜日になってしまいましたが、日本印刷技術協会（JAGAT）において
５月１５日（月）10:30-18:00 イベントセミナー「PDF/Xカラー印刷はじめの一歩」が開催されます。
アンテナハウスも、今年の4月から、PDF/X-PlusJ推進協議会に参加しました。そして、このイベントセミナーと併催のミニ展示会に出展します。
ミニ展示会では、PDF/X対応版PDF生成ライブラリーを紹介させていただく予定ですが、実際は、そのライブラリーを使ってPDF/X出力をする XSL Formatter の新バージョンのご紹介になります。
弊社では、XSL FormatterV4.0を近日発売の予定ですが、XSL Formatter 4.0で、（漸く！）PDF/Xに準拠したPDFの出力を可能とします。
これまで、XSL Formatterのお客様からPDF/Xに対応してほしいという要望が多く寄せられていました。また、海外の競合製品でもPDF/X対応で先行されていたこともあり、私としては早く対応したいと強く希望していたのですが、ようやく、リリースできる運びになり、一安心です。
XSL FormatterのPDF出力は、自社開発のPDF生成ライブラリーを使っているのですが、今回、PDF生成ライブラリーに、PDF/X準拠のPDF出力機能を追加したことになります。
さらに、できるだけ早く、PDF/X-PlusJなどにも引き続き対応していきたいと思っています。
どうぞ、よろしくお願いします。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月12日
日・英・中 ビジネスレター・Eメール ハンドブック
弊社の顧問 田中則明先生が、このほど、次の本を出版されました。
「日・英・中 ビジネスレター・Eメール ハンドブック」
田中 則明 他著、B5版 本文149ページ、定価1,470円（税込）、心弦社発行、ISBN4-901278-11-8、2006年5月1日刊
この本は日本語、英語、中国語を使って、国際的なビジネスレターを書く人のためのテキストブックです。
日本語のみ、あるいは英語、恐らく中国語も、それぞれの国内向けのみならば、手紙の書き方の例文集は沢山あると思います。
それに対して、この本には、通常の例文集と違う大きな特徴があります。それは、ひとつには日本語、英語、中国語の3ヶ国語の例文が並列になっているということです。
それだけではありません。さらにすごいのは、日本語のビジネスレターを作成する要領で、日本語のパラグラフを選択して順番に並べていくと、英語や中国語のビジネスレターもできてしまうという仕組みになっています。英語や中国語が殆ど分からなくても、日本語の手紙を書く要領で、英語、中国語の手紙もできてしまうなんてすごい！
私にとりましては、中国語の手紙を書く機会は多分やってこないと思いますが、英語の手紙やe-メールはかなり頻繁にやり取りしていますので、重宝しそうです。いままで、かなり自己流で恥ずかしい手紙を一杯書いていましたので、この本で、少し、精進しようかと思っているところです。
5月18日に、このテキストを使用して「ビジネスレターを書く」コース（全１回）をアンテナハウスのセミナールームで開催します。
詳しくはこちら（「１００万人の中国語」コースのご案内）をご覧ください。
心弦社
http://homepage3.nifty.com/shingensha/
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月11日
PDFとフォント (28) フォント技術の将来
こうしてみますと、アウトラインフォントの技術については、アドビシステムズとMicrosoftがほとんどを握ってしまっているように思います。
アウトラインフォントを使う場合、困るのはフォントデータとラスタライザがセットでないと役に立たないということがあります。フォントデータの方は、フォントベンダがまだ沢山ありますし、ツールを使えば新しいフォントを作り出すことはできます。
問題はアウトラインフォントのラスタライザです。例えば、OpenTypeを例に取りますと、TrueTypeアウトラインと、CFF/Type2アウトラインの2種類があります。OpenTypeを可視化するには、その2種類のフォントのラスタライザが必要です。
OpenType の仕様書には、
---引用開始---
PostScript data included in OpenType fonts may be directly rasterized or converted to the TrueType outline format for rendering, depending on which rasterizers have been installed in the host operating system.
---引用終了---
OpenType Overview
と書いてあります。つまり、PostScriptアウトラインは、TrueTypeアウトラインに変換してラスタライズできると。これが事実ならTrueTypeのラスタライザのみで良いのですが。しかし、これは、多分近似的にできるということで、完全にはできないでしょう。3次元のベジエ曲線を2次元で表現するのは不可能なはずですから。
Windowsで文字を表示するのであれば、ラスタライザはMicrosoftとアドビが提供しているので問題ないのですが、Windows以外のOS、例えば、Linux、あるいは、もっと離れて、携帯電話などで表示しようとするとラスタライザがないということが大きな問題になると思います。
PDFにフォントを埋め込むと、表示環境にフォントがなくてもPDFを見ることができる、と言われます。しかし、PDFに埋め込まれているのはラスタライズした（可視化した）文字ではなく、フォントのアウトラインデータです。
従って、表示環境にラスタライザがなければ、PDFにフォントが埋め込まれているとしても、その文字を表示することはできません。
OpenTypeが普及した場合、上のことは相当に大きな問題で、Microsoftまたはアドビの協力がなければ、PDFを表示することができないということになりかねません。このあたり、将来、どうなるのか？不安を感じるところです。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (2) | トラックバック
2006年05月10日
XSL・PDF新製品 無償セミナー
アンテナハウスでは、5月18日（木）に、新製品のご紹介セミナーを開催します。
今回のセミナーは、次のように二部構成で行います。
１．第一部（14:00～15:30）
・ XSLFormatterV4とXSL1.1のご説明
・ PDFToolV2のご説明
２．第二部（15:30～17:00）
・デジタルコミュニケーションズ様 Word2XMLのご説明
・XSL標準出版システムについてご紹介
XSL-FOの仕様はV1.1の策定が進んでおり、現在、V1.1は勧告候補となっています。アンテナハウスでは、XSL-FO V1.1準拠のXSL Formatter V4.0を近く出荷開始します。第一部では、この新しいXSL Formatterについて紹介します。
また、PDF Tool の新版V2.0につきましてもご紹介します。
第二部は、デジタルコミュニケーション様のご協力で、Microsoft WordをXML編集ソフトとして使って、XMLを作成するWord2XMLの紹介をします。さらに、Wordで作成した文書をXMLとした上でPDF化する「XSL標準出版システム」について、デモを交えて紹介いたします。
セミナーの開催概要は以下の通りです。ぜひ、お時間をお繰り合わせの上、ご参加ください。
○開催日・時間
2006年5月18日 木曜日 14:00～17:00 (開場13:40～)
○開催場所
アンテナハウス株式会社 本社セミナールーム
東京都千代田区九段南4-3-13麹町秀永ビル4F
地下鉄「市ヶ谷」駅 （都営新宿線/営団有楽町線/営団南北線）
A3出口より徒歩２分
JR「市ヶ谷」駅下車 徒歩５分
○参加資格・費用
どなたでもご参加いただけます。参加費用は無償です。
○お申し込み
参加申込書（PDF 53KB）
○Webページ
アンテナハウス「新製品紹介セミナー」ご案内
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月09日
PDFとフォント (27) OpenTypeによるグリフのレイアウト
OpneTypeでは、OpenTypeレイアウトというコンセプトを持っています。
OpenTypeレイアウトは、フォントファイル中には特性テーブル(feature table)として用意されます。
これは、グリフを行にそって配置していく際に次のようなことを行うためのものです。
・複数のグリフのリガチャ、文字の位置によるグリフの変化など。
・文字の配置方法に依存するグリフの入れ替え
・2次元平面上でのグリフの配置、グリフの付加
例えば、日本語ですと縦書と横書での句読点、括弧類の形の入れ替えたり、アラビア文字では、単語の中での文字の位置により、グリフの形が変わります。アラビア文字については、
2006年01月19日 PDFと文字 (27) – アラビア文字の扱い
～
2006年01月22日 PDFと文字 (30) – アラビア文字Harakatの結合処理
あたりをご参照ください。
OpenTypeレイアウトには次のような幾つかの共通テーブルがあります。
・BASE ベースラインについてのデータ
・GDEF グリフの定義データ
・GPOS グリフの配置データ
・GSUB グリフの入れ替えデータ
・JSTF グルフの均等配置のためのデータ
文字・言語によってそれぞれのテーブルの中に用意されているデータを使って、グリフに対する操作・配置を行うことができます。
フォントファイルから取り出したグリフの操作や配置は、WindowsではUniscribeというグリフ・レイアウト・エンジンを使って行うことができます。もちろん、アプリケーションが自前のグリフ・レイアウト・エンジンを使用することも可能です。
ちなみに、アンテナハウスのXSL Formatterでは、アラビア文字、ヘブライ文字、タイ文字などについては、自前のグリフレイアウト・エンジンを使ってグリフの配置を行っています。
現在は、クメール文字やデバナガリ文字はWindowsのUniscribeに頼っています。しかし、Windowsに頼っていると、Unix、あるいはLinuxで同じ機能を実現できませんので、将来は、これらの文字も自前で処理したいものです。
このようにOpenTypeのレイアウト・テーブルを使うことで、組版ソフトなどのアプリケーションが高度なタイポグラフィを実現することができます。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月08日
GB18030の法的拘束力とは？
2006年01月16日 PDFと文字 (24) – Adobe-GB1, Adobe-CNS1, Adobe-Korea1で、Adobe-GB1が、GB18030-2000をカバーしていないと書いて、小川創生＠檸檬の家さんに間違っていると指摘されました。（随分前の話ですみません）。
Adobe の GB18030 対応をご参照ください。
確かに、Adobe-GB1には、GB18030をサポートすると書いてありますので、私が間違っていたように思います。
で、ついでなので、この機会に、かねてから疑問に思っていたことを書いておきます。
それは、「GB18030-2000」が法的拘束力をもつとは、どういうことなのか？ということなんですが、この数年間、ずっと疑問のまま。
私の疑問は、次の点です。
１．GB18030-2000って、文字の符号化方式の標準じゃないの？
２．しかし、実際のところ、GB18030-2000サポートという課題を、グリフの認定という課題に、問題をすり替えているんじゃないの？
ということです。もう少し説明しますと、
・GB18030-2000は、文字の符号化方式と理解しています。
-そうなりますと、これを、サポートするとは、OSやアプリケーションの内部コードで使えってこと？それとも、変換テーブルを用意して入出力できれば良いってこと？一体どちらなんだろ？
・GB18030-2000仕様書では、表の一部に、実際の文字の字形が印刷されています。残りの表には、Unicodeのコードポイントが書き込まれているのみです。
- GB18030-2000のコードポイントは160万以上。そのうち字形が印刷されているのは、28,522に過ぎません。(自分で数えたわけじゃないですが）。
- そうすると、符号化方式はどうでも良くて、仕様書で字形が印刷されている文字は、使えるようにせよ、ということ？
・ビットマップフォント標準字形の国家規格というのがあり、GB18030に対応するビットマップフォントというものが売りだされています。
- これは、グリフを規定しているものではないのでしょうか？グリフの国家規格とGB18030の法的拘束力というのは別の問題だよね。
情報機器などでは、内部文字コードにUicodeを使っているものがあります。この様な機器で、GB18030に対応するビットマップフォントを使うには、買ってきたビットマップフォントをUnicode順に並び替えることが必要です。そうすると、並び替えたものはGB18030に対応するビットマップフォントではなくなるのかな？
・今回の話で新たに沸いた疑問として：AdobeのCIDというのは、文字のグリフを集めてきたもの。フォントベンダがCIDに対応するフォントを作るときは、CIDのグリフを参考にして、自分達で新しくデザインしたグリフセットを作成する、という目的で用意されているものと理解していました。
しかし、
---引用ここから---
The typeface used to illustrate each character in this section is STSong™ Light, a product of Changzhou SinoType Technology Co., Ltd. STSong Light is certified by the Press and Publication Administration of the People’s Republic of China, the China State Language Commission, and the National Typeface Committee; and is recommended for use in official and professional publications.
---引用ここまで---
Adobe-GB1-4 Character Collection for CID-Keyed Fonts
(強調は筆者による）
というのは、CIDの趣旨に根本的に背反するのではないでしょうか？
投票をお願いいたします
投稿者 koba : 08:00 | コメント (2) | トラックバック
2006年05月07日
PDFとフォント (26) フォントファイルとしてのOpenType
次にOpenTypeのフォントファイルとしての主な特徴について整理しておきます。
１．グリフのアウトライン記述形式
OpenTypeのグリフアウトラインは、TrueTypeアウトラインと、PostScriptアウトラインのどちらかを使用できます。PostScriptアウトラインは、CFF/Type2形式です。
なお、アウトライン形式に加えて、ビットマップのグリフを含めることもできます。
OpenTypeフォント・ファイルの拡張子は次のようにつけます。
・TrueTypeアウトラインの場合：.OTF、または、.TTF（過去のシステムでも使用可能にしたいとき）
・TrueTypeコレクションの場合：常に.TTC
・PostScriptアウトラインのみを含む場合：.OTF
２．cmapテーブル
フォントを使用するアプリケーション・OSで使う文字コードからグリフ番号（GID）への対応表をcmapと言います。TrueTypeと同じものと思います(推測）。
cmapは、一つのフォントファイルに複数のテーブル(cmapサブテーブル)を持つことができます。
サブテーブルは、プラットフォームID（Windows：3、Macintosh:1）と、プラットフォーム毎の符号化方式（2バイトのUnicode:1、4バイトのUnicode:10など）の順で並べます。フォントファイルに様々なOS別のサブテーブルを用意することで、一つのOpenTypeフォントをマルチ・プラットフォームで使えることになります。
cmapサブテーブルは7種類（Format：0, 2, 4, 8, 10, 12）あり、各サブテーブルの先頭に該当する種類がセットされます。
Unicodeサポートについて
UnicodeからGIDへのcmapサブテーブルは、次の3種類が使えます。
・Format4：[U+D800 - U+DFFF] (サロゲートペア)以外のUnicode領域をサポートする文字コードからGIDへの対応表（Microsoftの標準）
・Format8：16ビットと32ビット混在。サロゲートペアの文字コードは32ビット。それ以外が16ビット。
・Format12：32ビット固定長（UCS-4）の表。（サロゲートペアをサポートする時のMicrosoftの標準）
なお、サロゲートペアをサポートできるのはWindows2000以降ですが、サロゲートペアをサポートするOpenTypeフォントは、過去のOSでも使えるようにするためFormat4のcmapサブテーブルも用意しておかなければなりません。
【注意】
このように、cmapはUnicodeの全領域をサポートできそうに見えますが、OpenTypeのひとつのファイルに収容できるglyphの数は64k（65,536個）とされています。従って、UnicodeV4で定義されている全文字をひとつでサポートするOpenTypeフォントを作ることはできません。Arial Unicode MSの最新Unicode全文字版はできないということになりますね。
※参考資料
OpenType specification
特に
cmap - Character To Glyph Index Mapping Table
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月06日
PDFとフォント (25) OpenType
さて次は、いよいよ真打OpenTypeの登場です。OpenTypeという名前は、既に何回か出てきました。
ここでは、フォントファイル形式としてのOpenTypeとそれがPDFでどのように扱われるかについて検討してみましょう。
いままで延々といろいろなフォントの形式を説明してきましたが、これはすべて、本命であるOpenTypeの説明をするための準備をしてきたようなものです。
【歴史】
OpenTypeは、最初Microsoftによって、TrueType Open として開発されました。その後、1996年にアドビが開発に参加、1997年4月に共同で発表されました。
Adobe Systems and Microsoft Deliver OpenType TM Font Specification
1990年代前半まで、アドビのPostScript Type1フォントと、マイクロソフト/アップルのTrueTypeという2大アウトライン・フォントがしのぎを削るという状況でした。この両陣営が協力してOpenTypeというフォントファイル形式を開発したのは、アウトライン・フォントの歴史上では、非常に大きなできごとと思います。
OpenTypeは、TrueTypeとType1フォント技術の後継として位置付けられています。
また、OpenTypeは、現在、ISOで標準化が進んでおり、新しい標準は、OpenType 1.4で、ISOで名前を変更して"Open Font Format"になるようです。2006年終わりに最初の版が出ると期待されています。
【普及の見通し】
アウトライン・フォントの普及には、フォント制作者が提供するフォントファイルと、それを使うアプリケーション、フォントファイルからアウトラインを取り出してグリフを可視化するラスタライザの3つが大きな要因となります。
OpenTypeはもともとTrueTypeの延長として開発されていますので、TrueTypeフォントの多くについては、大きな変更なく使用できるだろうと思います。これに対してアドビはType1フォントを全てOpenType形式に変換し、OpenTypeフォントに集中しています。
Wikipediaの記事では、2005年の末で、10,000種類のOpneTypeが入手できるそうですが、このうち1/3がアドビのものと推定しています。やはり早く手がけたものが有利ということでしょうか。
いずれにしても、フォントファイルの供給という面からは、今後、OpenTypeが圧倒的に増えるだろうと予想できます。
【参考資料】
Wikipedia OpenType
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月05日
PDFとフォント (24) CID-Keyedフォント（PDF)
PDF ReferenceにもCID－Keyedフォントの説明があります。
5.6.1 CID-Keyed Font Overview
PDF Reference V1.6 pp.403 -405
ここを読みますと、昨日、説明しましたPostScriptを想定するCID-KeyedフォントとPDFのそれでは微妙に違いがあることがわかります。
まず、PDF Referenceではフォントをsimpleフォントとcompositeフォントの二つに大別しています。simpleフォントとは1バイトフォント、compositeフォントとは複数バイトのフォントです。
2006年05月03日 PDFとフォント(22) Type0 フォントでも説明しましたが、PDF Referenceでは、compositeフォントのことをType0フォントと言い、具体的にはCID－Keyedフォントのみ使うことができます（OCFはサポートされていない）。
PDFのCID-Keyedフォントは次のものから構成されます。
・CID
・CMap
・CIDFont
(1) CIDは、昨日説明しましたPostScriptと同じものです。
(2) CMapも同じような役割なのですが、PDFでは少し機能を限定しています。
(3) 一番の違いはCIDFontです。PostScriptの時とは違い、PDFではCIDFontにはType0とType2の２種類があります。
・CIDFont Type0は、アドビのType1フォントの形式でグリフを記述したもの
・CIDFont Type2は、TrueTypeフォントの形式でグリフを記述したもの
PDFでは、1バイトのTrueTypeフォントをsimpleフォントの1種類として扱い、CJKなどの複数バイトのTrueTypeフォントは、compositeフォントとして、Type0フォントの仕組みを使って扱っているということになります。
この影響でPDFではCMapによるグリフ選択の仕組みも、PostScriptのCID-Keyedフォントとは少し異なっていて、TrueTypeの取り扱いが追加されます。このあたりは細かい技術的な話ですので省略します。
このことは、1バイトのTrueTypeフォントと2バイトのTrueTypeフォントが、AcrobatのPDFのフォント・プロパティ情報で、表示が違うことからも確かめることができます。
※Acorbat Standard 6 (英語版）による
上の画面の例ではTimesNewRoman（1バイト）のタイプはTrueTypeですが、MS明朝（2バイト）のタイプはTrueType(CID)となっています。
私としては、いままではTrueTypeにCIDなんてないのに「おや？おかしいな。」と思っていたのですが、漸く、わかりました。
※このあたりはアドビの手抜きじゃないかなと思うのですが。ま、こんな細かいことに文句言うのは日本人だけかもしれませんね。
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月04日
PDFとフォント(23) CID－Keyedフォント (PostScript)
CID-Keyed フォントは、PostScript Type1形式の複合フォントとしてOCFの後継として規定されました。
CJK /CID-keyed fonts CID フォントに関する一連の仕様
CIDフォントの構成要素は、次のものです。
・CID文字集合
・CMapファイル
・CIDフォントファイル
(1) CID文字集合
日本語、中国語（繁体字、簡体字）、韓国語についてグリフを集めてCID番号をつけたものです。これについては、既に2006年01月15日 PDFと文字 (23) – Adobe-Japan1、2006年01月16日 PDFと文字 (24) – Adobe-GB1, Adobe-CNS1, Adobe-Korea1で簡単に紹介しました。
(2) CMap
さまざまな符号化文字集合の文字コード番号から、CIDへの対応表です。アドビが用意した標準のCMapは無償配布されています。フォントベンダなどが独自に定義することもできます。
これについても、既に、
2006年01月17日 PDFと文字 (25) – CMapで文字コードからCIDへ変換で説明しました。
(3) CID フォントファイル
これは、フォントのグリフを記述するプログラム（データ）を収録したファイルです。フォントベンダが開発するものです。Type1のグリフアウトライン形式と互換の形式になっていて、Adobe Type ManagerやPostScriptインタープリタで解釈してラスタライズすることができます。
CID-Keyedフォントを表示・印刷する仕組みの一部は2006年01月17日に示しましたが、CMapを使って、文字コードからCIDに変換し、CIDをキーにして、文字のグリフを取り出し、そのグリフをラスタライズするものです。
CID-Keyed Font Technology Overview Technical Note #5092にはCIDフォントの特長として次のようなことを挙げています。
・CMapファイルを使って、複数のCID-Keyedフォント、OCFフォント、Type1、Type3フォントを参照して使える。
・文字を追加して、拡張していくのが簡単。
・Type1よりフォントを取り出してラスタライズするのが速い。
・広範な機器に使える。
・OCFと比べてフォントのファイル数が少なくて済む。コンパクトになる。
など。
基本的にCJK用なので日本のフォントベンダもCIDフォントを多数出しています。
CIDフォントにモリサワの報告があります。OCFからCIDへの移行で細かいことでかなりいろいろな問題を経験しているとのこと。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月03日
PDFとフォント(22) Type0 フォント
Type0フォントは、複合（Composit)フォントと言い、もともとはPostScriptの仕様書で定義されている、複数のフォントを束ねて高度なフォントを作る仕組みです。
Type1フォントは1バイトでローマ字用のもののため、CJKの文字を扱えませんでした。そこで、アドビはType0フォントの仕組みを利用して、OCF（Original Composite Font)を開発し、さらに、その後CID-Keyedフォントを開発しました。
このうち、OCFフォントはPostScriptでのみ使えるもので、PDFの仕様ではサポートされていません。
この記事を読みますと、OCFフォントは、日本のDTP分野で一時代に流行(という言葉が適切かどうかわかりまえせんが）したものですが、既に、フォント・メーカはサポートを終了してしまっているようです。Mac OS Xではインストールさえもできないとあります。PDFの仕様書を検索しても、OCFという言葉は一言も出てきません。
CID－Keyedフォントの概要は次に説明があります。
CID-Keyed Font Technology Overview Technical Note #5092
PDFで使えるのは、CID-Keyedフォントのみに制限されています。
PDF Reference V1.6
5.6 Composite Fonts (p.403)を参照。
PDF Referenceでは、composite font = Type0 フォント= CID-Keyedフォントとなっています。しかもcompositの意味が、1バイト以上の並びを解読して、CIDfontからグリフを選択する仕組みという意味になっていてPostScriptとは異なっています。
さて、ややこしいことに、PDF ReferenceのCIDFontには、CIDFontType0とCIDFontType2の2種類があります。
Technical Note #5092のCID-KeyedフォントとPDFの2種類のCID-Keyedフォントとの関係が今ひとつ分かりにくいですね。明日、もう少し調べてみましょう。
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月02日
PDFとフォント(21) Type3 フォント
Type3フォントは、PostScriptでグリフを表現するものです。2006年04月26日 PDFとフォント(17) Type1 フォントで説明しましたように1980年代は、Type1フォントのファイル形式は非公開でした。
これに対して、Type3のファイル形式は、最初から公開されていましたので、一般の人がPostScriptベースでアウトライン・フォントを開発しようとするとType3を使うしかなかったわけです。
Type3フォントの仕様については、 PostScript Language Reference Manual, 2nd Edition; Addison-Wesley (ISBN #0-201-18127-4)に記述されています。
青木俊道（あおきとしみち）さんという方のWebページで「Type3フォントについて」実際に作って試した話が載っています。
アドビのサポートページで、Type1とType3についての比較を見ますと次のようなことが書いてあります。
・Type3フォントの文字の字形は、標準のPsostScriptの命令で記述できる。
・従って、作るのは簡単。また複雑な形状の文字を作ることもできる。
・アドビは、Type3フォントの仕様を公開したが、自社でType3フォントを作成したことはなく、配布したこともない。
・Adobe Type Manager などのアプリケーションはType3フォントをサポートしていない。
※参考資料
Distinguishing Type 1 from Type 3 Fonts
要するにType3フォントの仕様はPostScriptでグリフを作れるよ、というサンプルのようなものなんでしょうね。
PDF Reference（1.6版）には、5.5.4項(pp. 389～395)に7ページも費やしてしっかりとType3フォントの説明があります。
この部分、もう削除してしまっても良いと思うのですが。Type3フォントなんてフォントに使っている人がいるのだろうか？
投票をお願いいたします
投稿者 koba : 08:00 | コメント (0) | トラックバック
2006年05月01日
情報セキュリティSDK 「CRYPTER」について
アンテナハウスは、2006年4月20日付けで、株式会社エクスフロントより情報セキュリティSDK「CRYPTER」の開発元である（有）ラング・エッジの株式の50%を取得しました。
詳細はこちらのニュース・リリースをご参照ください。
CRYPTERは、デジタル情報の保護・管理・追跡を行う技術を簡単に使用できるようにするSDK（ソフトウェア開発キット）です。これを利用して、デジタル情報について、様々なライセンス管理を行うシステムを構築することができます。
CRYPTERは、デジタル情報の保護・管理・追跡を行う技術を簡単に使用できるようにするSDK（ソフトウェア開発キット）です。これを利用して、デジタル情報について、様々なライセンス管理を行うシステムを構築することができます。
例えば、次のようなことができます。
１．コンテンツ配信と閲読権限管理
コンテンツの配信とデジタル著作権管理（Digital Rights Management: DRM）のシステムは一般的に次のようなことを行います。
(1) デジタル情報のコンテンツを暗号化して配信します。
(2) コンテンツ利用者を予めサーバ側のデータベースで管理しています。
(3) コンテンツ利用者（端末）からの要求により、ライセンス発行の可否を決定。
(4) ライセンス発行サーバからライセンスを発行します。
(5) コンテンツ利用者（端末）側では、ライセンスを使って、コンテンツの暗号を解き、閲覧できます。
２．アプリケーションの動作を制限するアクティベート
CRYPTERのライセンス管理APIは、アプリケーションの動作を制御するためのアクティベート情報をC-PKCのかたちでアプリケーションに渡し、アプリケーション側でC-PKCをもとに各動作を許可、禁止する機能を提供します。この機能を利用すると、「体験版」として期間や動作の制限付きでインストールされ、アクティベートすると制限のない「製品版」として利用できるアプリケーションを作成できます。
その例を図で示します。
現在、情報セキュリティは、情報漏洩という観点から注目があつまっています。しかし、将来のことを考えますと、紙に代わってPDFを使った電子配信が今後もますます普及すると見込まれます。これにより、重要な情報が自由に複製・再配布されてしまうことを防止したり、あるいは、情報の真贋性の保証方法などについては、ますます重要な課題になると予想します。
今後は、Crypterで蓄積した技術をPDF関係にも生かしていきたいと考えています。
投票をお願いいたします