« 2006年02月 | メイン | 2006年04月 »

2006年03月31日

オープンソースのビジネスモデル (4)

先に進む前に、ここでオープンソースという言葉とライセンスについて簡単に検討してみます。

まず、オープンソースという言葉ですが、プログラムのソースコードを公開、共有利用するというのは30年以上前からありました。

私がコンピュータをはじめて使いましたのは1973年ですが、当時、Fortranという言語で多変量解析などのプログラムを書いて、大型コンピュータ（メモリは128KB位から256KB位だったと記憶していますが）で計算しました。

そのプログラムは数式を元にゼロからプログラムを書いたわけではなく、専門書に掲載されていたプログラムや専門の研究所から入手したプログラムリスト（プログラムのプリントアウト）で、他の人の書いたプログラムを読んで、それを元に自分なりに多少修正してプログラムを作ったことの方が多かったと記憶しています。

実際、大きなプログラムをゼロから書くことはあまりなく、90%位は既存のものを使い、仕事に合わせて10%位書き直してということをやっていたと思います。ですからプログラムは（社外だけでなく社外とも）共有するものなんだな、とずっと思っていた位です。

そもそも自分の開発したプログラムのソースコードを占有し、使いたい人に使用権をライセンスするというビジネスの方が比較的新しいビジネスモデルである、といえるかもしれません。

さて、以上の話は個人的な余談として、本題に入ります。

１．オープンソースとは
現在、オープンソースの話についてはいろいろな人が語っていますので、ここではもう語るのはやめて、オープンソース・イニシアティブの言葉の定義を示しておきます。

１．１　原文(英語)
・Open Source Initiative (OSI)

・The Open Source Definition

