PDF　千夜一夜

« 2008年03月 | メイン | 2008年05月 »

2008年04月30日

電子書籍システム

先日、松下電器の読書端末「ワーズギア」の生産終了の話をご紹介しました。

2008年04月27日　読書端末「ワーズギア」の生産終了

他にはどんなのがあるのだろう、また電子書籍の業界は、最近、どうなっているのだろうと気になりましたので、引き続いて少し調べてみました。

電子書籍の専用端末では、ソニーの「LIBRIe（リブリエ）」が有名なようです。
◎LIBRIe　ソニー
・Webページ
　EBR-1000EP　

しかし、このリブリエもWebでは生産完了となっています。紛らわしい表現ですが生産終了のことのようです。

◎Flib
Ｇｏｏｇｌｅで電子書籍で検索しますと　Flibという電子図書館が上位にきます。これはシンガポールの E-Book SystemsPte Ltd.社が開発しているFlipBook技術を使っているようで、技術を売るために、電子図書館を作っているようです。やや本末転倒な気がします。

・イーブック・システムズ株式会社
が推進しています。ハードウェアはパソコンです。

◎パピレス
ここは、ハードウェアとしてはパソコンと携帯電話となっています。
ファイル形式と必要なビューア（パソコン）
・KeyringPDF形式　→（特別なDRM付きPDF）
・XMDF形式　→ブンコビューア（無料）
・.book形式　→T-Time（無料）
・Adobe eBook形式　→Adobe Reader
・蔵形式　→蔵衛門8デジブック
あと携帯に対応です。

◎eBookJapan
ここはコミック（漫画）中心です。
・ファイル形式は分かりませんが、専用リーダebi.BookReaderをインストールして使うようです。
パソコン（Windows）のみで携帯電話は未対応のようです。

ざっと見てみただけですが、こうしてみますと、電子書籍がだめというわけではなくて、どうも電子書籍用の専用端末がだめってことのようです。

いまは、携帯小説が好調という話を聞いていますが、このあたり、1980年代に登場したワープロ専用機がパソコンのワープロに押されて、2000年代に入って短い期間で絶滅したのをなんとなく連想してしまいます。専用のハードウェア＋ソフトウェアは、汎用のハードウェアとソフトウェアに勝てないという一般化に、かなりの妥当性がありそうです。

投票をお願いいたします

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

2008年04月29日

PDFに、印刷するときの用紙の横置き、縦置きを指定する方法はある？

次のような質問を受けました。

「PDFをプリンタで印刷するとして、プリンタに用紙を縦置き（ポートレイト）するか、横置き（ランドスケープ）で使うかを、PDFファイル上で指定する方法はあるのでしょうか？」

どうも、PDFの仕様書を見ても、そういう方法はなさそうです。

PDFでは、独自の座標系をもっており、左下、右上の概念はありますが、用紙という概念はありません。そして、PDFのページに設定できるのは、境界ボックスと90度単位の回転角度のみです。

これをプリンタが用紙の上にどうやって対応つけるかは、印刷する方の側の問題ということになります。

※PDFの境界ボックスについてはこちらをご参照ください。
2007年11月30日　PDFのページ境界とXSL-FOの設定方法

ところで、それに関連して、AdobeのPDF Driverを見ていましたら、LayoutタブにOrientation（方向）という設定があります。
・Portlait
・Landscape
・Rotated Landscape
という３つのメニューがあります。

これは一体何をするものなのでしょうか？良くわかりません。どうも、用紙の設定ではなくて、ページの内容の表示領域だけを変更してしまうようです。

(1)Wordで用紙を縦置きとして、Adobe PDF DriverでPortlaitを指定。
・Wordの設定

・Adobe PDFの設定

そうしますと、PDFは正しく出ます。
・

(2)Wordで用紙を縦置き（Wordの設定は(1)と同じ）として、Adobe PDF DriverでLandscapeを指定。
・Adobe PDFの設定

そうしますと、用紙は縦に使いますが、内容が横長になるようです。

Adobe PDF Driverのこのメニューは一体何のため？

投票をお願いいたします

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

2008年04月28日

DITA関連のコミュニティと参加者人数など動向

YahooのDITAメーリング・リストに27日投函されたメールにDITA関連のコミュニティと参加者人数の情報が載っていましたのでご紹介しておきます。

１．Yahooメーリング・リスト

dita-users@yahoo.com (参加者数：1900人)　
○アーカイブはこちらです。
http://tech.groups.yahoo.com/group/dita-users/messages

ちなみにYahooGroupで見ますと、約1,760人となっています。なお、Yahoo のXSL-FOグループは、約1,500人です。SVG-Developerは約7,900人。

２．OASISの公式コミュニティ DITA.XML.org
<http://dita.xml.org/>　(メンバー数：1300人）

３．DITAニュース　
the DITA News <http://www.ditanews.com/>/DITA Users<http://www.ditausers.org/>コミュニティ (メンバー数：600人)

４．STC：　Society for Technical Communicators
<http://www.stc.org/> (参加者数：13,000人)

５．TECHWR-L
<http://www.techwr-l.com/techwhirl/index.php3>　寄稿者：2,500人

６．Content Wrangler Community
<http://thecontentwrangler.ning.com/>
　　(参加者 1,600人のソーシャル・ネットワーク）

こうしてみますと、DITAの専門ネットワーク参加者は、まだ2,000人弱ということになりそうです。

2006年、2007年と過去2回DITAに対する関心が高まっていますとお伝えしましたが、2008年3月まで見ましても、まだ、YahooのDITAグループへの発言数が増えています。
■月間発言数の推移

ご参考：
・2007年08月16日　DITA、初のバージョンアップでV1.1となる
・2006年08月24日　DITA への関心が急激に高まっています

DITAは、かなり難しいですから、腰を据えて取り組んでいきたいものです。

なお、2005年から2007年まで毎年11月に、欧州で開かれていましたDITAの欧州会議（DITA European Conference）は、今年2008年はどうも開催されないようです。主催者の話ではドル安で開けないということだそうですが。大変残念です。米国のXML業界の景気は相当悪いのでしょうか？でも欧州のXML業界は景気が良さそうに思いますけど。

○2008年6月26日　DITAヨーロッパがミュンヘンで開催のアナウンスがありましたので上記の情報を訂正します。
　PDF千夜一夜の2008年6月30日で紹介しますので、ご参照ください。

投票をお願いいたします

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

2008年04月27日

読書端末「ワーズギア」の生産終了

松下電器・角川モバイル・東京放送の3社合弁で、ワーズギア(株)という電子書籍事業を行っています。ワーズギアのWebページを見ましたら、2008年3月27日付けで　読書端末ワーズギアが生産終了のお知らせが出ていました。

ワーズギアは、テキスト、ドットブック（.book）やXMDFという電子書籍フォーマットで電子書籍を閲覧できます。この他、クセロ製のPDF Viewerが載っていて、書籍をPDFで閲覧することもできるようになっていました。

ワーズギアPDFビューア発売のニュース

PDF版の書籍を使うにはPDF利用権（1,480円)を購入するというユニークな仕組みです。しかし、PDFで読むのに、読者がわざわざ1,480円を払わなければならない、というのは無理があったのではないでしょうか。

普通の人が、電子ブック端末で本を読むためだけのために、有償でPDFビューアの利用権を購入するとは思えません。もう少し魅力的なフレームワークを考えないといけないでしょう。

電子書籍ビジネスがだめとは思いませんが、それにしても、現実はなかなか難しいようです。

ご参考
○電子書籍Wiki
　　○ハード紹介
　　　　○ワーズギア
　　　　○シグマブック