１．２　日本語訳
・オープンソースの定義（The Open Source Definitionの翻訳）
・オープンソースグループ・ジャパン(日本独自の団体）

２．ライセンスとは
ソフトウエア(特に新しいソフトウェアを開発する）プロジェクトという点から考えますと、オープンソースという言葉の検討より、どのようなライセンスを選択するかという検討が重要です。ライセンスは著作権者とそれを利用する者の間の私的契約事項です。そこで順序として、最初に著作権者と利用者の基本的権利を確認しておきます。

２．１　法律上の根拠
ライセンスの基本になるのは国家の法律です。
ソフトウエアを保護することができる法律は、主に次のふたつだろうと思います。
(1) 著作権法
(2) 特許権

著作権法については、日本国内では日本の著作権法が適用されます。
海外では、当該の国の著作権法で保護されることになると思います。

国際的には、万国著作権条約加盟国では、各国内の著作権法を万国著作権条約の規定に合わせて変更しています。
日本の場合：万国著作権条約の実施に伴う著作権法の特例に関する法律

プログラムは著作権法の対象になると具体的に例示されています。
・第十条　（著作物の例示）　九項　プログラムの著作物

職務著作物としてのプログラムの著作者は、原則としてその人が属する法人になります。
・第十五条の2　職務上作成する著作物の著作者

著作者は幾つかの権利を持ちます。プログラムに関してその主なものは、
・第十八条　公表権
・第十九条　氏名表示権
・第二十条　同一性保持権　　但し、動作しないプログラムを動作するように改変することは、同一性保持権の適用対象外
・第二十一条　複製権　これは著作者の専有です。
・第二十六条の二　譲渡権　著作者は複製による譲渡権を専有します。
・第二十八条　二次的著作物の利用に関する原著作者の権利　原著作者は二次的著作物にも権利を持ちます。

一方、著作権には制限があります。
・第四十七条の二　プログラムの著作物の複製物の所有者は、利用する必要と認められる限度で複製・翻案を行うことができます。

著作者の権利の行使
・第六十三条　著作権者は著作物の利用を許諾できます。

権利侵害
・第百十二条　著作者は差止請求権をもつ
・第百十四条　損害の額の推定

罰則
・著作権違反については、段階に応じて、罰則（懲役または罰金）規定があります。

このように、国家の法律では著作権者の権利を一部の制限を除いて守っていることをまず理解しなければなりません。これは著作権者の権利を守ることで、創作活動が活発になり、文化の発展につながるということが大義名分です。

特許権についても、著作権と同じように特許権者の占有権を保護しています。ここでは、省略しますが、ビジネスを行ううえでは、これらの法律の大筋を理解しておく必要があります。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月30日

オープンソースのビジネスモデル (3)

PDFのオープンソースのビジネスモデルのもう一つのタイプはGhostScriptやXpdfのように、同じものを商用ライセンスとオープンソースライセンスのデュアルライセンスで提供するタイプです。

例えば、GhostScriptのライセンスはここに説明されています。
http://www.artifex.com/licensing/index.htm

これによりますと、GhostScriptは３種類のライセンスで提供されています。

なお、以下でいうライセンスの違いは、主にGhostScriptを使ったアプリケーションを再配布する時の条件の違いになります。従って、製品提供者側向けの話です。エンドユーザの使用権について言っているわけではありません。

(1) Artifex Ghostscript　商用ライセンス
Artifex 社と契約を結びGhostScriptのソースコードを入手、GhostScriptを自分で開発したアプリケーションと一緒に配布する権利を得ることができます。このとき、自分で開発したアプリケーションのソースコードをオープンソースにしなくても構いません。

(2) AFPL Ghostscript：Aladdinフリー公開ライセンス（Free Public License）
(3) GPL Ghostscript： GPLライセンス

GPLまたはAFPLのGhostScriptを使うなら、自分が開発するアプリケーションが、次のいずれかにあてはまる場合、自分が開発するアプリケーションすべてをGPLまたはAFPLで公開しなければなりません。

・自分で開発するアプリケーションが、GPLまたはAFPLのGhostScriptのコピーを含む。
・自分で開発するアプリケーションが、GPLまたはAFPLのGhostScriptから派生している。
・自分で開発するアプリケーションが、GPLまたはAFPLのGhostScriptのひとつ以上の機能を使っている。

自分が開発するアプリケーションをGPLまたはAFPLで公開しないなら、(1)の商用ライセンスを選択しなければならないのです。つまり、お金を払って再頒布の許可を得なければなりません。

AFPL GhostScriptはこちらから入手できます。
AFPL Ghostscript

GPL GhostScriptはこちらから入手できます。
GPL Ghostscript

ややこしいですね。それにしても、なぜ、商用ライセンスの他に、GPLとAFPLの2種類のライセンスがあるのでしょうか？

Aladdin Free Public Licenseの文章をざっとみますと、まず、これは、(いわゆる）オープンソースではないと書いてあります。GPLとの違いとして、AFPLでは「商用団体が、直接的にせよ、間接的にせよ、対価をとってAFPL GhostScriptを配布することを禁止している」ということで、「AFPLはGPLより厳しいライセンス」であると書かれています。
GPLは対価を取ることを禁止していません。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月29日

オープンソースのビジネスモデル (2)

PDFのオープンソース・プロジェクトの中で、現在の時点で一番うまくいったのは、PDFLibでしょう。PDFLibはオープンソースから初めましたが、既にオープンソースを卒業してしまったようです。成功した例が既にオープンソース・プロジェクトでない、というのは皮肉です。

改めてPDFLibのWebページを見ましたが、現在では、PDFLib Liteのみが、オープンソース開発者、私的利用者、研究者向けに限りオープンソース・ライセンスで提供されています。他の製品はすべて商用ライセンスを有償で購入する必要があります。

PDFLib Liteのライセンスページ
http://www.pdflib.com/purchase/license-lite.html

ちなみに、いま盛んに宣伝されているLinuxで、もっとも成功したのはRedHatだろうと思います。RedHat Linuxはオープンソースからスタートしたかもしれませんが、現在はRedHat Linuxをオープンソース・プロジェクトに分類するのは不適切なように思います。PDFLibと同じように、RedHat Linuxは極一部だけ、オープンソースで提供しているように思います。

このふたつの例をもって、オープンソース・プロジェクトは成功するとオープンソースでなくなる、といったら言い過ぎかもしれません。しかし、多少なりとも大きなプロジェクトにして、品質の高い製品を継続的に出していこうとすれば、どうしても対価を得る必要があります。そのためには対価と交換に製品を提供するという仕組みをとるのが一番単純明快のように思います。

元に戻りますが、PDFLibのWebページを見ますと、現在では、ＰＤＦLibは同名の会社名となり、PDFLibはバージョン6、製品の種類も増えて世界の60カ国以上に製品を販売していると言っています。いくらインターネットを通じてオンライン・ダウンロード販売できると言っても、世界60カ国はなかなかすごいと思います。

PDFLibの成功の要因は次のようなことでしょう。
(1) サーバサイドPDFへの取り組みが早かった。
(2) 書籍などでPRして有名になった。
(3) 開発者のPDFに関する知識のレベルが優れていた。
(4) プログラムの品質が高い。

しかし、この成功の条件はオープンソースとあまり関係ありませんね。PDFLibの成功にはオープンソースで始めたことはあまり関係ないのではないでしょうか。

他には、ReportLabも結構長期間に渡って頑張っています。ReportLabは、商用ライセンスとオープンソース・ライセンス（OSL）の両方を用意して、ユーザがどちらかを選択するデュアルライセンス方式を取っています。

このデュアルライセンス方式は、オープンソースのビジネスモデルの一つです。
ReportLabは、商用ライセンスの製品では、OSLの製品と比べて、製品の種類を増やしています。また、利益源になる製品は商用ライセンスしか提供していません。このあたり、PDFLibやRedHat Linuxと似ています。

結局、オープンソースから商用ライセンスに向かうというところに成功への道が一つあるように思います。

2006/3/30追記　sodaさんのご指摘の通り、RedHat Linuxの中核部分のソースは公開されているようです。公開部分が全体のどの位の割合になるか分かりませんが、RedHatのビジネスモデルがPDFLibと同じと分類するのは不適切でした。RedHatの課金方法は、一見、商用ライセンスと似ていますが、商用ライセンスに向かっていると分類はできないようです。

なお、3月28日に2006年2月度のRedHatの決算が発表されています。
Red Hat Reports Fiscal Fourth Quarter and Fiscal Year 2006 Results
売上高　　　2億78百万ドル　前年比53%増
営業利益　　　 58百万ドル 前年比165%増

というすばらしい業績です。但し、まだ多額の累積損失が残っていて、自己資本比率は30%台なので優良企業というにはあと数年掛かるように思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (6) | トラックバック

2006年03月28日

オープンソースのビジネスモデル (1)

さて、過去3回にわたりPDFのオープンソース・プロジェクトについてチェックしてみました。

次に、これらの事例を参考にしながら、オープンソースのビジネスモデルについて検討してみたいと思います。

新しいプロジェクトを始めるにあたり、それが成功するための条件が分かれば良いのですけれども。しかし、PDF分野では期待したほど成功したオープンソースはありません。ですのでビジネスモデルを検討するには不十分かもしれません。随時、他の事例を参照しながら考えて見たいと思います。

予めお断りしますが、以下の議論では、オープンソースの成果を消費する立場ではなく、オープンソースで何かを作りだそうという立場でのものです。

どんなプロジェクトでも成功するには大義名分が必要です。

商用ソフトウエアのメーカは、私利私欲を追及していると見られがちです。ここで強調しておきたいと思いますが、当社の場合は、私利私欲を追及している訳ではありません。念のため。

この点、オープンソースのプロジェクトは、利己的な利益と離れて、公益を追求すると言う大義名分を付けやすいように思います。しかし、実際は、大義名分だけでは持ちこたえることができないのは、社会人であれば誰にでも分かると思います。

オープンソースのプロジェクトで、恐らく一番大きな問題は、開発者に資金が還流しないことです。

商用ソフトウェアの場合は、ソースコードの権利と、その生成物であるオブジェクトの権利を占有し、顧客に使用権を提供すると同時に見返りに対価を得るというビジネスモデルが成り立ちます。

しかし、オープンソースでは、ソースコードを誰でも入手できます。結果的にオブジェクトを誰でも入手できることになります。誰でも入手して使えることになれば、当然使用権を提供して対価を得ることは難しくなります。ありていに言えば、誰も使用料を払わなくなるということです。従ってプログラムの使用料を得るのは難しいことになります。

一方、どのようなものであれ、開発には必ずお金が掛かります。そのための資金を集めなければなりません。しかし、開発に使った資金がより大きな価値となって回収できる見込みがなければ、新しいプロジェクトに投資する人はいないでしょう。大きなプロジェクトを起こすには、ベンチャキャピタルという仕組みもありますが、ベンチャキャピタルは投資が回収できる見込みがなければ決して投資しないでしょう。

この点、米英でオープンソース方式で開発するソフトウエア会社にベンチャキャピタルが出資するケースが増えているのは注目されます。

政府のような公的機関の場合は、資金の回収ということはあまり考えないかもしれませんが、国民の汗と涙の結晶である税金を使う以上は、ベンチャキャピタルなどよりは遥かに厳しい投資判断基準が必要なはずです。

最近のオープンソース・プロジェクトは、コンピュータ・メーカやシステム・インテグレータに在籍する開発者がフルタイムで働くものが多いですが、その場合、プログラマが在籍する企業にとってオープンソース・プロジェクトが価値があるものでなければなりません。

草の根オープンソース・プロジェクトでは開発者が手弁当で働くことになります。この場合、苦労した開発者が報われないような仕組みでは、プロジェクトを長期にわたって活発に継続することはできないでしょう。

このようなことを考えると、オープンソース・プロジェクトを起こすにあたって、ビジネスモデルを十分に検討することが最も大事といえるでしょう。このためのひとつの手段は、成功したプロジェクトを研究することです。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月27日

PDFのオープンソース・プロジェクト (3)

PDFのオープンソース・プロジェクトについて、ざっと見てみましたが、次に活動状況を比較してみます。

オープンソース・プロジェクトは、SourceForge.netに登録しているものが多いのですが、わかるものはSourceForgeのWebページの来客者数やダウンロード数を一覧にしました。

名称 商用ライセンス オープンソース バージョン リリース日 開発者数 Webヒット* ダウンロード*（GB) フォーラム
GhostScript 有 GPL/Other 8.53 2005/10/24 18 60 10,213 1,228
iText GPL/MPL 1.4 2006/03/03 4 1,621 1,102
iTextSharp GPL/LGPL/MPL 3.1.0 2006/03/03 4 3,801 249
PDFBox BSD 0.7.2 2005/09/11 4 801 145 2,781
FPDF Free 1.53 2004/12/31
FOP Apache 0.91 2005/12/23
ReportLab 有 BSD, GPL 1.2 2004/11/25 21 10 1
XPDF 有 GPL 3.1 2005/08/17
PJX GPL 1.2.1 2003/08/17 1 22 15 96
PDFCreator GPL 0.9 2006/01/19 3 294 13,130 6,215
※数値は、SourceForgeの統計。*は過去5日間平均。
※ダウンロードは、GByte単位なのでファイルサイズが大きいと大きくなります。

・GhostScript、iText、ReportLab、など多くのプロジェクトは自前のWebサイトをもち、かつ、SourceForgeに登録しています。

・FOPはApacheのプロジェクトからのみ、FPDF、XPDFは自前のWebサイトからのみダウンロードを提供しています。

・PDFCreatorは、紹介していませんでしたが、WindowsアプリケーションにPDFを出力させるプログラムです。GhostScriptを使った仮想プリンタドライバ型PDF生成ソフトです。この手のものは一杯あります。なぜか、今、PDFCreatorがSourceForgeで人気があるようです。
　HomePage　http://sourceforge.net/projects/pdfcreator

PDF関係のオープンソース・プロジェクトの活動状況を、横に比較するのは難しいですが、大雑把には、GhostScript、iText/ iTextSharp、PDFBox、FOP、ReportLab、PDFCreatorあたりが比較的有力なものと言えるように思います。

PDFのオープンソース・プロジェクトは、特に、海外では数えきれないほどありますが、有力なものは思ったより少ないように思います。

私がうまく探せていないだけかもしれませんので、もし、他にこれが抜けてる！というものがありましたら教えてもらいたいと思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (2) | トラックバック

2006年03月26日

PDFのオープンソース・プロジェクト (2)

「PDF on the Fly: Tools and Strategies for Automatic Generation of PDF」(PDFをon the Flyで作成する：PDFの自動生成のためのツールと戦略)　（2002年8月、Seybold Report）は少し古いですが、割と良くまとまっています。

以下、概要です。
サーバ上でPDFを自動生成しようとしますと、Adobe製品ではAdobe PDF Libraryを使う訳ですが、上の資料によりますと、Adobe PDF Libraryは次のような問題点があります。

(1)　ものすごく高機能で、パワフルだけれども、遅い。
(2)　PDFのことを良く知らないとプログラムできない。
(3)　スレッド・セーフでない。

そのような問題があり、サード・パーティのPDFライブラリーの必要性が生まれているとしています。

Adobe PDF Libraryの代替としては、まず、オープンソースのライブラリーが候補になるわけですが、このレポートではReportLab、Etymon（両方とも昨日リストアップ済）をオープンソースのPDF生成ソフトとしてあげています。但し、Etymonは、優れているが、ページ数が多くなると、スピードが落ちてきて、メモリをものすごく使う、と言っています。（注１）

それから、PDFLibをオープンソースから商業ライセンスに移行して成功している例として取り上げています。

---概要、ここまで。

・PDFLib　2005年11月12日　PDFの作成方法（9） – PDF出力ライブラリーで紹介済み。当日の記事のコメントもご参照ください。

・FPDF　PHPでPDFを作成するためのライブラリー。
　HomePage　http://www.fpdf.org/
　日本語もあります。http://fpdf.japansite.net/

・JFreeReport　Javaのオープンソース。レポートを作成してPDFなどの形式で出力します。2002年2月にバージョン0.6。最新版は2006年2月にバージョン0.8.2が出ています。満4年間で0.2しか進んでいません。(注2）JFreeReportのPDF生成エンジンはiTextです。
　HomePage　http://www.jfree.org/jfreereport/index.php

注１
実は、弊社のXSL Formatterも同じような用途に使うケースが多いのです。それで、オープンソースのFOPやJAVAで開発された競合製品から、XSL Formatterに乗り換えるお客さんも多いのですが、大抵、同じような理由を挙げます。ページ数が増えたときのパーフォーマンス（速度とメモリ）が鬼門なんでしょうね。オープンソースでやってみて、結局、壁にぶつかって、諦めて商業ソフトに乗り換えるお客さんは予想外に多いのです。

注２
但し、JFreeReportプロジェクトは、2006年1月に、Pentaho Corp.（フロリダ州オーランド）という会社に吸収されました。Pentahoは、オープンソースでBI（ビジネス・インテリジェンス）のツールを揃えようとしているようです。この会社は、かなり多額のお金をVCから集めています。どういうビジネスモデルか、興味がありますね。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月25日

PDFのオープンソース・プロジェクト (1)

最近、あるソフトウエア開発プロジェクトをオープンソースでやったらどうか、ということを考えています。そんなわけで、ちょっと、思いついて、PDF関連のオープンソース・プロジェクトにどんなのがあるか、を調べて整理してみました。

とりあえず、最初に私の知っているものを中心にリストしてみます。

(1)　PDF作成ソフト
・GhostScript　2005年11月09日 PDFの作成方法（7） – Distiller互換ソフトで説明しました。PostScript互換インタープリタで、PostScriptからPDFへの変換を行います。商業ライセンスもあります。
　HomePage　http://www.ghostscript.com/

・iText　2006年02月19日 Java用PDF生成ライブラリー iTextの調査から6回ほど説明。JAVAで開発されたサーバサイドのPDF生成部品。C#版もあります。
　HomePage　http://www.lowagie.com/iText/

・PDFBox　JAVAのPDF生成ライブラリー　Ben Litchfieldさんが管理者。2002年からhttp://sourceforge.net/で公開されています。現在、Version0.7.2。最近、後述のFOPのPDF生成エンジンとして、立候補しています。
　HomePage　http://www.pdfbox.org/

(2) ドキュメントからPDF生成ソフト
PDF生成ソフトの上位にあたる、ドキュメント整形機能をもち、整形結果をPDFにするソフトです。
・FOP　XSL-FOをPDFに。当社のXSLFormatterと同一ジャンルに属するもの。現在、V0.91ベータ版が公開されています。
　HomePage　http://xmlgraphics.apache.org/fop/

・ReportLab　ビジネスレポートをPDF化。Pythonで開発されています。同名の商業ソフトのオープンソース版。
　HomePage　http://www.reportlab.org/

(3)　PDF表示ソフト
・Xpdf　UnixなどのX－Windowの上で使えるPDFファイルのビューア。
　HomePage　http://www.foolabs.com/xpdf/home.html

(4) 多機能PDFライブラリー
・PJX　PDFの生成、読み込み、結合操作など。SourceForgeでソースが公開されています。開発者1名、あまり活発ではないようです。
　HomePage　http://www.etymon.com/epub.html

投票をお願いいたします

投稿者 koba : 08:00 | コメント (1) | トラックバック

2006年03月24日

いきなりPDF Professional 2 PLUS

ご存知の方も多いと思いますが、ソースネクストは、4月7日から、各種注釈やしおりの編集など新機能を追加したPDF作成ソフトの最新版「いきなりPDF Professional 2 PLUS」を発売します。

ソースネクストのプレスリリース

「いきなりPDF Professional 2 PLUS」製品情報

この製品の開発元はアンテナハウスです。これで、「いきなりPDF」ファミリーの中で、アンテナハウスが開発してソースネクストから発売されているものは、単品で3製品、パック製品を含めますと5製品となりました。

ソースネクストから出ている「いきなりPDF」ファミリーは全部で11製品になっています。アンテナハウス製と他社製品をお間違えにならないように。

製品名 標準価格 開発元
いきなりPDF2 1,980円 アンテナハウス
いきなりPDF Professional 2 2,970円 アンテナハウス
いきなりPDF Professional 2 PLUS 3,970円 アンテナハウス
いきなりPDF EDIT! 6,980円 ニュアンス コミュニケーションズ株式会社
いきなりPDF COMPLETE 9,850円 いきなりPDF EDIT!、いきなりPDF to Data、いきなりPDF from スキャナのパック
いきなりPDF from スキャナ 1,980円
いきなりPDF FlashPaper 1,980円 アドビシステムズ（旧Macromedia, Inc.）
いきなりPDF Expert PACK 2 3,970円 いきなりPDF Professional2、いきなりPDF to Dataのパック
いきなりPDF Expert PACK 2 DX 4,980円 いきなりPDF Professional2、いきなりPDF to Data Professionalのパック
いきなりPDF to Data 1,980円 パナソニック ソリューションテクノロジー株式会社
いきなりPDF to Data Professional 2,970円 パナソニック ソリューションテクノロジー株式会社

それにしてもソースネクストに限らずPDF関係の製品はどんどん増えますね。そういうアンテナハウスもいろいろ製品を出していきたいと思っていますが、お互いに切磋琢磨して、安くて良い製品が沢山出回るようになれば、ユーザのためには良い訳ですから、こういう競争は歓迎です。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月23日

PDFとフォント(12) CSSのフォント選択仕様

和文フォント”平成角ゴシック Std”は、もともと、W3、W5、W7、W9がフォントファミリーとして設計されています。しかし、現在のWindowsアプリケーションは、Microsoft OfficeでもWebブラウザ（IE6、Firefox）でも、”平成角ゴシック Std”をフォントファミリー名として認識できていないことを示しました。

私の想像ですが、この原因は、次のようなことでしょう。
(1) フォントファミリーは印刷業界などの専門家向けのDTPソフトで使われていたが、Microsoft Officeでは、文字にフォントを指定する際に、フォントファミリーを使うという概念がなかった。
(2) さらに、WindowsのAPI（アプリケーション・プログラム・インターフェイス）もMicrosoft Officeのような一般ビジネス文書用のアプリケーション用途になっているため、OpenTypeの優先フォントファミリー（ID16）の情報をアプリケーションに提供するようになっていない。

この解決策はないのでしょうか？

CSS2では、ブラウザがフォントを選択するための仕組みとしてフォント記述（Font Description）という仕様が定義されています。

例えば、平成角ゴシック Stdというフォントファミリーは@font-faceを使って、次のように記述することができます。

<style type="text/css">
@font-face { src : local("平成角ゴシック Std W3");
font-family : "平成角ゴシック Std" ;
font-weight : 300
}
@font-face { src : local("平成角ゴシック Std W5");
font-family : "平成角ゴシック Std" ;
font-weight : 500
}
@font-face { src : local("平成角ゴシック Std W7");
font-family : "平成角ゴシック Std" ;
font-weight : 700;
}
@font-face { src : local("平成角ゴシック Std W9");
font-family : "平成角ゴシック Std" ;
font-weight : 900
}
</style>

こうすれば、font-weightが300、500、700、900の4つの特性をもつ平成角ゴシック Stdというフォントファミリーを定義できるはずです。しかし、残念ながらIE6も、Firefoxも@font-face指定を認識できません。

・@font-faceはCSS2から導入されました。IE6はCSS2は未対応。
・CSS2の@font-face宣言は、CSS2.1（Working　Draft）では削除されています。

Cascading Style Sheets, level 2 revision 1
CSS 2.1 Specification
W3C Working Draft 13 June 2005

Appendix C. Changes

・そのためかどうか、Firefoxでも@font-faceによる上の定義は認識できないようです。

ここにサンプルファイルを置きます。お使いのブラウザでお試しになってみてください。
Download file

どこかに、@font-faceを認識するブラウザがあるのでしょうか？また、Internet Explorer7になったらできるようになるのでしょうか？

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月22日

PDFとフォント(11) CSSのフォント指定とブラウザの表示

さて、CSSでは、前に言いました（2006年03月12日PDFとフォント(2) フォントファミリー）が、フォントの指定には font-family, font-style, font-variant, font-weight, font-stretchおよびfont-sizeを使います。

では、WebサーバにあるHTML＋CSSで指定されたフォントは端末のブラウザでどのように選択されるのでしょうか？

CSSの font-family, font-style, font-weightの指定の仕方をいろいろ変えたとき、Internet Explorer6 (IE6)とFirefoxで、どのように表示されるかを調べてみましょう。

ここでは、今までに調べてきましたArialと平成角ゴシック StdというふたつのOpenTypeフォントファミリーで試しています。次のような結果になりました。

(1) IE6でもFirefoxでも、font-family="Arial"、font-style="italic"、font-weight="bold" の組み合わせで適切なフォントが選択される。欧文フォントはCSSの指定が機能しています。

(2) IE6でもFirefoxでも、font-family="平成角ゴシック Std"はフォミリー名として認識できず、ブラウザのデフォルトのフォントになってしまう。つまりOpenTypeの優先フォントファミリー（ID16）の名前の指定は有効にならないということが言えます。

(3) 和文フォントに対してfont-style="italic"、font-weight="bold"を指定すると、IE6でもFirefoxでも文字を傾けたり、文字を太らせるというフォント合成を行ってそれらしく表示します。

(4) font-family="平成角ゴシック Std W3"～"平成角ゴシック Std W9"というフォントメニュー名（ID1）を指定すると、Firefoxでは、平成角ゴシック Std フォントファミリーから該当するフォントを選択して適用します。

(5) しかし、IE6は、漢字・カタカナがMSP明朝というブラウザのデフォルトフォントになってしまいます。ラテン文字にのみ、平成角ゴシック Std フォントファミリーの該当するフォントを選択して適用されます。
※結局、このテストデータをIE6で表示しますと、漢字カタカナを平成角ゴシックStdのファミリーを選択して表示するケースは皆無になっています。これはIE6のバグじゃないでしょうか？

(7) font-weightに数値(100から900)を指定したとき、Firefoxは；
a."平成角ゴシック Std W3"、"平成角ゴシック Std W5"では600以上をboldとして扱う。
b."平成角ゴシック Std W7"、"平成角ゴシック Std W9"ではもともと全てをboldとして扱っている。

(8) font-weightに数値(100から900)を指定したとき、IE6は；
a.MSP明朝についてはfont-weight="600"以上になると太らせている。
b."平成角ゴシック Std W3"では500以上をboldとして、"平成角ゴシック Std W5"では700以上をboldとして扱う。つまりそれ自身より2段階上の値が指定されると太らせている。
b."平成角ゴシック Std W7"、"平成角ゴシック Std W9"ではもともと全てをboldとして扱っている。

簡単なサンプルを作ってみただけですが、和文フォントについてはfont-familyで指定して指定したフォントが必ずしもうまく選択されないという問題があるのではないかと思います。

■テストデータ
欧文フォント、和文フォントへのfont-family、font-style、font-weight設定例

■上記のサンプルをブラウザ＋アンテナハウスPDFドライバV3でPDF化した例
Firefox1.5＋アンテナハウスPDFドライバV3でPDF化

InternetExplorer6＋アンテナハウスPDFドライバV3でPDF化

【動作環境】
WindowsXP Service Pack2英語版OSを日本語モードで起動。
InternetExplorer Version 6.0.2900.2180
Firefox 1.5.0.1

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月21日

PDFとフォント(10) フォントの合成

実際に、Microsoft Excelでフォント別にスタイルを指定したデータを作ってみます。
次の図は、Arial、Arial Narrow、平成角ゴシックStdについて、Excelで指定可能なスタイルを指定したものです。

OfficeFontSynsesize.PNG
※MicrosoftExcelの印刷プレビュー画面

上の図で、フォント名にブルーの背景をつけた行は、フォントファミリーに該当のスタイルのものがありません。しかし、フォントがなくてもそれらしいスタイルの文字が表示されていることがわかります。

Bold、Italicについては、フォントファミリーに該当するフォントがなくても、OS（Windows）がフォントを合成して該当するスタイルを作りだしてくれることがわかります。

もちろん、これをPDFドライバでPDF化した場合、Excelの印刷プレビューと同じようにPDFでも再現されます。

○上記のExcelファイルをもとにAcrobat6で作成したPDF：
Download file

○上記のExcelファイルをもとにAntenna PDF Driver 3.0で作成したPDF：
Download file

ちなみに、
OSで合成したフォントについては、PDFReferenceには次のように書いてあります。

「システムにインストールされていなくてOSが合成したフォントについては、カンマで区切ってスタイル名を付加する。例えば、TrueType フォントNew YorkのBoldを派生させたときは、BaseFont の値に、/NewYork,Bold　と書く」
（PDF Reference 1.6 p.388)

しかし、実際には、そのような出力をしているのは、PDFWriterのみです。次の図は、PDFWriterで出力したPDFのプロパティ-Fontの部分ですが、フォント名の後ろにスタイルを付加していることがわかります。
OfficeFontSynsesize-PDFWriret.PNG
※ちなみに、PDFWriterで作成したPDFは、（ここにはリンクしませんが）平成角ゴシックStd部分が文字化けしてしまっています。

AcrobatPDFもAntenna PDF Driverもそういう出し方はしていなくて、Italicに対して傾ける行列をつけるなどの計算方法を指定しているようです。PDFReferenceの記述は不要ということなんでしょうか？

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月20日

PDFとフォント(9) Officeのフォントダイヤログ－スタイル

Microsoft Officeのフォントダイヤログでは、各フォントに対して、スタイルを指定することができます。

フォント名を選択すると、スタイルのリストボックスに、いくつかのスタイルが表示され、その中の一つを選択できます。このリストが実際のフォントファイルにどのように対応付けられているのかを見てみます。

(1) 大部分のフォント名について、スタイルには
・日本語版では標準-斜体-太字-太字 斜体
・英語版ではRegular - Italic - Bold - Bold Italic
の4種類がリストされます。以下、括弧内が英語版。

例えば、ArialやArial Narrowの場合は、4種類のフォントファイルが存在して、ファミリーを作っています。
2006年03月13日 PDFとフォント(3)　欧文フォントのフォントファミリー

このようなフォントファミリーの場合、標準-斜体-太字-太字 斜体(Regular - Italic - Bold - Bold Italic)の4種類のスタイルは、そのファミリーの4つのフォントファイルと1対１対応です。

(2) 欧文フォントのBitstream Vera Sansの場合は、スタイルのリストにはRoman - Oblique - 太字 -太字 Oblique (Roman - Oblique - Bold - Bold Oblique)の4種類が表示されます。標準(Regular)の代わりにRoman、斜体(Italic)の代わりにObliqueになっています。（スタイルの名前が違う）。

(3) Arial Blackの場合は、フォントファイルは一種しかありませんが、スタイルのリストには標準-斜体-太字-太字 斜体 (Regular - Italic - Bold - Bold Italic)の4つが表示されます。つまりフォントファミリーには実際にフォントがないのに、スタイルのリストにはあたかもファイルがあるかのように表示されます。

(4) 平成角ゴシックStdは、W3、W5、W7、W9がそれぞれ単独でフォント名として選択できます。
(a) W3、W5は、標準 - 斜体 - 太字 - 太字 斜体 (Regular - Italic - Bold - Bold Italic)の4種類、
(b) W7は、日本語版Wordでは太字 - 太字 斜体（英語版WordではRegular - Bold Italic）、日本語版Excelでは斜体 - 太字 - 太字 斜体(英語版ExcelではItalic - Bold - Bold Italic）
(c) W9は、日本語版Wordでは標準 - 斜体 - 太字 - 太字 斜体 (英語版WordではRegular - Italic - Bold - Bold Italic)、日本語版Excelでは斜体 - 太字 - 太字 斜体 - 太字 （英語版ExcelではItalic - Bold - Bold Italic - Bold)の4種類のリストが表示されます。

Officeのフォントダイヤログで平成角ゴシックStdW7,W9フォントを選択した時にスタイルのリスト表示は正しくないように思います。特に英語版はWordとExcelで首尾一貫していません。ソフトウエアのとこかにバグがあると思います。

日本語：Windows2000英語版ServicePack4を国際化したOSを日本語モードで起動＋Microsoft Office2003日本語版
英語：WindowsXP ServicePack2英語版を日本語モードで起動＋MicrosoftOffice2003英語版

上に述べたことをOpenTypeのFont Subfamilyとの関係について表に整理してみました。

※Officeは上に述べたように、OSと日本語版・英語版で首尾一貫してない箇所がありますので、ここでは英語版のExcelのスタイルリストのみとします。

Font FileのName Table 英語版Microsoft Excel
Font Styleリスト
Font Family(ID1) Font Subfamily (ID2)
Arial / Arial narrow Regular Regular
Italic Italic
Bold Bold
Bold Italic Bold Italic
Arial Black Regular Regular
* Italic
* Bold
* Bold Italic
Bitstream Vera Sans Roman Roman
Oblique Oblique
Bold Bold
Bold Oblique Bold Oblique
平成角ゴシックStd W3 Regular Regular
* Italic
* Bold
* Bold Italic
平成角ゴシックStd W5 Regular Regular
* Italic
* Bold
* Bold Italic
平成角ゴシックStd W7 Bold Italic
* Bold
x Bold Italic
平成角ゴシックStd W9 Bold Italic
* Bold
x Bold Italic
x Bold

○まとめ

(1) Microsoft Office のフォントダイヤログ－スタイルのリストには、原則として、WindowsにインストールされているフォントファミリーのFont Subfamily (ID2)に設定されている名前が表示される。

(2) 但し、フォントファミリーにはFont Subfamily (ID2)に該当する設定を持つフォントがないのにリストにスタイルが表示されることもある。
上の表で * を示したセルが該当。

(3) Font Subfamily (ID2)になく、かつ、無意味と思われるスタイルが表示されることもある。
上の表で x を示したセル。バグ？。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月19日

.NETの未来　Microsoftは.NETに賭けていないのか

最近、これから新しく開発するツールの言語についてC#（.NET）にすべきかどうか真剣に考えています。

そんな話を社内のメーリング・リストに流したところ、showさんから、
http://slashdot.jp/articles/06/03/16/1143227.shtml
やっぱり OS 開発はネイティブコード?
という記事が出ているよ、と教えてもらいました。

原文は、Microsoft Vista and .NET
著者はMicrosoftのMVP（Most Valueable Professional） Richard Grimesさんです。
URLはhttp://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm
です。

早速読んで見ました。この記事は、私にとっては、近ごろ読んだ記事の中で一番ショッキングな内容でした。

原文は、かなり長文なのですが、さわりだけを簡潔に紹介します。

１．Microsoftは2000年のPDC2000で、.NET Framework をデビューさせた。その後PDC2003では、Longhornの新しいAPIであるWinFXは.NETのマネージド・コードになり、開発者がそれを生かすには、.NETでプログラム開発しなければならないということをアピールした。

PDC2003で参加者に配布したLonghornには、2078個の実行形式ファイルがあり、その中の35個が.NETで開発したマネージド・コードであった。その中に、Font Cache Service, Indexing Serviceという重要なふたつのプログラムがマネージド・コードであった。

※2003年のPDC2003のサイト

２．Vistaの最終ビルド5308（2006年3月6日配布)では、2606個の実行形式ファイルがあり、その中の27個がマネージド・コードである。しかし、これらのマネージド・コードはあまり重要なものではなく、SerivceやWindows Explorerのような重要プログラムには.NETは使われていない。つまり、2003年時点と比べると、Microsoftが.NETから退却したのは明らかである。

３．.NET2.0は、Vistaのベータ版と一緒に提供されている。しかし、WinFXはVistaの一部として提供されておらず、独立にインストールする必要がある。このことは、VistaのOS内部コードは、Avalon （Windows Presentation Foundation)、Indigo (Windows Communication Foundation)を一切使っていないことを意味する。すなわち、サードパーティの開発者は、Microsoft自身が使っていない技術を使うことを期待されている、ということになる。

４．Microsoftは、.NETに会社を賭けると言いながら、同社の重要な収入源になっているソフトウエア製品の中で.NETで開発しているものはない。さらに上の１～３のようにVistaでも.NETから撤退しているということは、Microsoft自身、自分達のアプリケーション・フレームワークに対してまったく信頼を置いていないことを意味する。

以上です。
もっと他の資料も当たって真偽の程を良く調べないといけないですが、これを読んで、正直なところ、仰天しました。

アンテナハウスは、現在までのところ、重要なアプリケーションを.NETで作っていません。しかし、アプリケーション・ベンダの中には.NETに多額のお金を投資している会社もあるだろうと思います。

.NETアプリケーション開発に投資するか否かは、3年、5年というスパンでソフトハウスの収入に重要なインパクトを与えます。.NETはアプリケーション・ソフトにとっては環境であり、アプリケーション・ソフトはそれが動作する環境が普及すれば、売れ行きが伸び、動作する環境が普及しなければ、売れないからです。

分かりやすく例えれば、ガソリンの値段が高くなれば、米国の消費者が燃費効率の良いトヨタなどの日本車を買うようになりトヨタは儲かりますが、大型車を作っているGMやFordの経営は苦しくなるようなもの。.NETが普及すれば、ユーザは.NETのマネージド・コードで作ったプログラムを買うようになり、.NETに投資したソフトハウスが有利になります。しかし、そうでなければその逆になります。