投票をお願いいたします

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

2008年04月26日

4月28日 XSL Formatter V4.3を発売

弊社では、4月28日よりXSL Formatter V4.3を発売します。

XSL Formatter V4.3はV4.2に比べて以下の点が機能追加となります。
1. Windows x64版がラインアップに追加されました。
2. CGMオプションが追加されました。
3. INX出力オプションが追加されました。

Formatterの32ビット版も64ビットWindows上で動作はします。Formatterの64ビット版ではメモリ空間が大きくなりますので、32ビット版では扱えないような巨大なFOを組版できると思われます。但し、巨大なメモリを搭載したマシンでないと確認できないため、実証されていませんけれど。

他になにか64ビット版にするメリットがあるのだろうかと思い、とりあえず、FOを組版してPDF化する速度を比較してみました。次の表は、FormatterのマニュアルのFOを組版してPDF化するための所要時間を、64ビット版と32ビット版で比較したものです。

64ビット版の方が、わずかに速い程度ですが、実際のところほとんど差がないようです。

	64 bit版	32bit版
初回	95秒	99秒
2回目	95秒	98秒

【計測の条件】
１．Windows Vista 64bit版の上で、Formatter V4.3の64ビット版と32ビット版を比較。
２．コマンドライン・インターフェイスを使用。入力ファイルを引数指定によりプログラム起動からPDF出力完了までの処理時間を計測。
３．入力はFO。出力はPDF。　全フォントを埋め込み。PDFのページ数は213ページ。
４．Pentium 1.80GHｚ　メモリ1015MB、Windows Vista Ultimate 64ビットOS

注）通常、初回は、FOファイルをハードディスクから読み込んでメモリに載せる時間が掛かります。2回目はFOがオンメモリ（キャッシュ）に載っています。このため、初回と2回目ではファイルをハードディスクから読む時間に相当する処理時間の差がでます。上の計測で差がでなかったのは、コマンドラインの起動前に、GUIで何回か組版したので、FOファイルがメモリに載っていたためと思います。

この結果を見ますと、少なくともこの程度のPDFを作るには、64ビット版はぜんぜん必要ありません。64ビット版って、大きなFOを扱える以外に何かメリットあるのでしょうか、ちょっと疑問です。

このほかにオプションですが、CGMを自力で組版する機能、それからInDesｉｇｎの外部ＸＭＬ形式ＩＮＸを出力できるようになります。

CGMは、これまで、ずっと要望がありましたが、漸くできたというところです。

○CGMにつきましてはこちらもご参照ください。
・2008年02月16日　ありそうな、なさそうな、CGMビューア（１）
・2008年02月17日　ありそうな、なさそうな、CGMビューア（2）

○INXについてはこちらもご参照ください。
・2007年10月06日　PDF/A Competance CenterとAIIMが戦略的提携
・2007年10月19日　INXCreator Preview

○ニュース・リリースはこちらです。
「XSL Formatter V4.3 」2008年4月28日出荷開始

投票をお願いいたします

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

2008年04月25日

PDF 1.7 仕様に用意されている注釈

昨日、リンク注釈について触れましたが、PDF の仕様には他にどのような注釈があるのか「PDF Reference, version 1.7」で確認したところ、Annotation Types として定義されているのは実に 25種類になります。では、それらすべてが Acrobat 8 Pro で使用できるのでしょうか？ちょっと調べてみました。

以下、左側が「PDF Reference, version 1.7」に記載されている注釈、右側が Acrobat 8 Pro の GUI で用意されているツールの名称です。ツールはメニューバー、ツールバーの両方に用意されていますが、ツールの名称としては主にツールバーにあるものを採用しました。

PDF Reference	Acrobat 8 Pro
Text annotation	ノート注釈
Link annotation	リンクツールまたはテキスト注釈で文字列を選択後「リンクの作成」
Free text annotation	引き出し線ツール、テキストボックスツール
Line annotation	矢印ツール、線ツール
Square annotation	長方形ツール
Circle annotation	楕円形ツール
Polygon annotation	雲形ツール
Polyline annotation	-
Highlight annotation	テキスト注釈で文字列を選択後「テキストをハイライト表示」、または「テキストにノートを追加」、またはハイライトツール
Underline annotation	テキスト注釈で文字列を選択後「テキストに下線を引く」
Squiggly-underline annotation	-
Strikeout annotation	テキスト注釈で文字列を選択後「テキストに取り消し線を引く」、または「選択したテキストを置換」
Rubber stamp annotation	スタンプ注釈
Caret annotation	テキスト注釈で文字列を選択後「選択したテキストを置換」、またはテキスト注釈で位置を指定後「カーソルの位置にテキストを挿入」
Ink annotation	鉛筆ツール
Pop-up annotation	※1
File attachment annotation	メニューバーの注釈から「注釈ツール」－「ファイルを注釈として添付」
Sound annotation	-
Movie annotation	-
Widget annotation	署名、フォーム
Screen annotation	ムービーツール、サウンドツール
Printer's mark annotation	-
Trap network annotation	-
Watermark annotation	※2
3D annotation	3Dツール

※1、Pop-up 注釈は、今回 Acrobat 8 Pro での対応を確認した注釈の内、「Text、Line、Polygon、Highlight、Underline、Strikeout、Caret、Ink」注釈の出力時に同時に作成されます。
※2、Acrobat 8 Pro には、透かしを追加する機能がありますが、Watermark 注釈は使用されないようです。

私の確認した限りこのようになりましたが、今回見つからなかった注釈の中には Acrobat 8 Pro が対応しているものもあるかも知れません。

投票をお願いいたします

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

2008年04月24日

リンク注釈について

PDF の仕様にある「リンク注釈」とは具体的にどのような注釈なのかという質問がありました。

PDF の仕様（PDF Reference, version 1.7）では、リンク注釈は次のように定義されています。

A link annotation represents either a hypertext link to a destination elsewhere in the document (see Section 8.2.1, “Destinations”) or an action to be performed (Section 8.5, “Actions”).

つまり、リンク注釈とは PDF 文書内の「宛先」へのハイパーテキストリンク、または「アクション」を指定する注釈です。

この宛先にはページ番号とその表示方法の指定ができ、表示方法としては仕様では 8種類が用意されています。例えば Acrobat 8 Pro の「リンクツール」を使用してリンク注釈の表示方法を編集すると、ダイアログでは「ズーム」として 5種類の表示方法（「全体表示」、「100%表示」、「幅に合わせる」、「描画領域の幅に合わせる」、「ズーム設定維持」）が用意されています。

アクションでは、宛先と同じこともできますが、他文書内への宛先や URI 指定、Sound、Movie 再生といった PDF の仕様に用意されている様々なアクションを指定することができます。以下のキャプチャは、Acrobat 8 Pro の「リンクツール」に用意されているアクション項目です。

投票をお願いいたします

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

2008年04月23日

オープンソース長期署名ライブラリーのソースが公開されました

弊社の関連会社　ラング・エッジは、以前よりXML長期署名を開発し、ライブラリーを公開していましたが、この程、Le-XAdESライブラリのソースのソースが公開されました。

Le-XAdESライブラリ / XAdES署名ツール XAdEStool

いままで、長いことβ版でしたが、4月にV1.0になったのかな？しかし、知らない間にV1.01になってます。ずっといままで、バイナリの公開だけだったようですが、遂にソースの公開に踏み切ったとは、なかなか大胆な決断です。

長期署名は、まあ、会社がなくなっても検証されねばならないでしょうし、オープン・ソースにする方が良いかもしれませんね。

私的には、オープン・ソースの考え方はあまり好きではありませんけれども。