MicrosoftのOSや.NETなどのフレームワークの動向は、世界の何千というソフトハウスにとって、ガソリンの値段が自動車メーカの経営に与えるインパクトよりも遥かに大きなインパクトを与えるのです。

ある程度大きなソフトウエア製品を作ると、ビジネスとしてものになるのに3年位は掛かります。間違った方向の選択をすると、3年後にGMのようになってしまうわけです。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月18日

PDFとフォント(8) Windows アプリケーションのフォント・メニュー

さて、2006年03月16日のPDFとフォント(6) 和文フォントのファミリーについてに、Ken Lundeさんから、『CJKのOpenTypeフォントの「name」テーブルの内容について、Adobe Tech Note #5149を参照』せよ、というコメントをいただきました。

Adobe Tech Note #5149　
OpenType-CID/CFF
CJK Fonts: ‘name’
Table Tutorial
http://partners.adobe.com/public/developer/en/font/5149.OTFname_Tutorial.pdf

早速読んでみましたが、この文書はフォントを作成する人向けの、Name Table設定のための手引書です。

これを見ますと、Microsoft/Unicode Menu Namesに、Font Family (ID1), Font Subfamily (ID2), 優先Font Family (ID16), 優先Font Subfamily (ID17)について、次のようにまとめられています。

・ID1は、優先Font Family (ID16)と優先Font Subfamily (ID17)をスペースを間において結合した文字列とする。
・ID2は、head.MacStyle とOS/2.Selectionのフィールドの情報が、ボールドを示さない時は、Regular固定とする。ボールドを示す時は、Bold固定とする。

平成角ゴシックStdファミリーは、その通りに設定されています。

ところで、Menu Nameという表現は、PostScript Nameとの区分上の表現なのでしょう。そして、この名前はメニューに表示するためのものであることを意味すると予想されます。

そこで、平成角ゴシックStdフォントの名前がWindows上のMicrosoft Wordでどのように表示されるかを見てみました。

１．Windows XP を英語モードで起動した時

WordFontDialog-En.PNG


２．Windows XP を日本語モードで起動した時

WordFontDialog-Ja.PNG

ここから次のことがわかります。

(1) Microsoft Officeでは、Name Table のFont Family (ID1)は、フォントを選択するためのリストボックスに表示するための名前として使われている。

(2) Microsoft Officeのフォント選択ダイヤログには、優先Font Family名 (ID16)は表示されない。

では、一般のWindowsアプリケーションは、優先Font Family （ID16）と優先Font Subfamily (ID17)を使うことができるのでしょうか？

普通のWindowsアプリケーションは、WindowsのAPI（WindowsOSが、アプリケーションに提供するインターフェイス）を使って、Fontファイルの内容を読みます。従って、上の質問に対する回答は、WindowsAPIの機能を調べてみないと分かりません。

で、当社のプログラマの一人に聞きましたら、そんなことは知らないというつれない返事でした。

アンテナハウスのXSL FormatterやPDF関連のライブラリーは、Windowsの他、Linux、Solaris、AIXなどで動きます。これを実現するためWindowsAPIを使わずに、自力で、Fontファイルの内容を読んでいます。ですのでWindowsAPIの機能なんて知らないという答えになってしまうのも仕方ないのです。プログラマも分業制ですしね。

ところで、殆どのソフトハウスは、WindowsAPIを使ってフォントファイルから情報を取り出しているはずです。なぜかと言いますと、例えば日本で販売されているPDF作成ソフトでJAVA版を除くと残りのソフトは、殆どWindows版のみですから。

そうしますと、優先ファミリー （ID16）と優先サブファミリー （ID17)を使うことができるかどうかは、MicrosoftのWindowsAPIにその機能が用意されているかどうか、に依存してしまうということになるのですが。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月17日

PDFとフォント(7) 平成角ゴシック Stdフォントのファミリー名

さて、次に平成角ゴシック Stdフォントの名前が、Macintosh、Windowsの日本語、英語モード用にどのようになっているかを比較してみました。

○まとめ
(1)Macintosh用
・英語では、ファミリー名：Heisei Kaku Gothic Std、サブファミリー名：W3～W9となっています。つまり、フォントウエイトでファミリー化しているということになります。また、優先フォントファミリーの部分は使っていません。
・日本語も同様です。

(2)Windows用
・英語では、ファミリー名：Heisei Kaku Gothic Std W3～同W9、サブファミリー名：RegularまたはBoldとなっています。
この部分を使うと、Heisei Kaku Gothic StdのウエイトW3～W9のフォントはファミリーとして扱われません。

・優先ファミリー名（ID16）を使ってMacintoshと同じようなファミリー化をしています。従って、Windows版では、優先ファミリー名を使わないとファミリーとして扱えません。

・Full font name （ID4）は、ID1とID2を結合したものでなければならない、しかし、そうなっていない、という点で仕様違反です。

・日本語の場合、Full font name （ID4）が空白になっています。日本語WindowsではFull font name を表示するアプリケーションがもしあると困るでしょう。

以下にデータを示します。

次の表は、平成角ゴシック Std W3フォントのName Tableに書かれている４つのプラットフォーム用のフォントファミリー関係のデータを取り出したもの。

表１　平成角ゴシック Std W3フォントのName Tableをttfdump.exeで解析した結果

Font Family Font Subfamily 優先Font Family 優先Font Subfamily
Mac 英語 Heisei Kaku Gothic Std W3
Mac 日本語 平成角ゴシック Std W3
Window英語 Heisei Kaku Gothic Std W3 Regular Heisei Kaku Gothic Std W3
Windows日本語 平成角ゴシック Std W3 Regular 平成角ゴシック Std W3

次の表は平成角ゴシックStdファミリーのName Tableの解析結果です。4つのフォントファイルのフォント名に関する部分を取り出して、4種類のプラットフォーム毎に整理したものです。

表2-1　平成角ゴシックStdファミリー　Macintosh用英語

FileName Font Family Font SubFamily Full Font Name 優先Font Family 優先Font Subfamily
(ID1) (ID2) (ID4) (ID16) (ID17)
HeiseiKakuGoStd-W3.otf Heisei Kaku Gothic Std W3 Heisei Kaku Gothic Std W3
HeiseiKakuGoStd-W5.otf Heisei Kaku Gothic Std W5 Heisei Kaku Gothic Std W5
HeiseiKakuGoStd-W7.otf Heisei Kaku Gothic Std W7 Heisei Kaku Gothic Std W7
HeiseiKakuGoStd-W9.otf Heisei Kaku Gothic Std W9 Heisei Kaku Gothic Std W9

表2-2　平成角ゴシックStdファミリー　Macintosh用日本語

FileName Font Family Font SubFamily Full Font Name 優先Font Family 優先Font Subfamily
(ID1) (ID2) (ID4) (ID16) (ID17)
HeiseiKakuGoStd-W3.otf 平成角ゴシック Std W3 平成角ゴシック Std W3
HeiseiKakuGoStd-W5.otf 平成角ゴシック Std W5 平成角ゴシック Std W5
HeiseiKakuGoStd-W7.otf 平成角ゴシック Std W7 平成角ゴシック Std W7
HeiseiKakuGoStd-W9.otf 平成角ゴシック Std W9 平成角ゴシック Std W9

表2-3　平成角ゴシックStdファミリー　Windows用英語

FileName Font Family Font SubFamily Full Font Name 優先Font Family 優先Font Subfamily
(ID1) (ID2) (ID4) (ID16) (ID17)
HeiseiKakuGoStd-W3.otf Heisei Kaku Gothic Std W3 Regular HeiseiKakuGoStd-W3 Heisei Kaku Gothic Std W3
HeiseiKakuGoStd-W5.otf Heisei Kaku Gothic Std W5 Regular HeiseiKakuGoStd-W5 Heisei Kaku Gothic Std W5
HeiseiKakuGoStd-W7.otf Heisei Kaku Gothic Std W7 Bold HeiseiKakuGoStd-W7 Heisei Kaku Gothic Std W7
HeiseiKakuGoStd-W9.otf Heisei Kaku Gothic Std W9 Bold HeiseiKakuGoStd-W9 Heisei Kaku Gothic Std W9

表2-4　平成角ゴシックStdファミリー　Windows用日本語

FileName Font Family Font SubFamily Full Font Name 優先Font Family 優先Font Subfamily
(ID1) (ID2) (ID4) (ID16) (ID17)
HeiseiKakuGoStd-W3.otf 平成角ゴシック Std W3 Regular 平成角ゴシック Std W3
HeiseiKakuGoStd-W5.otf 平成角ゴシック Std W5 Regular 平成角ゴシック Std W5
HeiseiKakuGoStd-W7.otf 平成角ゴシック Std W7 Bold 平成角ゴシック Std W7
HeiseiKakuGoStd-W9.otf 平成角ゴシック Std W9 Bold 平成角ゴシック Std W9
投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月16日

PDFとフォント(6) 和文フォント、Open Typeの Naming Table

和文フォントのファミリーについて、OpenTypeの仕様と照らし合わせながら少し詳しく調べてみましょう。

OpenTypeのファイルには、そのフォントを利用するアプリケーションのために様々なデータの表が収容されています。フォントの名前などは、Naming Table という表にまとまっています。

ちなみに、ttfdump.exeでHeiseiKakuGoStd-W3.otf（平成角ゴシック Std W3)のNaming Table の内容を見てみました。

Naming Tableには、ひとつのフォントファイルを幾つかのプラットフォーム（OS)で利用するために、名前も一種類ではなく、複数のプラットフォーム用の名前のデータがあります。そして、このフォントでは、次の4つのプラットフォーム用のデータがあることが分かりました。

(1) Macintosh英語用
Platform ID: 1　（Macintosh）
Specific ID: 0　（Roman）
Language ID: 0　（English）

(2) Macintosh日本語用
Platform ID: 1　（Macintosh）
Specific ID: 1　（Japanese）
Language ID: 11　（Japanese）

(3) Windows英語用
Platform ID: 3　 (Windows)
Specific ID: 1 (Unicode)
Language ID: 1033 (英語)

(4) Windows日本語用
Platform ID: 3　 (Windows)
Specific ID: 1 (Unicode)
Language ID: 1041 (日本語)

平成角ゴシック Stdの場合、MacintoshとWindowsのふたつのOSの、それぞれ英語モード、日本語モードで使えるように、4種類の名前のデータを別の符号化方式で持っているということになります。

逆にいうと、このフォントはLinuxなどの他のOSでは公式には使えないってことなんでしょうか。

さて、Naming Table には幾つかの見出し項目（Name ID）があります。その中で関係しそうなものを拾って見ますと、次のようになります。

Name ID 意味
1 Font Family。最大4つのフォントが同じFont Family名を共有できる。４つでregular, italic, bold, bold italicというフォントファミリーを形成する。
2 Font Subfamily。Font Subfamily名はID 1で同じファミリーに分類されるフォントをさらに細かく区別する。
4 Full font name。ID 1とID 2を結合したもの。但し、ID 2でregularの時のみファミリー名のみを使う。
6 PostScript name
16 Preferred（優先）Family。歴史的な理由でフォントファミリーは最大4つのスタイルを含んでいる。優先ファミリーを使うことでデザイナは4種類以上のスタイルをグループ化することができる。ID 1と異なる場合のみ存在する。
17 Preferred（優先）Subfamily。ID 2よりも細かい分類をすることができる。ID 2と異なる場合のみ存在する。また、優先サブファミリーの中ではユニークでなければならない。

フォントファミリーの基本は、regular, italic, bold, bold italicの4種類がひとつのセットなんですね。そうして、もっと多数のフォントをファミリー化するには、優先ファミリー名と優先サブファミリー名を使うということになっているようです。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (2) | トラックバック

2006年03月15日

PDFとフォント(5)　XSL-FOにおけるフォントの扱い

XSL-FOのフォントについての説明はCSS2を元にしていますが、細かく見ますとCSS2とは少し異なっています。

XSL-FO V1.0 仕様書 7.8 Common Font Propertiesでは、フォントについて大まかに、次のように説明しています。

(1) XSLのフォントモデルは、OpenType仕様で示される技術に準拠して説明されている。
※Microsoft, Adobe. OpenType specification v.1.2.

(2) フォントは、グリフと、そのグリフを表示するために必要なフォント・テーブルという情報の集合である。グリフとフォント・テーブルの集合をフォント・データという。

(3) フォント・テーブルには、文字をグリフに対応付けるのに必要な情報と、グリフの領域を決め、グリフの領域の位置を決めるのに必要な情報を含んでいる。各フォント・テーブルはフォントのウエイトやフォントのスタイルのようなフォントの特性から構成される。

ここで、注意すべきことは、フォントとは単なるグリフの集合ではなく、グリフを印刷平面上に配置していくための様々なデータを含んでいるということです。

さて、XSL-FOで使うフォントの属性は、次の6項目でほぼCSS2と同じです。
(1)フォントファミリー　font-family　<family-name>、または<generic-family>を指定。
(2)フォントサイズ　font-size
(3)フォントストレッチ　font-stretch
(4)フォントスタイル　font-style
(5)フォントの変形　font-variant
(6)フォントのウエイト　font-weight
※XSL-FOはCSS2を若干拡張していますが、あまり本質的ではないので省略します。

font-familyはCSS2と同じです。CSS2で出てきました時、説明しませんでしたが、属性に指定する<family-name>は、フォントの提供者がつける固有名となります。これに対して<generic-family>は、キーワードでserif, sans-serif, cursive, fantasy, monospaceの5種類があります。例えば、和文フォントではserifというより明朝という言い方が、sans-serifというよりゴシックという言い方が一般的です。cursive, fantasyは欧文フォントの概念で和文フォントでは一般的ではないように思います。無理にいえば、cursiveは連綿体に相当すると思います。monospaceは、欧文では手動タイプライタのフォントになります。和文フォントはもともと固定ピッチが基本なのでmonospaceというキーワードを和文フォントに適用するのは意味がないと思います。

<generic-family>はフォントの選択メカニズムで重要になります。

さて、CSS2もXSL-FOも上のように、その文字を可視化する際に使いたいフォントのプロパティを(1)から(6)の属性によって細かく指定できるわけですが、既に見ましたように実際に使うことのできるフォントのファミリーには、指定した属性のものが揃っているとは限りません。いや、むしろ揃っていないことの方が多いでしょう。

その時は、どうするのでしょうか？この時に重要になるのがフォントの選択メカニズムです。この辺については別途調べてみたいと思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月14日

PDFとフォント(4) 和文フォントのフォントファミリー

昨日は、欧文フォントのフォントファミリーはNormal、Italic、Bold、Bold Italicの4種類で構成されているものが多いようだ、と言いました。

それでは、和文フォントはどうでしょうか？Windowsについている最もポピュラーなフォントである、MS明朝やMSゴシックは1種類しかありませんからファミリーにはなっていません。

日本規格協会の文字フォント開発・普及センターが開発した平成明朝体、平成ゴシック体というフォントはいろいろなフォント・ベンダが商品化しています。現在ではかなり普及したフォントになっていると思います。

このフォントは、ウエイトについてファミリー化されています。アドビが商品化した平成明朝体、平成角ゴシック体、平成丸ゴシック体のフォント名とフォントファミリー名を見ますと次の表のようになっています。

いずれも、OpenTypeフォント、PostScriptアウトライン形式。