長期署名は、これから、だんだん重要度が増していくと思います。しかし、実際のところは長期署名の前に、署名対象になる電子ファイルの長期的な利用可能性をどうやって保証するか、ということの方がその前提になる重要な課題だろうと思います。

電子ファイルに署名をつけて、それを遠い将来に検証して、改竄されていないことを確認できたとしても、肝心の電子ファイルを人間が開いてみることができないのであれば、あまり意味がないのは明らかです。

例えば、いまから15年前を考えてみます。15年前といえば、1993年です。ワープロ文書について言えば、ワープロ専用機とWindows3.1の時代です。いま、Windows3.1の電子ファイルはどこまで読むことができるでしょうか？ワープロ専用機の電子ファイルにいたってはほとんど読めないでしょう。

こうしてみますと、なにも考えないで電子化して、15年もたてば電子ファイルのほとんどは開いてみることさえできないだろうと予想されます。いまから、15年後、果たしてWindowsのＰＣがどれだけ使われているでしょうか？携帯電話に、あるいは、ブラウザ上のアプリケーションにすべてが統合されてしまっている可能性すらあります。

投票をお願いいたします

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

2008年04月22日

2008年DITA/CMS会議のハイライト

4月7-9日に、カリフォルニアのSanta ClaraでDITAとCMSを中心とする会議がありました。

Content Management Strategies/DITA
North America Conference 2008

アンテナハウスも出展しましたが、そのハイライトがSunのブログに紹介されていました。
Highlights of the 2008 DITA CMS Conference

このブログを書いている、Eric Armstrong氏は、DITAについてもかなり前向きに捉えているようです。

別のトピックの中ですが、「Some folks here are taking a very strong look at DITA. I'm certainly one of them.」（Posted on: Sep 15, 2007） （ここでは、DITAに対して非常に強気の見方の人がいるが、自分も確かにその一人だ。）という発言がありました。こことは、たぶんSunのこと。

○DAISYというWYSIWYGのWikiに関する紹介が一番良かったとのことです。

彼のブログを読んでみますと、どうもDITAオーサリングをWikiで実現することに関心をもっているようです。一般には、DITAは、コンテンツ（トピック）を再利用するために、コンテンツの構造に強い制約をかける為、慣れないとオーサリングをし難いようです。このあたりをどうやって解決するか？ということが課題らしいです。

○第2位は、DITAStormというWebブラウザでDITAを編集するエディタです。

DITAStormはブラウザ・ベースのDITA-XMLエディタ。これは、あまり素人向けではなく、所謂XMLエディタの雰囲気ですので、XMLに慣れている人向けではないかと思います。

○第3位は、MarkLogic Serverです。

MarkLogic社はアンテナハウスのUSのリセラーです。MarkLogic Serverは、以前にお話しましたO'ReillyのSafariU出版システムのサーバとしても使われています。

2008年03月13日　O'Reilly MediaのSafariU

MarkLogic Serverは、ドキュメントのバージョンをオン･デマンドで組み立てて配信するダイナミックなコンテンツ配信の標準という評価をしています。

投票をお願いいたします

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

2008年04月21日

文字をパスで表した場合とグリフで表した場合の違い

アウトライン・フォントの文字をPDFにして画面に表示したり印刷する方法を大別すると、次の３つあります。

１．PDF上の文字コードを使う。表示環境上のアウトライン・フォントで表示する。
２．PDF上のグリフのデータを使う。グリフデータがPDFに埋め込まれている必要がある。
３．PDF上の文字がアウトライン化（パスで表現）されている。

１，２，３の相違はPDFの作成方法によります。１のとき、表示結果は環境依存となります。２、３では表示結果は環境には依存しません。しかし、品質に微妙な差があります。

２、３の違いの具体例がMicrosoftのWord2007製品担当者のブログに紹介されていました。

Word2007で数式編集したとき、それをPDF化すると数式の文字をパスに変換してしまうという問題が発生して、それを調査した話です。
Publishing Workflow – Math content as paths vs glyphs in generated PDF files

PDFの中で、文字をパスで表すかグリフで表すかは、一見大きな違いがありませんが、拡大するとその相違が分かります。文字の輪郭をパスで表した場合、これを拡大するとパス同士の接続が滑らかでなくなってしまっています。このため、文字の輪郭が滑らかでなくなります。（600%拡大の上の画像）

文字をグリフで現すと拡大しても滑らかなままです。グリフの場合は、グリフデータからビットマップへの変換を行うフォント・ラスタライザの計算方法が最適化されているためだろうと思います。

普通は、Word 2007で数式を作って、Save AsでPDF化するとグリフを埋め込みます。しかし、Windows Server 2003で複合文字または極東文字体系（Far East script)が無効になっていると、Word2007は、文字をパスに変換してしまうようです。

これと似たような現象を見たことがあるような気がしますが、思い出せません。

投票をお願いいたします

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

2008年04月20日

DITAの価値は、コンテンツ再利用、シングル・ソース、標準の3点にあり

米国時間の18日（日本時間では19日）、DITA指数という面白いデータが発表されました。
ボストンのDITAユーザズ・グループで過去2年間にDITAのビジネス的な意味に関連して、よく聞かれた質問から、10項目を取り上げて、質問表とし、その回答をもとに指数化したものです。

4月18日時点のDITA指数表は次のようになっています。

項目	平均点
コンテンツ管理システムを使用しているか？	5.1
コンテンツを構造化しているか？	3.5
コンテンツをどの程度再利用しているか？	9.5
シングル・ソース（コンテンツをマルチ形式で出版しているか？）	8.7
コンテンツを翻訳しているか？	6.4
メタデータはマークアップされているか？	4.4
コンテンツはモジュール化されているか？	5.8
条件処理（コンテンツを聴衆毎に変えているか？）	5.0
タスク志向とミニマリズムに従っているか？	4.5
標準化の重要性（共有されたプラクティスを使いたいか？）	9.0

※回答者は38人

これを見ますと、DITAの価値として
○コンテンツ再利用
○シングル・ソース
○標準
の3項目を重視している人が多いということが分かります。

・DITA指数表
・DITA指数とは？
・DITA指数のための回答フォーム

投票をお願いいたします

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

2008年04月19日

PDF/A に電子署名をするとPDF/Aになるだろうか？続き

PDF/A Competance CenterのFAQページには、次のような一文があります。

「PDF/A ファイルは電子署名を含むことができますか？

はい。PDF/Aファイルに電子的に署名することは許可されています。市場ではPDF/Aファイルに電子的に署名するための様々なツール、方策、ソフトウェア・ソリューションが手に入ります。Acrobat ProfessionalもPDF/Aに電子署名するために使うことができます。
出典：FAQページ

ということなので、試してみました。
○PDF/A-1aファイルにAcrobat 8.1で電子署名して、適合度をチェックします。

※PDFファイルは下記の（A）です。

あれ？
「PDF document is not compliant with PDF/A-1a(2005)」 となります。Actobat8.1で署名してもPDF/Aにならないようです。おかしいなあ。

使用したのはAcrobat 8.1Professionalです。