１．平成明朝体　(アドビ）のフォント名とフォントファミリー名

ファイル名 Font Name Font Family Name
HeiseiMinStd-W3 HeiseiMinStd-W3 平成明朝 Std W3
HeiseiMinStd-W5 HeiseiMinStd-W5 平成明朝 Std W5
HeiseiMinStd-W7 HeiseiMinStd-W7 平成明朝 Std W7
HeiseiMinStd-W9 HeiseiMinStd-W9 平成明朝 Std W9

2．平成角ゴシック体　(アドビ）のフォント名とフォントファミリー名

ファイル名 Font Name Font Family Name
HeiseiKakuGoStd-W3 HeiseiKakuGoStd-W3 平成角ゴシック Std W3
HeiseiKakuGoStd-W5 HeiseiKakuGoStd-W5 平成角ゴシック Std W5
HeiseiKakuGoStd-W7 HeiseiKakuGoStd-W7 平成角ゴシック Std W7
HeiseiKakuGoStd-W9 HeiseiKakuGoStd-W9 平成角ゴシック Std W9

3．平成丸ゴシック体　(アドビ）のフォント名とフォントファミリー名

ファイル名 Font Name Font Family Name
HeiseiMaruGoStd-W4 HeiseiMaruGoStd-W4 平成丸ゴシック Std W4
HeiseiMaruGoStd-W8 HeiseiMaruGoStd-W8 平成丸ゴシック Std W8

この3つの表を見ますと、フォントファミリー名のところにフォントのウエイトの名前が付加されているため全てのフォントがひとつづつ別のフォントファミリー名になってしまっています。つまり意匠上はファミリーであっても、OpenType仕様上でのファミリーになっていません。

このようになっていると、CSS2の font-family、font-weightでプロパティを指定してフォントを選択するというメカニズムを適用することができません。

フォントファミリーということを意匠・書体面の概念としてのみ捉えるのではなく、CSS2などに対応するブラウザで使うための技術仕様であるfont-familyとして捉えるのであれば、OpenType仕様で定めるFont family nameの項目には同一のファミリー名を設定しておかないといけないのではないでしょうか？

[2006/3/15 一部削除]
ザキンコ さんのご指摘により削除しました。詳細は、コメントをご覧ください。

[2006/3/15 追記]
ttfext.exeでFont Family Nameを見ますと、次の画面のようになっています。上の表の通りなのです。しかし、ザキンコ さんのご指摘のように、アドビの平成フォントは、別の箇所に、優先Font Family Nameを持っています。ttfext.exeの表示が不十分ということのようです。この点につきまして調査結果を、3月16日のブログで詳しく説明したいと思います。
HeiseikakuGo-ttext.PNG

投票をお願いいたします

投稿者 koba : 08:00 | コメント (2) | トラックバック

2006年03月13日

PDFとフォント(3)　欧文フォントのフォントファミリー

さて、手元のWindowsマシンに入っている欧文フォントのファミリーがどうなっているか、ちょっと見てみましょう。

OpenTypeのttfext.exeというツールを使うと、各フォントのフォント名とフォントファミリー名を見ることができます。

まず、 Monotype Typography, Inc.のArial 系OpenType (True Type Outline)フォントは、類似の名前のものが10種類入っています。このフォントファミリー名は次のようになっています。

ファイル名 Font Name Font Family Name
Arial Arial Arial
Arial Italic Arial Italic Arial
Arial Bold Arial Bold Arial
Arial Bold Italic Arial Bold Italic Arial
Arial Black Arial Black Arial Black
Arial Narrow Arial Narrow Arial Narrow
Arial Narrow Italic Arial Narrow Italic Arial Narrow
Arial Narrow Bold Arial Narrow Bold Arial Narrow
Arial Narrow Bold Italic Arial Narrow Bold Italic Arial Narrow
Arial Rounded NT Bold Arial Rounded NT Bold Arial Rounded NT Bold

次にAdobe SystemsのMinionPro系OpenType (PostScript Outline)フォント6種類のフォントファミリー名は次のようになります。

ファイル名 Font Name Font Family Name
MinionPro-Regular MinionPro-Regular Minion Pro
MinionPro-It MinionPro-It Minion Pro
MinionPro-Bold MinionPro-Bold Minion Pro
MinionPro-BoldIt MinionPro-BoldIt Minion Pro
MinionPro-Semibold MinionPro-Semibold Minion ProSmBd
MinionPro-SemiboldIt MinionPro-SemiboldIt Minion ProSmBd

MinionProは、SemiBoldの2書体がMinion ProSmBdというフォントファミリーで、MinionProとは別のファミリーになっています。他のフォントも同じようなものです。大半の欧文フォントはNormal、Italic、Bold、Bold Italicの4種類でフォントファミリーを構成しているようです。Condensedなどのファイル名がついているものもありますが、その場合、フォントファミリー名にCondensedがついているなど、CSS2のプロパティで指定して選択できるようなフォントファミリーを構成するものは、少なくとも手元のパソコンには見当たりません。

ですので、CSS2のフォント・プロパティではウエイト、幅などを指定できますが、フォントファミリーとこれらのプロパティが指定されたとき、既存のフォントファミリーの中から、その組み合わせにぴったりマッチするフォントが見つかる可能性はあまり大きくないと言えます。結局、ブラウザのフォントマッチング手法依存になってしまうのではないでしょうか。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月12日

PDFとフォント(2) フォントファミリー

フォントはいろいろなアプリケーションから使用します。

例えば、Microsoft Officeからフォントを指定して、PDFを作成する場合には、ユーザがフォントについて知識をもっていなくても、それ程、困ることがないでしょう。

InDesignやQuarkXPressなどのDTPソフトを使いこなす上では、フォントについての知識を多く持っている方が都合が良いのではないでしょうか。

これに対して、CSSやXSL-FOなどを使いこなそうとしますと、ユーザがフォントの仕組みについて知識をもっている必要がありそうです。

そこで、CSSの仕様でフォントについての記述を見てみましょう。CSSというのは、WebでHTML/XHTML/XMLの表示方法を指定するための仕様で、現在、W3Cが標準として勧告しているのは、次のCSS2です。

Cascading Style Sheets, level 2
CSS2 Specification
W3C Recommendation 12-May-1998
※なお、CSS2は改訂が進んでおりCSS2.1の最終ドラフトが公開中。CSS3も、現在、策定作業中です。

この15 Fontsを見ますと、フォントの指定方法と、ブラウザなどがフォントを選択する方法について記述されています。

1.フォントの指定方法
CSS2では、フォントについて次の特性を指定できます。
(1) フォントファミリー font-family
欧文フォントは、意匠デザインが同じ系統の幾つかのフォントをシリーズにしてフォントファミリーを構成するように作成しています。フォントファミリーでは、そのファミリーの名前を指定します。つまり、フォントファミリーを指定するということは、複数のフォントを一括して指定するという意味合いになります。

(2) フォントスタイル(font-style)
ファミリー中でnormal（通常）、oblique（斜めに傾けた形状）、italic（手書きに近い形）を指定します。

(3) フォントの変形(font-variant)
normal（通常）、small-capsを指定します。small-capsは小さめの大文字を指定します。ラテン文字のように小さめの大文字という使い方をもつ場合のみ有効です。

(4) フォントのウエイト(font-weight)
normal、bold、bolder、lighter、100～900で文字を構成する線の太さを指定します。

(5) フォントの字幅(font-stretch)
normal、wider、narrower、ultra-condensed～ultra-expandedで文字の幅を指定します。

(6) フォントの大きさ(font-size)
文字の大きさを指定します。

2.CSS2のフォント選択
CSS2ではこのように画面に表示したり印刷する時のフォントを、ファミリー名で指定して、さらにフォントの特性を指定するというやり方をとっています。

このようなやり方がうまく機能するには、フォントファミリーが、CSS2で定義しているような選択法にうまく適合するように作られている必要があります。

また、もし、指定したフォントファミリーの中に、うまく当てはまるフォントがないときに、代わりのフォントをうまく選択するフォントのマッチングという仕組みが必要になります。CSS2の仕様では、ブラウザなどで、ユーザが指定したフォントを選択するための仕組みを定めています。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月11日

PDFとフォント(1) 書体、グリフ、フォント

次に、PDFのための必須の技術の中で、フォントについて説明してみたいと思います。私は、フォントについては、少しかじったくらいであまり詳しくありませんので、いろいろ調べながらできるだけまとめてみたいと思っています。間違いがありましたらご指摘いただければ幸いです。

フォントとはなにかということを簡単に整理してみたいと思います。ちょっと古くなりますが、日経バイトの1994年2月号(pp.247～260)のバイト・セミナーに沼尾　禮子・林　隆男氏の連名で「フォント関連用語を正しく理解する」という記事が掲載されました。

その記事では、書体とフォントを区別して次のように定義しています。

(1) 書体は「一連の文字や記号の1セットに対し、印刷や表示のために、美観などのコンセプトに基づいて統一的に施された意匠デザイン」。
(2) フォントは「同一書体を元にして作られた、すべてのファミリ、変形、サイズを含む一連の文字・記号の1セット」。
(3) 書体は抽象的概念で、それを具象化したのがフォントである。

次に、TR X 0003:2000 フォント情報処理用語の関連部分の定義を見てみますと、次のようになっています。

(1) 書体（type face）「表示などに使用するため、統一的なコンセプトに基づいて作成された、一組の文字などの意匠」
(2) フォント(font)「ある書体でデザインされた字形の集合」
(3) グリフ(glyph)「文字の可視化表現またはその構成部分から大きさ及び意匠を正規化した抽象表現（JIS X4161 ISO/IEC 10036）」

JIS　X4161-1993 (pp.2-3)では次のようになっています。
(1) グリフ(glyph)「個々のデザインの違いを除去した認知可能な抽象的図記号」
(2) フォント(font)「基本デザインが同一であるグリフ像の集合」

さて、このブログでは、過去にグリフについて、
2006年01月13日 PDFと文字（22) – グリフとグリフセットで検討しました。そこでは、グリフとは、「文字を可視化した形状である」というPDF Referenceの定義に従うことにしました。

グリフとは抽象的なものか、それとも可視化した具象図形かという点に少し違いがありますが、概ね、次のようにまとめることができそうです。

・グリフとは文字を可視化した形状である。但し、リガチャのように複数の文字の連続を別の形状にして可視化する場合、複数の文字がひとつのグリフになり、アラビア文字のようにひとつの文字が複数(4つ)のグリフをもつものもあります。ですので文字とグリフは1対1対応とは限りません。
・書体とは意匠デザイン
・フォントとは、書体が同じグリフを集めたもの。

しかし、この定義は、大雑把過ぎて、実際に使うとなるとあまり役に立たないでしょう。次回、さらに、もう少し詳しく見てみたいと思います。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月10日

ヤンキー・グループのFlash調査報告

もう半年近く前のものなの（2005年10月）で新しい資料とは言えませんが、Flash導入3年目のNTTドコモという調査レポートがあります。

この手の米国調査会社のレポートは大抵、ベンダがスポンサーになっていて、販売促進資料として配布しているもので、このレポートもMacromediaがスポンサーになってまとめたものです。そういう意味では、Flashの販促用ということもできますけれど。

レポート（本文はPDF英文10ページ）のポイントを紹介します。
---ここから---
・NTTドコモは、2003年の早い時期にFlash Liteをi-mode端末に搭載して出荷を始めたが、2005年秋時点でNTTドコモの契約者の中で2000万（全i-modeの45%）がFlash Liteを利用可能な電話機をもっている。2005年末には2500万台になる見込み。
・第3世代（３G）電話機FOMAのユーザの90%にあたる約1400万台がFlash Liteを利用可能。
・i-modeの公式サイトは、2005年9月時点で4600あるが、その中で2000がFlash Lite対応になっている。非公式サイトは87,000以上で推定20%がFlash Lite対応。

KDDIのauは、1年ほど遅れてFlash Lite1.1を採用し、1年遅れでドコモを追撃している。
---ここまで---

この数字をみますと、Flash Liteが随分普及しているという印象がありますね。私は、auなのであまり普段見てませんでしたが。

Flash LiteとSVG Tiny
ところで、Flash Lite 1.1からSVG Tiny の表示をサポートしています。だから携帯電話にFlash Lite 1.1が普及すれば、自動的にSVG Tinyも普及するという構図になるはずです。

MacromediaのFlash Lite サポート対象の携帯デバイスには、NTTドコモの機種が、40機種掲載されています。（ざっと数えたのみなので間違いがあるかもしれません。大筋でみてください）。
・富士通　9機種
・三菱　5機種
・NEC　8機種
・松下　7機種
・シャープ　6機種
・ソニーエリクソン　5機種
-----------
合計　40機種

この中で、富士通の4機種だけが、Flash Lite 1.0で他の機種はすべてFlash Lite 1.0とFlash Lite 1.1に対応しています。

ドコモのFOMAのFlash対応機種は、ほとんどFlash Lite 1.1になっているようです。こうみますと、SVG Tiny を表示できる携帯電話って1500万台以上はあるのではないでしょうか。

そうしますと、2006年03月07日SVGの行方は？で紹介しましたスウエーデンのIkivo AB社の950万台という推定は少なすぎるように思いますね。Ikivio ABはFlash Liteを計算に入れてないのかな？

但し、Flash LiteFAQの、なぜSVG Tinyをサポートしたかというところを見ますと、
・SVG-Tを組み込む決定の理由
・FlashはSVG-Tをサポートしますか？
・FlashはSVG-T仕様に準拠していますか？
の３つの質問への回答は、SVG Tinyに対してあまり前向きとは言えないようです。


投票をお願いいたします

投稿者 koba : 08:00 | コメント (3) | トラックバック

2006年03月09日

SVGの行方　キラーアプリケーションは何？

さて、SVGの未来について、アドビが関心ないとか、谷間のゆりとか否定的なことを書いてきましたが、ではSVGには未来はないのでしょうか？

SVGのファイル形式はPDFにかなり似ています。大雑把に言えば、SVGはPDFの代替手段であると言っても良いと思います。しかも、PDFと比べるとかなりシンプルになっています。

PDF仕様はPostScriptをベースにしていることもあり、ものすごく大きな仕様となっていて極めて扱い難いものです。これに対してSVGの取り扱いはPDFより遥かに簡単です。取り扱いし易いというのは、SVGのもつ、PDFにはない大きなメリットです。

ですから、使い方によっては、非常に大きな威力を発揮するように思います。

先日来お話しましたように、SVGが普及していないのは、技術的な問題というよりも政治的な問題が大きいと思います。こう考えますと、キラーアプリケーションを見つけることができればSVGにもチャンスが巡ってくると言えます。

どの辺にSVGのチャンスがあるのでしょうか？
（1） 現在は、SVG-Tinyが携帯電話へのデータ配信・表示に使われているのが最大の用途でしょうか？しかし、PDFやFlashが携帯電話に普及してきますと単なるデータ配信用途では太刀打ちできないような気もします。

（2） 第2は、日本で進んでいる地図の配信用です。これは、goSVG（g-contents over SVG）という、地図情報の配信をSVGで行うプロジェクトがあります。これは結構期待が持てるように思います。

※GIS･MapServerリファレンス

(3) W3Cには、SVGPrintという仕様の草案があります。SVGPrintは、詳しく読んでいませんが、SVGを印刷用のページ記述言語（PDL）の代わりに使おうということのようです。まさしく、PDFの代わりにSVGを使おうということですね。この草稿2003年7月発表ですが、その後進んでいるのでしょうか？

ちなみに、アンテナハウスは、XSL FormatterでXMLをページアップした結果をSVGに出力するオプションを用意しています。また、サーバベース・コンバータでMicrosoft Officeドキュメント、PDFからSVGへの出力もできます。

私としては、将来、Web上でのページアップされた情報配信のメディアとしてPDFだけではなく、その代替手段としてSVGも候補になることを願っています。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (2) | トラックバック

2006年03月08日

SVGの行方は谷間のゆり　？

アンテナハウスの提携先でいつも中国語講座をしていただいている田中先生のすぐ話せて書ける“痛快中国語講座”。

ここに、次のような絵があります。
VRM-IE.PNG

上の絵は、マイクロソフトのInternetExplorerで表示したものです。ところが、これをFireFoxで表示すると次のようになってしまいます。折角のイラストの部分が脱落してしまった状態で、正しく表示されていません。

VRM-Firefox.PNG

この理由は、脱落する部分の画像がVML (Vector Markup language) というMicrosoft独自のベクトル画像（線画）形式で記述されているためです。VMLはFireFoxのようなブラウザでは表示することはできないので壊れた画像の絵がでてしまいます。

画像形式を大別すると、イメージ画像とベクトル画像に分かれます。このうち、ベクトル画像の標準形式としてW3Cが策定したのがSVG (Scalable Vector Graphics) なのです。

インターネットの線画標準の策定過程で、VMLはもともとW3CにWebの標準仕様案として、Microsoft、HP、AutoDesk、Visioの技術者の連名で1998年に提案されました。
Vector Markup Language (VML)

ところが、一方で、アドビシステムズ、IBM、Sun、Netscapeの技術者が、Precision Graphics Markup Language (PGML)という仕様案を提案してます。

このような２つの対立する提案の結果として生まれたのがSVGと言うわけです。このためかどうか、SVGはMicrosoftにはまったく見向きもされていません。MicrosoftはOfficeを初めFrontPageのようなWebページ・デザインソフトでも、依然としてVMLを使っています。しかし、VMLは標準仕様とは言えません。

一方のブラウザで正しく表示できるものが、他方のブラウザで正しく表示できないという問題は、このインターネットの標準を巡る2大陣営の戦いの帰結ということができます。

一方、SVGは、FireFoxでかなり（完全ではない）表示できますが、FireFoxのシェアはわずか5%内外でしょう。また、IEでもアドビのSVGビューアがインストールされていれば表示できます。そういう意味ではかなり普及していると言えるかもしれませんが、圧倒的なシェアをもつMicrosoft系のアプリケーションに無視されているということでは、標準仕様としては弱いでしょう。

そうして、昨日お話しましたように、アドビもあまり関心をもっていないということになりますと、まさに、SVGの将来は谷間のゆりになってしまうかもしれません。

インターネットにおける線画の表現形式の標準が普及していない、というのはユーザにとっては不幸なことではあります。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月07日

SVGの行方は？

アドビのCEO Bruce Chizenのインタビューを読んでいて気になったことを、もうひとつ挙げます。
それはSVGの行方です。

SVGは、Scalable Vector Graphicsの略で、W3Cが制定しているWebなどで使うためのベクトル・グラフィックスの標準です。2003年にV1.1仕様が勧告となっています。

・SVG V1.1仕様
Scalable Vector Graphics (SVG) 1.1 Specification
W3C Recommendation 14 January 2003

SVGには、フルセットの仕様のほか、携帯などで使うためのSVG Tiny、SVG Basicなどのサブセットの規格もあります。

・SVGモバイル仕様
Mobile SVG Profiles: SVG Tiny and SVG Basic
W3C Recommendation 14 January 2003

SVG Tiny は携帯電話用のビューアとして使われることも多く、スウエーデンのIkivo ABの推定では、SVGビューアを搭載したモバイル機器が世界で950万台出荷されているとしています。

Over 60 Million Ikivo Powered Mobile SVG Handsets Shipped

現時点では、携帯電話用のビューアとしてSVG Tiny がFlashと並ぶ存在と言っても過言ではありません。

SVGの仕様策定にあたってはアドビの技術者の貢献が大きかったと思います。現在もアドビはSVG仕様の編集者を出していますし、SVG仕様はPDFと非常に似通ったところがあります。

現在の時点でもPC用のSVGV1.1ビューアとしては、アドビのSVGビューアが一番ポピュラーでしょう。

Adobe SVG Viewer 3

しかし、アドビのBruceのインタヴューではSVGは一言も出てきません。

SVG Tinyが携帯用ビューアの有力候補なのですが、アドビはSVG Tinyではなく、FlashLiteとPDFのセットで携帯に取り組むということです。そうすると、SVG Tinyはどうなってしまうんでしょう？

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月06日

アドビのマルチ・プラットフォーム作戦の行方　Linuxを買収？

アドビのCEO Bruce Chizen のWhartonインタビュー読めば読むほど面白い。アドビは、幾つかの事業をもっているのですが、Bruce は、その一つとしてengagement platform構想について熱く語っています。

このアドビのengagement platform構想を追求していくと、恐らくLinuxをどれか買収しなければ済まないのではないか？という気がします。

以下は、私の妄想ですので、そう思って気楽に読んでください。間違っても、どこかのLinuxベンダの株を買いに走ったりしないように。Linux株で損しても、私は一切責任をもちませんから。

まず、アドビがMacromediaを買収した最大の目的はFlashだ、と述べています。そうして、FlashとPDFを組み合わせて、マルチプラット・フォームで表示系を抑えるということを狙っているようです。

engagement platformで、Windows、Macintosh、SunなどのPCまたはワークステーションなどのコンピュータ系だけではなく、携帯電話のようなモバイル機器、自動車、あるいは、eBookなどの読書端末までをカバーしようとしています。インタビューでは、後者をmini engagement platformとしています。

まず、コンピュータ系の世界で考えますと、Bruceの発言でもありますが、アドビのengagement platformは、Microsoftが支配するWindowsの世界では、それ程大きな価値はありません。Windows以外のコンピュータが増えないと価値が大きくならないのです。

さらに、engagement platformは表示用途ですので、サーバ・コンピュータ用ではなく、デスクトップ・コンピュータ用となります。ところで、いま、注目を集めているLinuxはサーバ用途では普及が進んでいますが、デスクトップ用途ではなかなか普及が進みません。なぜかと言いますと、デスクトップではマンマシン･インターフェイスであるグラフィック・ユーザ・インターフェイス（GUI)が重要なのですが、LinuxOSにはWindowsのような優れたGUIシステムがないからです。そうするとengagement platformの価値を増大するには、LinuxOSにWindowsシステムを構築するという大掛かりな投資が必要となります。従って、これをどうするかがアドビの次の課題ということになります。

mini engagement platformについていえば、例えば日本の携帯電話のOSは、一時はTronが主流でした。しかし、Tronは減っていると思います。世界的に見ますと米国Qualcom社のBrew、英国シンビアン社のSymbianOSを見逃すことができません。最近はLinuxを組み込んだ携帯電話も増えています。
・「2005年度は1000万台近いLinux搭載3G携帯を出荷する」---NTTドコモ 照沼和明氏

アドビのPDFは一部の携帯電話に載っていますが、あまりメジャーな存在にはなっていません。Flashを欲しかった最大の理由は、恐らく携帯電話への取り組みの遅れを取り戻したかったことが大きな動機になっていると思います。そうすると、mini engagement platformの分野でMicrosoftを出し抜くための、アドビの次の一手は組み込みLinuxを手に入れる、ということになりそうです。

どっちにしてもLinuxだ！

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月05日

文字符号の歴史　「欧米と日本編」

「文字符号の歴史　欧米と日本編」　（安岡孝一・安岡素子著、6,000円＋税、共立出版、ISBN4-320-12102-3、2006年2月1日発行）が発行されたことは、文字のメーリングリストで紹介されていましたので、知っていましたが、たまたま神田に行く用事があったので書泉で買ってきました。

このブログでも何回か紹介しました、「文字符号の歴史　アジア編」（三上　喜貴著、共立出版、2002年、ISBN4-320-12040-X、2002年3月20日発行 ）と並べてみますと、2冊が姉妹書として企画されたことが良くわかります。

20060304.PNG
※左がアジア編、右が欧米と日本編

アジア編は、各国の文字コードについての情報がものすごく豊富でさすが、という本でした。

欧米と日本編は、まだ詳しく読んでいないのですが、資料がいろいろ載っているのは将来のために参考になりそうです。なにはともあれ、こういう本をまとめた安岡ご夫妻にご苦労様と申し上げたいです。

こういう2冊の本が、文字コードがUnicodeの時代に大きく変わって行こうとする今の時点ででたことは大きな意義があると思います。いづれも大体2000年頃までの話になっていますので、20x0年頃に続きがでることも期待しましょう。

特に、アジアの文字については、次回は、誰かKen Lundeに負けない本を出してもらいたいものです。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (4) | トラックバック

2006年03月04日

Macromedia吸収後のアドビ、次のステップ

アドビのCEO Bruce Chizen のWharton School of Businessでのインタービューは一読の価値があります。

アドビは、2005年12月にMacromediaの買収を終えたわけですが、その大きな狙いは冷蔵庫、自動車からビデオゲーム、コンピュータ、携帯電話までのすべてのデバイスの画面にインターフェイスを提供することだと言っています。

これは、まさにMicrosoftの組み込み用Windows戦略とぶつかります。逆に、MicrosoftのWindows VistaはPresentation Foundation、XML Paper Specification、Office12のPDF生成などアドビの大きな収入源であるPDF分野を浸食しようとしています。

いままで、アドビとMicrosoftは、うまく分野を棲み分けて、あまり正面衝突はしてこなかったように思いますが、これからは両雄の激突必至となりそうです。

このインタービューでは、いまや、世界で5番目に大きなソフトウェア・メーカとなったアドビの次のステップについて語られています。

ポイントは：
（1）アドビはMacromediaの買収でフラッシュを手に入れ、これによってPDFとFlashを合わせて、あらゆるプラット・フォーム、あらゆるOSで対話的な表示機能を提供できるようになった。特に、携帯電話分野でFlashの採用実績が多いことに期待しているようだ。

（2）また、アニメーションからビデオまでの編集ソフトの技術も手に入れた。アドビのCreative Suite製品との連携を考えているようだ。DTPにビデオ編集まで一緒にして、制作者向け製品の充実をする。

（3）この3年程LiveCycle製品を中心に、企業向けのシステム製品市場（ワークフロー分野）に取り組んできた。難しかったが、ようやく利益がでるようになってきた。Macromedia買収で、企業向けの営業力も倍増できた。

（4）Acrobatは、6億から7億ドルのビジネスになっている。Microsoft Office 2007がPDFを出力できるようになることでPDF生成分野の収入が減るのは仕方ない。PDFはオープン・スタンダードになっていて、サードパーティ製品も既に一杯あることだし。アドビは、ここ5年ほど、Acrobatに対して、PDF作成以外の付加価値をつけることを行ってきた。なので、PDF作成が無償になってしまっても収入が減ることはない。またBreezeとAcrobatの合体を考えている。

これを読みますと、アドビはPDFとFlashを合併して、携帯電話、家電製品、自動車などの組み込み分野でOSメーカのようなプラットフォームを提供しようとしていることがわかります。しかし、ブラウザをやるつもりはないと言っていますので、あくまでリッチ・クライアント分野ということになります。

次に、マイクロソフトと戦う姿勢をかなり明確に発言しています。マイクロソフト側が、XPSなどでアドビの市場を浸食しようとしているわけですが、これをV1.0の試みと言い切り、アドビとMacromediaはもう10年以上の経験をもっているので、勝者はこちらだと自信の程を示しています。

確かに、PDF誕生後既に10年以上経って成功はしたと思いますが、PDFはあくまでアプリケーション。これに対してWindowsはOSです。アプリケーションをもってOSと競争するというのはおかしな図式ではあります。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月03日

PDF/A とコンシューマ・デバイス

PDF/A仕様はISOの標準になったことを以前に読んで頭の片隅にありました。
例えば、PDF/Archive Secures ISO Approval

これは、PDFを長期に保管するための仕様で、どうせ電子図書館用の仕様だろうからあまり重要じゃないだろうと思ってました。

しかし、アドビシステムズのBill McCoyのブログMore on PDF/Aを読むとどうやらそうではないようです。

PDF/Aは、アドビが、NTTドコモ、アクセス、ノキアの携帯電話などのPDFビューアや、ソニーの電子ブックビューアSony Reader PRS-500に提供しているPDFビューアは、PDF/Aをベースとして拡張したPDF/A+というべき仕様に基づいていると言っています。

これらのコンシューマ・デバイスでは、パソコンとは違って、CPU、メモリなどのコンピュータ資源が乏しいため、PDF1.6をフルに実装したビューアを動かすのは無理があります。

Bill McCoyによると、そういうコンシューマ・デバイス用に制限したPDF仕様としてPDF/Aが重要とのことです。

この他、PDF/Aが重要なポイントとして、次のことをあげています。
（１）AppleのQuartzのような異なるイメージング・モデルなどで動く代替ビューアを可能にし、クロス・プラットフォームでビューア開発ができる。

（２）新しい機能を使ったPDFが、古いあるいかサブセットのビューアで見えにくくなるという問題に焦点をあてている。

（３）PDFの中のスクリプトなどのプログラムを使えなくすることで、PDF表示のコンピュータへの依存性、セキュリティ上の危険性を減らす。

こうしてみますと、PDF/Aに対する認識を改める必要がありそうです。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月02日

Facilis Guardianでチェックできる項目

次のリストはFacilis GuardianでPDFについてチェックできる項目です。

・フォントの埋め込み
・トラッピング
・オーバープリント
・CMYK、RBG画像
・PDFのバージョン
・スクリーン線数指定
・ICCプロファイル指定
・PDF/x-1a、PDF/x-3かどうか
・Adobe以外の製品でPDF変換したかどうか
・PDF変換した製品の情報が不明か
・用紙サイズの異なるページがあるか
・回転指示の異なるページがあるか

このソフトでは、監視対象ホルダを設定し、その監視対象フォルダにコピーされたPDFファイルを検出して、自動的にチェックすることができるようになっています。フォルダ毎に、次のようにチェック項目を指定しておくことができます。

CheckItems.PNG

さて、試しに、アンテナハウスのPDF Driver V3を使って一太郎から作成したPDFを検査してみました。しばらく待ちますと、処理が終了したところで、結果は次のような画面に表示されます。

Result.PNG


ジョブ情報のペインには検査結果が、埋め込みフォントと非埋め込みフォントのペインには、それぞれの該当するフォント名のリストが表示されます。

検査が正常に完了しますと、RIPで作成したTIFFのファイルが出来ています。そこで、検査対象ファイルをマウスで右クリックして、TIFFのプレビューを表示したり、あるいはTIFFやPDFによるゲラだしを行うことができます。

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月01日

印刷ワークフローの中でPDF関連の問題

さて、一昨日の続きですが、Facilis Guardianを使う目的は、入稿したPDFを自社の出力システムで問題なく処理できるか、ということをできるだけ早く、問題が起きる前にチェックすることとなります。

本当は、このようなチェックは印刷会社ではなく、印刷を発注する企業の方で行ってからPDFを渡す方が、手戻りがなくなり、効率的でしょう。しかし、発注者側で、発注先の印刷会社のRIPを特定したチェックを行うというのは、役割分担として難しく、結局、受注者である印刷会社が泣いているのが現状のように思います。

では、PDFを印刷する工程で、実際にどんな問題が起きているのでしょうか？

梶間社長は次のようにまとめています：
・Web用に作成したページに混入している印刷に向かないPDFファイルが入稿される。
・別々に作成したPDFをつなぎ合わせたり、ページ単位で差し替えるケースが増えている。Adobe Reader では表示できても、CTP出力できないページが紛れ込む。
・PDF変換情報が不明のPDFファイルが増えているが、うまくCTPできないことが多いので早くより分けたい。
・単色ページものとして受注したもので、表示はモノクロでもカラーモードの画像の混入が増えている。
－単色ページ物なのに、あるページの範囲がCMYKモードになっていて、白色のCMY版が出る。
－単色ページ物なのに、カラー画像が混じっていて、画像が小さくて見落としてしまう。これは、PDF/X-1aにしても防げないケースがある。
－単色テキスト部分がカラー分版される入稿が後を絶たない
・フォントの埋め込み忘れ。
・CTPのRIPが処理エラーを起こす。RIPが落ちてしまう。
・用紙サイズが異なるものが混在するため、面付け結果がおかしくなる。
－用紙サイズが違うページが混在し、トンボが紙面に入る。
－アートボックス指定のページが混在する。
－回転指示が入ったページが混在する。
･オーバープリント

こういうのを読みますと、現在のようにいろいろな種類のPDF作成ソフト、PDFを編集するツールがある状況では、確かにいろいろ問題がでるのだろうな、と思います。

当社のように、PDF生成、PDFを分割・結合こともできるツール「リッチテキストPDF」などを出している会社としては、こういうことが起きないようにする責任も感じます。

〔参考資料〕
分かったつもりの印刷用語CTP
これからのCTPワークフローは・・・

投票をお願いいたします

投稿者 koba : 08:00 | コメント (0) | トラックバック