○電子署名するまえのPDF/A適合ファイル：
ファイルをダウンロード
(このファイルの検証結果は、昨日のブログのこちらにあります。）

○上のファイルにAcrobat8.1で電子署名して別名保存したPDFファイル（A）：
ファイルをダウンロード

もう少しチェックしてみないといけないかもしれませんが、PDF/Aを使いこなすのは、慣れるまでいろいろ調べないといけないことが多そうです。

投票をお願いいたします

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

2008年04月18日

PDF/A に電子署名をするとPDF/Aになるだろうか？

PDF/Aについては、既に何回かお話しています通り、日本ではまだあまり関心がないようですが、欧米(特に欧州）ではかなり関心があるようです。

アンテナハウスのXSL Formatterでは、組版した結果をPDF/Aに出力できます。FormatterでPDF/Aに電子署名する機能をサポートする計画があるか？という問い合わせが来ていました。

質問： Are there any plans to support digital signatures on PDF/A? If so, in what version can this be expected? If not, can XSL Formatter be used with signature modules that do support signatures on PDF/A?

PDF/Aファイルに署名すると、PDF/Aになるのではないかと、簡単に考えて、少し試してみました。

まず、FormatterでPDF/Aのファイルを作ります。Acrobat8.1でPDF/Aかどうか検証しますと、問題ありません。

※Formatterで作成した署名前のPDF/A-1aファイルをAcrobat8で検証した画面

これに、PDF電子署名モジュールで不可視署名をつけます。そうして、Acrobat8.1で検証しました。

※PDF/A-1aファイルに不可視署名をつけた結果のPDFをAcrobat8で検証した画面

残念ながら、PDF/Aにはならないようです。

では、可視署名をつけたらどうなるでしょうか？
これを試してみるために、PDF電子署名モジュールで可視署名をつけて、Acrobat8.1で検証しました。

※PDF/A-1aファイルに可視署名をつけた結果のPDFをAcrobat8で検証した画面

こちらも残念ながら、PDF/Aにはならないようです。

ということで、署名する前のPDFがPDF/A準拠になっていても、なにも考えずに署名するとPDF/A準拠ではなくなってしまいます。どうやら、電子署名の付け方もPDF/A対応にする必要がある、ということのようです。

投票をお願いいたします

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

2008年04月17日

PDFによる情報保存の法的な有効性　(2)

もう1ヶ月ほど前、3月26日に、PDFによる情報保存の法的な有効性(1)というお話で「ＣＡＤによって作成された設計図書（電子データ）をＰＤＦ印刷した場合、当該ＰＤＦファイルによる保存は認められません。」ということについて、取り上げました。

繰り返しますが、上のQ&Aでは、(1)CADのデータを直接PDFに印刷した場合は保存を認めないが、(2)紙に印刷したものをスキャナーでPDF化したものであれば認めるということを言っています。

この判断の根拠がはっきりしないので、非常に気持ちが悪いのですが。

もし、この対象アプリケーションとしてCADのみではなく、ワープロや表計算にまで帰納的に当てはまるとしますと、(1)ワープロや表計算から直接PDFに印刷した場合は保存を認めないが、(2)ワープロや表計算から紙に印刷したものを、スキャナーでPDF化したものであれば認めるという結論になります。

さらに、これが、建築関連図書のみではなく、一般に法的に保存が義務付けられている資料にまで、帰納的に当てはまるとしますと、日ごろ、私たちが、企業間でやり取りしているPDFは、ほとんど、法的な証拠書類としては認められない、という悪夢のような結論が導かれます。

まあ、一般には、帰納的推論は、蓋然的にしか正しいとはいえないということらしいですから。

そうなりますと、じゃあ、どういう法律の求める保存義務と、どういう書類ならアプリケーションから直接出力したPDFの保存は認められるか、ということを個別に調べていかなければならない、という大きな問題になります。

私的には、(1)CADのデータを直接PDFに印刷した場合は保存を認めないが、(2)紙に印刷したものをスキャナーでPDF化したものであれば認めるというのは、技術を知らない人の迷信による、あるいは宗教的な判断としか思えないので、こういう迷信に染まった人達を相手にするのは大変だ、と頭を抱えています。

但し、PDFの作り方によっては紙に印刷したものと、PDFの直接印刷したものが同等にならないケースがあります。しかし、それを言い出したら、スキャナーだって、スキャン・ヘッドが傷んだスキャナーだってありうるわけですし、私の使っているとても安価な複合プリンタについているスキャナについているPDF作成ソフト（某社のもの）は、（安いので文句いう気になりませんが）まともにPDFを作っていません。このように、うまく、できないケースをあげつらえばいろんな場合がある訳です。

どうしたら良いでしょうか？

投票をお願いいたします

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

2008年04月16日

標準文書作成支援ツールについてのご紹介

社団法人 情報通信技術委員会 (以下TTC)が試作した、「標準文書作成支援ツール」に関する資料がXSL Formatterのケーススタディとして公開されましたので、ここにご紹介します。

○標準文書作成支援ツールの検討（PDFをダウンロード）

ISOや、ITU-T（国際電気通信連合 電気通信標準化部門）などで作成している標準文書の作成には、XMLを使うのが望ましいのは、多くの専門家が同意するところと思います。

しかし、XMLはオーサリングの方法が大きな課題です。XML専門のエディタは色々ありますが、これは多くの人にはなかなか使いこなせません。一方、WordなどWYSIWYGの編集ソフトは、見栄えをたよりに文書を作成しますので、構造化された文書を作るにはあまり向きません。

ということで、XMLにより構造化された文書を簡単に作成するツールは、ずっと大きな課題なのですが、子今回、TTCはブラウザで一般的に用いられているツリー構造のインターフェイスを用いて、標準文書の構造を表現することで、「標準文書の論理的構造を保ったまま文章作成が可能であること」の条件を満たしたシステムを試作されたとのことです。

■ご案内
【第21回　XSLSchool】【第3回　XSL-FO指南塾】4月24日～4月25日開催
☞ XSLSchoolの案内書・参加申込書
☞ XSL-FO指南塾の案内書・参加申込書

投票をお願いいたします

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

2008年04月15日

日本語ワープロやエディタのビジネスは成立するのだろうか？続き

昨日のブログを、今、読み返してみますと、タイトルと本文の記述内容が随分と食い違っていたようです。

エルゴソフトの沿革を見てみますと、EGwordは本当にすばらしい評価を得ていますね。残念ながら私は足元にも及びません。脱帽するしかありません。

しかし、エルゴソフトは、ワープロ事業を終了してしまったわけです。これは一体なぜなのか？どうしたら良かったのでしょうか？

少し前になりますが、2月7日～14日にかけて「コンピュータ組版の奇跡２」についてお話しましたときも、同じようなことを考えました。

アンテナハウスは、XSL-FOとかPDFとか、ワープロなどと比較的近い分野のビジネスが中心ですので、この問題は、実は、ほとんど毎日のように自問自答している課題なのですが、なかなか、簡単な回答を出すことはできません。

市場ということで言いますと、1990年代後半から、ワープロなどの汎用ソフトウェアの市場は世界がフラットになっています。これにはさまざまな要因がありますが、日本語ワープロという観点では、Unicodeが普及したことがかなり大きな要因ではないでしょうか。

例えば、UnicodeのBIDIという仕様を実装すれば、アラビア語、英語、日本語の混在した組版を、アラビア語についてなにも知らなくてもある程度の品質の組版ができます。現実に、弊社のXSL Formatterは、そうやってアラビア語の組版を実装しており、世界中のユーザがこれを使用しています。

別の例では、今、W3Cのタスクフォースで日本語組版規則の要求事項を英文にまとめているわけですが、こういうドキュメントができることで、世界中の誰でも、ある程度の品質の日本語組版ソフトを作ることができるようになります。

ですので、ワープロや組版というような、印刷文化にかなり密着している分野でも、世界中のほとんど全てのソフトハウスにとって、同じ条件のソフトウエアを作る競争になっており、世界中から競争相手がでてくる可能性があるということです。

その中で、生き残るのは、ほとんどオリンピックに出場して表彰台にあがるくらいに難しいと思います。オリンピックは、参加することに意義があるかもしれません。しかし、ビジネスでは勝ち続けなければ生き残ることができません。そうしますと、私達の戦いは、オリンピックで表彰台にあがるのよりもむしろ難しいといえるかもしれません。

投票をお願いいたします

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

2008年04月14日

日本語ワープロやエディタのビジネスは成立するのだろうか？

エルゴソフトのEgwordの事業終了の話が大きくWebででているのに今頃気がつきました。

エルゴソフトegword、egbridgeパッケージソフト事業終了のお知らせ

そういえば、販売終了のお知らせが来ていたな、と思い出しました。エルゴソフトとはビジネス上の接点が無い訳ではなかったのですが、なにしろ先方のOSが、私がとっくに見捨てたMacということであまり注意しないままに時間が経過してしまったのが残念。個人的には1980年代から1990年初頭位まではMacの大ファンでした。Windows95の登場とともに完全にMacを見捨てて、それ以降ほとんど見向きもしていません。

さて、エルゴソフトの事業終了の話ですが。エルゴソフトのEgwordは、日本のMac界では大変に有名な存在ですし、製品としても優れていて、優秀な技術者もいたようです。それにも関わらず、事業を終了しなければならない、という決断に至ったのはなぜでしょうか？

会社の経営という観点から、やはりチェックしておかねばならない課題と思います。

といっても手元には公開された情報以外はほとんどありません。とりあえず、分かるのは、同社の沿革
http://www.ergo.co.jp/company/history.html
・設立　1984年ですが、これはアンテナハウスと同じ年です。EGWordをこの年発表しています。
・1985年日本語入力ツール「EGBridge」Ver.1.0を発表。
・1986年には、日経の年間優秀製品賞受賞を受賞しています。
・1987年EGTalk、EGBookを発売
・1988年EGWorksを発売　CANON Navi用です。
・1989年PC9801用ワープロソフトEGLightを発売
・1990年にEGLightを、J3100、FMR、PS/55用に発売
・1991年にJ3100用EG Calcを発売、DOS/V用EGLightを発売
・1992年３Ｄグラフィックソフト「Swivel 3D Professional」「Swivel Man」「Model Shop II」、アニメーション３Ｄソフト「LIFE FORMS」を発売
・1993年定型文書の作成・管理のための「EGForm」を発売。この年光栄が株式を100%取得。
・1994年に本社、東京営業所、東京開発センターを東京都渋谷区に統合。この年は新しいEGwordのバージョンを出していますが、新製品はありません。また、Windows用のEGBridgeを発売しました。
※株主の変更、事業所統合、新製品なし、といった状況から、恐らく、1993年までの事業の見直しが行われたのものと推測されます。
・1995年もEGWord、EGtalk、EGBridgeといった初期からの製品のバージョンアップのみを行っています。Windows用のEGWordを出しています。
・1996年からまた、EGWord、EGBridge以外の新しい製品を出し始めました。2001年位まで新製品を色々と出しています。
・2002年頃からまたEGWord、EGBridgeに回帰しています。
・2008年1月にパッケージソフト事業を終了するまで、新しい製品を出さずに、ほとんどEGWord・EGbridgeに世界に閉じこもっています。

こうして、エルゴソフトの沿革をざっとチェックしますと、(1)最初にワープロソフト、日本語入力ソフトで成功し、(2)表計算、３Dグラフィック等の製品を出して事業拡大を図る、(3)一端縮小し初期のワープロと日本語入力の原点に返り、(4)再度、新しい製品にチャレンジ、(5)また日本語ワープロ・日本語入力ソフトに回帰、という繰り返しを行っているように見えます。

中小企業が成長・発展するには：
・事業の多角化は絶対条件である。
・従って、経営者は多角化に挑戦しなければならない。
・しかし、多角化に成功するのは非常に難しい。

ということが、エルゴソフトの沿革にまるで教科書の通りに描かれていると言ったら言いすぎでしょうか？

投票をお願いいたします

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

2008年04月13日

XAML, XPS, WPF, XPSviewer, Silverlight ? その３

Codezineに掲載されたSilverlightの文書形式について読んで見ました。

Silverlight入門（1）－XAMLの文法
参考：MSDN のSilverlightリファレンス

・HTML上のOBJECT要素によってSilverlightをブラウザに表示するか、Silverlight SDK付属のSilverlight.jsを使い、createObject関数を呼び出す。
・SilverlightのコンテンツはXAMLで作成する。その記述方法は、XMLの要素として、XAMLのオブジェクト名、XMLの属性としてオブジェクトのプロパティとその値を指定する。属性を使う代わりに、属性と同等のプロパティ要素を使う方法もある。
・例えば、文字列はTextBlockオブジェクトを使い、線を引くならLineオブジェクトを使うなど。オブジェクトの入れ物としてのCanvasオプジェクトも使える。

続き： Silverlight入門（2）－図形やテキストを扱うオブジェクト（Codezineに登録しないと閲覧できないと思います。）

Silverlightで使えるXAMLのオブジェクトの種類は、まだ非常に機能的に少ない。また、この解説を読んだ範囲では、Silverligh用XAMLはXMLによる仕様書としてはそれだけで独立ではなく、Silverlightプログラム依存になっていると思います。つまり、オブジェクトとプロパティについて完全な仕様として記述されていないので、レンダリングがそのデータを解釈する実装に依存するということで、Microsoft OfficeのOOXMLも同じような性格を持っています。

XAML全体が、実行プログラム依存かと言いますと、そうでもなく、マイクロソフトのXAML の概要を見ますと、XAMLのドキュメントには固定ドキュメントとフロー・ドキュメントの2種類があると説明されています。

固定ドキュメントは、WYSIWYGアプリケーション用とのことです。このあたりは仕様を詳細にチェックしないとはっきりは言えませんが、レンダリングされる結果が常に同一になるように仕様上保証されていれば、アプリケーション独立になることがかなり期待できます。

XPSはXAMLの固定ドキュメントをひとつ以上とその表示に必要なリソースをパックしたものとのこと。

つまり、XPSはXAMLのサブセット＋資源のパックということです。

SilverlightでXPSをどこまで表示できるかという問の回答は、Silverlightがサポートしているオブジェクトの種類と、あとは、フォントなどのリソースをサーバからクライアントにどこまで送信できるか、という問題もありそうです。サーバ上にXPSと共に置いたフォント・リソースを解体してクライアントに送信したら、ライセンス違反の危険があるかもしれません。

投票をお願いいたします

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

2008年04月12日

XAML, XPS, WPF, XPSviewer, Silverlight ? その２

XAMLをつかった、「New York Times」のリーダは、2007年から有償配信サービスをしているようですが、日本では、イーストがXAMLを使った記事配信に熱心に取り組んでいるようです。

イーストのサイトにXamler01.exe　青空文庫ビューアが公開されていました。早速、ダウンロードしてみました。
○羅生門をXamler01.exeで表示したところ。

○XAMLのビューアは、ウインドウを狭くすると1段に、広げると段数が3段になります。

ブラウザと比べると、格段に読みやすいように思います。また、PDFと違って、固定のサイズもつ紙のページを画面に表示するのではない、と言う点で、確かに次世代の電子ファイルビューアの片鱗があります。

しかし、日本語組版はお世辞にも綺麗とは言えませんね。

○拡大したところ

Xamler01では、テキスト中心の表示になっています。少し複雑なHTMLページはうまく表示できません。

Xamlerには、Silverlight版とかMobile版とかいろいろあるようです。

投票をお願いいたします

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

2008年04月11日

DITA アーキテクチャ仕様書を翻訳しました

1月13日に「今年は、DITAを積極的にやろうかと思案中です。」とお話しました。DITAを勉強するために、OASISのDITAアーキテクチャ仕様書を翻訳していましたが、ほぼ出来上がりました。

こちらでご覧いただくことができます。
OASIS DITA Version 1.1　アーキテクチャ仕様
OASIS標準
2007年8月1日

この仕様書は、『DITAの入門を目的とはしていないし、ユーザ・ガイドでもない。この仕様が意図する聴衆は、DITA標準を実装する人であり、ツール開発者や専門化する者を含む。』と本文にもありますとおり、ユーザ向けのものではなく、かなり難しいと思います。

ちょっと気になっていますのは、Specializationという言葉の日本語訳です。私の訳では「専門化」と言う言葉を使いましたが、IBMのWebでは「特殊化」という訳を充てています。

DITAは、トピック型という一塊の情報単位が基本です。トピックの元祖は一般トピックですが、一般トピックをもとにして、コンセプト、タスク、参照、用語集（V1.1から）という専門化した文書型トピック型を作り出します。

(訂正）トピック型は文書型ではありませんでした。

また、トピックを組み合わせて文書にするマップがあります。マップには、一般のマップの他、本を作るためのブックマップ（V1.1から）という用途を絞った専門的なマップがあります。ブックマップは、一般のマップをSpecializeしたものなのですが、こういうものを特殊化といって良いのかどうか、専門化という方が妥当なのではないか、と。専門化なのか特殊化なのか、どちらでも良いような気もします。

なお、DITAを実際に使用したり普及させるには、もう少しやさしいDITAの入門書が必要ではないかと思います。

投票をお願いいたします

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

2008年04月10日

XAML, XPS, WPF, XPSviewer, Silverlight ?

Windows Vistaに伴って、いろいろと新しいMSのアーキテクチャが導入されました。もう、先刻ご承知の方が多いと思いますが。

○XAML：Extensible Application Markup Language
　　XMLベースのプレゼンテーション言語

○WPF：XAMLローダを備えておりXAMLで記述されたデータを実行するらしい。

○XPS：XML Paper Specificationは、XAMLのサブセットで電子ファイルを記述する言語。

○XPSは、XPSViewerで表示することができる。

○Silverlight：以前は、WPF/E（Windows Presentation Foundation/Everywhere）と呼ばれていたらしい。WPFのマルチ・プラットフォーム版。

ということは、SilverlightでもXPSを表示できそうな気がします。調べてみますと、Delayさんという人が、SilverlightでXPSを表示するプロトタイプを作ったようです。

Lighting up the XML Paper Specification [Proof-of-concept XPS reader for Silverlight!]

こんな感じで動きます。

○FireFox＋Silverlight2

しかし、まだ、Silverlight自体ではXPS表示をサポートしていない？

Silverlight 2.0 + XPS

を見ますと、この人も私と同じことを考えたようで、SilverlightでXPSを表示できないかと、Googleで検索しても、Delayさんのプロトタイプしか出てこないぞ、と言ってます。

そうしてみますと、XPSをSilverlightで表示するのは、なにか作らないとできないということなんでしょうか。

Windows環境であれば、XPSViewerがあれば、XPSを表示できますので別にSilverlightを必要とはしないと思います。Silverlightが、真にマルチプラット・フォームで動くのなら、XPSをSilverlightで表示するのにも意味がありそうに思います。

投票をお願いいたします

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

2008年04月09日

「書けまっせ!!フォーム」を改訂

昨日、ジャングル版の「書ける！PDF2」ファミリーでは、アンテナハウスの同等製品に比べて、フォーム300種類の同梱が追加ｓれているとお伝えしました。

アンテナハウス製品では、フォームをパッケージに同梱する代わりに、「書けまっせ!!PDF」で直ぐに使えるフォーム集として、Webで「書けまっせ!!フォーム」を提供しています。

■「書けまっせ!!フォーム」のページ

ここでは、PDFのフォームに加えて、「書けまっせ!!PDF3」用のプロジェクトファイル（WPP形式）も用意しています。

WPP形式には、入力用のテキストボックスなどが定義済みですので、「書けまっせ!!PDF3」でWPPファイルを開きますと、新たに、入力領域を定義しなくてもPDFに文字を書くことができます。

ぜひ、お試しください。

フォームの種類は、まだ50種類程度ですが、これから少しずつでも増やしていきたいと考えていますので、「こんな様式を増やして欲しい。」というようなご意見・ご要望をお寄せいただければ幸いです。

投票をお願いいたします

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

2008年04月08日

株式会社ジャングルより、「変換！PDF2」、「書ける！PDF2」など発売

4月17日、株式会社ジャングルより、「変換！PDF2」、「書ける！PDF2」などの製品が発売になります。これらの製品は、それぞれ弊社の、「リッチテキストPDF4」、「書けまっせ!!PDF3」などと同等機能をもつ製品となります。

○株式会社ジャングルのニュースリリースのページ
(1)変換！PDF2関連
(2)書ける！PDF2関連
(3)セット商品関連

○ジャングル製品と弊社製品との対応関係は次のようになります。
・変換！PDF2
　　　リッチテキストPDF4Lite　相当
　　　但し、弊社では、本製品はダウンロード販売のみで、パッケージ販売は行っていません。

・変換！PDF2PRO
　　　リッチテキストPDF4スタンダード　相当

・変換！PDF2PRO＋OCR機能
　　　リッチテキストPDF4コンプリート　相当
　　　リッチテキストPDF4のWebページ

・書ける！PDF2
　　　書けまっせ!!PDF3Standard　相当に、ジャングル製品は入力フォームが追加されています。

・書ける！PDF2PRO
　　　書けまっせ!!PDF3Professional　相当に、ジャングル製品は入力フォームが追加されています。
　　　書けまっせ!!PDF3のWebページ

・変換！+書ける！PDF2Standard
　　　弊社では同等製品を販売していません。

・変換！+書ける！PDF2Premium
　　　アンテナハウスPDFスイート　相当に、ジャングル製品は入力フォームが追加されています。

製品の機能につきましては、上記の対応の通りで相違はありません。但し、顧客登録・サポートなどの面で相違があります。

最近、お店で、アンテナハウス製品と間違えて、ジャングル製品を買ってしまったが、どうしたら良いか？というお問い合わせをいただくことがあります。この場合、弊社の顧客サービス（sales@antenna.co.jp）までお問い合わせください。

なにとぞ、よろしくお願いします。

投票をお願いいたします

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

2008年04月07日

GoogleDocsの進歩は如何？

GoogleDocsの進歩について、昨年11月からの変化をチェックしてみました。

１．ワープロ機能
ワープロ機能は編集メニューがかなり変更になっています。
■最新の画面

※FireFoxでは表示されますが、IE7では一部の文字が表示されません。（ブラウザ間の互換性の問題）

この画面を前回と比べますと、編集の関係のメニューが変わっています。
前回：2007年11月16日　Google Docs は進歩しているか？ — ワープロ文書の場合

編集画面はともかく、PDFの出力に以前はOpenOffice.orgを使っていましたが、最新の時点では、Princeを使っています。PrinceはCSSを使う組版ソフトです。上のGoogleワープロ文書をPDF化したものをここにアップしました。
○PDFファイルをダウンロード
・日本語部分に中国語のフォントが指定されてしまっています。IE7上の編集メニューには、日本語フォント（MS明朝、MSゴシック）を選択できますが、フォントをMSPゴシックに指定しても、サーバ上でPDFを作るとき中国語フォントを指定してPDFを作ってしまっているようです。日本語対応はあまり良くありません。

・PDF作成をOpenOffice.orgからPrinceに変更したのは何故なのでしょうか？ちょっと疑問。

２．表計算機能
表計算機能は、メニューが変わっていないようです。
■最新の画面

PDFを出力してみましたが、iTextを使っている点は、前回調べた時と同じです。

３．プレゼンテーション機能
プレゼンテーション機能は、だいぶ充実した印象を受けます。
■最新の画面

環境設定で日本語にしますと、日本語のフォントを選択できます。

PDF形式で保存するメニューがつきました。

IEの編集画面では、「標準」のフォントが指定されていますが、出力したPDFには、MSP明朝・MSPゴシックが埋め込まれます。そうしてみますと、Windowsサーバを使っているということなんでしょうか？
○ファイルをダウンロード

全体的にみて、特に日本語という点で問題が多いように感じます。

投票をお願いいたします

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

2008年04月06日

Webは修理が必要だ — Javascriptのセキュリティ問題

前回に続き、Ajax World East2008におけるDouglas Crockford氏の「Webを修理できるか」のスライドの続きをご紹介します。

※前回はこちらです。
2008年04月03日 Webは修理が必要だ — Turducken問題

１８．Webを修理するための三又戦略 — Javascriptの安全な部分集合（本要約19～22項）、ブラウザの小さな改善（本要約23項）、ブラウザの強力な改善(本要約24～25項)（スライド３３）
１９．Javascriptを小さくして、セキュアでない部分を削除する（スライド３４～３７）
　JSLint　　http://JSLint.com/は、HTMLとJavascriptの安全な部分集合を定義している。
　ADSafeでは、グローバル変数・関数は定義されない。 ADSAFE オブジェクト以外にグローバル変数・関数がアクセスされることはない、など。Google's Caja/CajitaもJavascriptの安全な部分集合。
２０．Ecmascriptとその実装には未発見の危険があるかもしれず、ブラウザの実装が変化して新しい脆弱性を導入しているかもれない。DOMラッパは完璧でなければならない。（スライド３８）
２１．クロスサイトデータアクセスは、他のサイトからデータを取得してマッシュアップするのに有用だ。しかし、スクリプトタグを巧妙に改変されると非常に危険。（スライド４０～４２）
２２．安全なデータ交換のためのJSONRequestを提案した。ブラウザに実装して欲しい。（スライド４３）
　JSONRequest

２３．HTMLはモジュール化を提供していない。Google Gear, Adobe AIRは、通信のための入れ物を提供するが、重いしXSS攻撃からは安全でない。<iframe> は解決策ではない。（スライド４４～４７）
２４．JavascriptとDOMを置き換える必要がある。ADsafeからスタートして注意深く機能を強化する。（スライド４９～６３）
２５．Javascriptをより安全な言語で置き換え、HTMLとDOMを安全なアプリケーション配布システムで置き換えねばならない。しかし、現在のHTML5の提案はそうなっていない。（スライド６７）
２６．Webはかつては革新の駆動車だったが、今は革新の障害だ。Webの時間は昔は”速い”を意味した。2000年には全てのブラウザでAjaxが可能になった。2005年にJesse James Garrett がAjaxを発見した。なぜ、5年も掛かったのだろうか？（スライド６９～７３）
２７．ブラウザの新しいバージョンが普及するのに長い時間が掛かるためだ。（スライド７４～７５）
２８．人類は10年で人間を月に送ったが、10年でWebを修理できるだろうか？（スライド７６）
２９．Webを置き換えようとする３つの競争 —　Silverlight、AIR、JavaFXがある。これはWebの終わりを意味する。（スライド７７～７８）
３０．私は、以前は、ブラウザは最も不適切なプログラム環境と言っていたものだが、それはモバイルを発見する前のこと。（スライド７９）
３１．モバイルへ向かう。もし、PCベースのブラウザがモバイルのペースに追いつけないなら、モバイルがPCを廃れたものとしてしまうだろう。（スライド８０～８２）
３２．さしあたり、ブラウザを信用しないこと。コーディング衛生学が必須だ。品質の高いコードを書け。JSLintでチェックせよ。（スライド８３～８６）
３３．Webの標準化は敗れている。W3C、ECMA、ブラウザ・ベンダに圧力を掛けるべき。彼らは、君達を危険にさらしている。（スライド８８）

プレゼンは、以上です。

モバイルも良いですが、PDFを表示するには、14インチディスプレイ付きのモバイルが必要なのが困りますね。

投票をお願いいたします

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

2008年04月05日

PDF Driver API の制限事項変更につきまして

Antenna House PDF Tool V2.6MR3（Windows 版）を 2008/2/25 に公開しました。

この V2.6MR3 の改訂履歴に「PDF Driver API と PDF Driver の情報の受け渡し方法を変更しました。」とありますが、この改訂によってこれまで制限事項としていた、タスクスケジューラや Windows サービスプログラムから Antenna House PDF Driver を利用した PDF ファイルの生成が可能になりました。

PDF Driver API でこれらの利用方法を検討されていた方に是非お試しいただきたく存じます。

Antenna House PDF Tool の評価版のお申し込みはこちらから

投票をお願いいたします

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

2008年04月04日

OOXMLのISO進展、WebCGM2.1のパブリック・レビュー他

ニュースとしては遅くなりましたが、Microsoft のOffice OpenXML（OOXML）ファイル形式が、投票でISO仕様（ISO・IEC DIS 29500）として認められるために必要な賛成数を得たという発表がありました。

ISO/IEC DIS 29500 receives necessary votes for approval as an International Standard

これはなかなか大きな一歩です。アンテナハウスは1990年代前半からMicrosoft Wordと他のワープロ間の変換ソフトを開発してきました。Wordのコンバータはもう15年位開発しているのではないかと思います。最近は、サーバベース・コンバータ（SBC）というOffice互換の組版エンジンを作っています。今までは、ずっとバイナリ形式のファイルを解析して開発してきました。今はファイル形式がXMLとして公開されてますので、既に、解析作業は不要になっています。しかし、ファイル形式がマイクロソフト独自のものである限り、いつ、本質的なところで仕様の変更が行われるか予測できません。

しかし、ISOの標準仕様となりますと、仕様としての長期安定性が保証されることになりますので、開発作業は非常にやり易くなるでしょう。その分、互換性のアップなどに力を注いでいくことができるようになります。ソフトハウスの力が、解析力ではなく、プログラム作成力に於いて問われるようになるとも言えます。

一方で、Microsoft以外のサードパーティが、OfficeのXML形式で文書を生成する機会が増えてきます。それらの文書を、SBCで組版するという機会も増えてくると思います。

要するに、OOXMLファイル形式がMicrosoft Officeから独立して、電子ファイルとしてやり取りされる、ということになり新しい市場が開けるのだろうと期待しています。

やることがいろいろ増えそうで楽しみです。

なお、多くのお客様から催促を頂いています、OOXML対応のSBC 2.0は、近日中に発売を目指して鋭意開発中です。恐れ入りますが、しばらくお待ちください。

WebCGM2.1草案
また、OASISは、4月2日より、WebCGM 2.1の委員会草案を公開しました。6月までパブリック・レビュー期間となっています。

詳細はこちらをご覧ください。
CGM情報源

投票をお願いいたします

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

2008年04月03日

Webは修理が必要だ — Turducken問題

New Yorkで3月に開催されたAjax World East2008で、YahooのDouglas Crockford氏が、「Webを修理できるか」という題で講演しています。

○講演を紹介したブログ：Crockford Speaks on “Fixing the Web” and Appears on Channel 9
○MSDNのチャンネル9でのインタビュー：http://channel9.msdn.com/Showpost.aspx?postid=391047
○講演内容のPowerPointスライド：http://yuiblog.com/assets/crockford/crockford-fix.zip

Douglas Crockford氏はJavascript分野で大変有名な人らしいですが、講演内容を見ますと相当にショッキングな内容です。

スライドをピックアップして紹介します。
１．Webブラウザは、Ajaxのために設計されたものではない。賢い人たちが動かし方を見つけだしたもの。（スライド４）
２．我々は既にブラウザのポテンシャルを探索し終えた。（スライド５）
３．Ajaxは、不必要に複雑であり、実装も変化しやすいが、それは最大の問題ではない。(スライド６)
４．セキュリティが最大の問題。（スライド７）
５．ブラウザは、安全なプログラミング環境ではない。生来、安全ではないのだ。（スライド８）

６．攻撃者が貴方のWebページに、なにかのスクリプトを入れたら何ができるか？（スライド９～１５）
　・世界中のサーバから、任意の追加スクリプトを要求できる。
　・貴方のサーバのリクエストを作ることができる。
　・文書を読むことができる。
　・ディスプレイの制御を奪って、ユーザに情報を要求できる。
　・その情報を世界中の任意のサーバに送ることができる。
ブラウザは、上のどれも防止することができない。
７．攻撃が成功したら恐ろしいことになる。（スライド１７）
８．Turducken問題：（七面鳥の中に、鶏肉巻き、その中にアヒル巻きをつめた料理）。ブラウザでは、様々な言語がネストする。（スライド１８）
９．ある文脈で安全なテキストは他の文脈では脅威になる。（スライド１９）
１０．単純なXSS攻撃の例（スライド２０～２１）
１１．これは、Web2.0の問題ではなく、1995年のNetscape2から存在する。（スライド２１）
１２．脆弱性は、標準の要求による（スライド２２）
１３．Javascript、DOM、クッキーが問題（スライド２３）
１４．Javascriptのグローバル・オブジェクトはXSS攻撃の根源（スライド２４）
１５．Javascriptは、安全な言語ではない（スライド２５）
１６．DOMの全てのノードは、他のノードやネットワークにつながる（スライド２６）
１７．二つまたはそれ以上のソースからきたスクリプトがあれば、それはセキュアではない。（スライド２９～３２）
　・マッシュアップはセキュアではない。
　・広告はセキュアではない。
---続く---

日経コンピュータ　4月1日号には、「組織犯罪がWebを襲う－3月だけで2万ページにウイルス埋め込み」という記事が出ています。

JavascriptでDOMを操作するAjaxが全盛になりつつあります。しかし、このようなセキュリティの脅威があるとすると恐ろしい時代になりつつあるようです。

投票をお願いいたします

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

2008年04月02日

OpenOffice.orgでIPAフォント設定時の縦書き用グリフ問題（問題発見！）

さて、「IPAフォントに不具合がある」ということなので、色々と調べてみたのですが、最後に漸く、それらしき問題を発見しました。

昨日、サーバベース・コンバータでフォントを埋め込んで作成したPDFを、今度は、「PDFViewer SDK」を使って表示してみます。

PDF Viewer SDKは、PDF表示機能をアプリケーションに組み込むための開発キットなのですが、Windows画面に文字を表示する方法を切り替えることができます。

PDFにフォントを埋め込んだ場合、各文字のグリフがPDFの中に埋め込まれます。PDFには同時に文字コードへの対応表も定義されます。

（1）PDFにフォントが埋め込まれている場合、通常は、そのグリフを使って表示します。
（2）しかし、グリフを使わずに、文字コードをWindowsに渡して文字を表示させることもできます。この場合、Windowsが、フォントファイルから縦書きか横書きかで適切なグリフを探して表示するはずです。

また、WindowsGDIには、GDIとGDIPlusと2種類があります。GDIPlusの方が新しく、高度な表示機能があります。PDF Viewer SDKでは、GDIを使う表示とGDIPlusを使う表示を切り替えることができます。

この組み合わせは4通りになりますが、4通りそれぞれの表示を試して見ました。

１．埋め込みフォントのグリフを使ってGDIPlusで表示した画面

２．埋め込みフォントのグリフを使ってGDIで表示した画面

３．文字コードを使ってGDIPlusで表示した画面

４．文字コードを使ってGDIで表示した画面

びっくり！

文字コードを使ってGDIPlusで表示したときだけ、縦書きの句読点のグリフが横書き用グリフになってしまっています。

どうやら、WindowsはGDIPlusの時だけ、「IPA明朝」の縦書き用のグリフを正しく取り出せないようです。推測しますに、Microsoft WordやOpenOffice.orgで、「IPA明朝」を指定した縦書き文書の句読点が正しく表示できたのは、文字コードでGDIを使って表示していたからかもしれません。

結局、「IPA明朝」にはどうも問題があるらしいことまでは分かりました。しかし、実際のところ、これがIPAフォントの不具合なのか、それともGDIPlusの不具合なのかは、これだけでは必ずしも断言できないと思います。最後は、「IPAフォント」の中を覗いて見るしかない？

投票をお願いいたします

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

2008年04月01日

OpenOffice.orgでIPAフォント設定時の縦書き用グリフ問題（謎が深まる）

昨日のOpenOffice.orgで、IPAフォントを設定した時の縦書き用グリフ問題について、「IPAフォントの不具合」だという話。どうも納得できないので、もう少し調べてみます。

今度は、Microsoft Wordで文書を作って、いろいろ調べてみました。
○Word文書：ファイルをダウンロード
・句読点に注目しますと、WordではIPAフォント指定の縦書き句読点が正しく表示できていることが分かります。

（Word2003英語版の印刷プレビュー画面）

○次にWordからAdobe PDF（ドライバ）でPDFを出力します。（フォント埋め込み）
ファイルをダウンロード
・句読点に注目しますと、やはりIPAフォントの縦書き句読点が正しく表示できていることが分かります。

（出力されたPDFをAdobe Reader　8.1で表示）

ここまで見る限りでは、特に、IPAフォントに問題があるようには見えません。

そこで、今度は、このWord文書からアンテナハウスのサーバベース・コンバータ（SBC）を使ってPDFを作成してみました。SBCは、Wordのdocバイナリ文書を直接解読して、WindowsのGDIを使わず、直接PDFを作成しています。LinuxやSolarisでも動くように、フォント・ファイルもWindowsの機能を使わずに独自に読んでいます。Wordなどとは別の方法でフォントにアクセスし、別の方法でPDFを作っています。

まず、フォントを埋め込まないPDFを作ります。
○SBCによるフォントを埋め込まない指定のPDF：ファイルをダウンロード
・これをAdobe Readerで表示しますと、縦書きの文字も正しく表示できます。

（SBCで作成したPDFをAdobe Readerで表示）
・問題ありませんね。

次にSBCでフォントを埋め込んだPDFを作ってみます。
○SBCによるフォントを埋め込む指定のPDF：ファイルをダウンロード

（SBCで作成したPDFをAdobe Readerで表示）
・これもAdobe Readerで表示しても特に問題はありません。

ということで、ここまでの調査では、
（1）Word2003でも縦書き句読点を正しく表示できる。
（2）WordからAdobe PDFでPDFを作成しても正しく表示できる。
（3）SBCで、Wordとは別の仕組みで、フォントにアクセスしてPDFを作っても問題ない。

ということになっています。本当にIPAフォントに不具合があるのでしょうか？ますます謎は深まりますね。

投票をお願いいたします

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