なるひこの Linux Printing お勉強日記 RSSフィード Twitter

ご注意!

ここはあくまでも私個人のブログであり、いかなる団体や組織の立場から離れた、私個人の知見なり学んだことなり勝手な思い(妄想ともいう)を書く場所であります。それを踏まえてお楽しみいただければ幸いです。

クリエイティブ・コモンズ・ライセンス
特に断りがない場合は、本ブログの筆者によるコンテンツはすべて クリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下に提供されています。

2008-11-13

関西オープンフォーラム 2008 2日目

前のエントリで書き損ねたのだけど、なんでKOFにある思いがあったかって言うと、「とにかく関西のコミュニティは熱い!」って話を聞いてたからのなのです。

関東のコミュニティは関西に比べると洗練されてるけど、熱さと言う意味では関西の方が……って話を聞いてたんで、じゃあ一度見に行ってみるか、ってことでね。

ということで前日の懇親会だけど、熱かったなぁ。

案外人見知りが激しいオイラはあんまりたくさんの人と話せなかったけど、この熱さはやみつきになりそうだね。


で、朝起きたら10時45分……なんじゃそりゃ。

目覚まし鳴らなかったんだよ。ちぇ。

しかし、幸いなことに午前中で聞きたいセッションはまるきり趣味の「 日本語プログラミング言語「なでしこ」で定型作業を自動化しよう!」 だけだったのでセーフ。

しかしなでしこセミナーOSC Tokyo/Fall 2008 でも体調不良で聞けなかったんだよね。呪われてるのか?


ということで昼まではブースを冷やかしてすごす。


なでしこのブースに行ってパンフをもらう。

前述のとおりセミナーを聞き逃した話をしたら「じゃあ本買ってくださいよ!」って言われちゃった。いや、面白そうなのはたまらなく面白そうなんだけど、ビジネスとは直結しないからなぁ。本買うまでのことは……(^^;)。


あとニコ動技術部の MZ-700 でアイマスムービーってのは激しくおかしかった。手ぶれしまくりだけどご容赦。

f:id:naruoga:20081108123001j:image


そのあとうぶんつなひとやでびあんなひとと話していたら、おっと、1時だ。


Ruby Lightning Talk

関西 Ruby の会の面々による「Ruby Lightning Talk」にちょい遅刻して参加。

途中から行ったので最初のいくつかは聞き逃したっぽい。

内容は:

Wii リモコンを Ruby でコントロール by ema さん
  • もちろん Pure Ruby ではかけないから C の拡張ライブラリで。
  • 何故に Ruby? ガワが Ruby の方がいろいろラクじゃん?
  • 注意点:加速度センサーは作用反作用の法則があるので振っても元に戻ってしまう。プログラミング上注意。

いやー、アホなことに使ってますねえ (褒めてます)。

男前 Ruby by よしだあつしさん
  • Ruby がいかに男前か訴え、女性ユーザに訴求する(そうか?)
  • 男前ポイント1. 素敵なメソッド名 Array#include? "?" 付きのあたりが超男前。
  • 男前ポイント2. 素敵なライブラリ名 例)"un" ruby -run touch hogehoge → 「走れ!」って感じで男らしい!
  • 男前ポイント3. Ruby は毅然としている 例) "1"+2 は例外
  • 男前ポイント4. Ruby は包容力がある 例)case 文は文字列なら比較だけど、正規表現なら match。

いやいや、強引な論法に笑わせていただきました。

会社の女の子に ruby 宣伝するときに使おう。

console on Rails by Nobuyuki Imai
  • irb の拡張でブロックとか複数文とか一気にヒストリで戻れるようにしたのがある
  • これを使って Rails の新機能を紹介

すんません、Rails よくわかんないんでピンとこなかったです。でも irb の拡張は便利そうだったなー。

Introducution of Lazy List (あ、Speaker の名前忘れちゃった)
  • Haskel 風の遅延リストを Ruby で実現したライブラリがあるのでこれでいろいろ遊ぼうって話
  • gemインストール可能
  • map チェーンとかバシバシしてもパフォーマンス劣化しないのがうれしい

これは面白そうだ。あとで試してみたいな。

地方 SIer での Ruby 事情 by 吉川正晃@四国富士通さん
  • 主に情報系 Web アプリを手がける
  • 基幹系には厳しいが (Java)、情報系なら Ruby はお手頃
  • CRM とかも使うけど、大抵は cgi.rb ゴリゴリ
  • 最近ちょっと Rails とか使い始めた
  • 何で Ruby? →日本発なのでとっつきがよかった/erbが便利/tDiary のソースが勉強になった
  • 課題:昔のバージョンで構築した環境をどう保守していくか?

あんまり縁がない世界なので案外面白かった。

基本的には LL といいつつ時間に余裕があるので「あ、じゃあもうちょっと喋っていい?」とか温めの進行だったけど、それもまたよしか。


Google Chrome 完全技術解説

次は Google の及川さんによる「Google Chrome 完全技術解説」。さすがにほぼ満席の人気セミナーでした。

Why they're developing new Web browser?

「なぜ Googleブラウザ競争に参入したか」ということなのだけど、これは、

今ある最高の要素を取り入れたブラウザをゼロから開発できるとしたら?

というのが出発点だとのこと。

NCSA で Mosaic が開発された頃、誰も Web 2.0 なんてことは予想していなかった。

しかし今や、Google 社内では誰も Office アプリグループウェアなど使っていない。すべて Web アプリ。そのインフラJavaScript。さらに Dynamic HTMLFlash なんてのもある。

ということで、今の技術で Web ブラウザを作るって選択をしたと。

キーワードは二つあって、

  • Rediscover The Web (by Mozilla Project), but
  • Do Not Reinvent The Wheel

まあ当たり前のことではあるんだけど、最新の技術で今の Web 世界にふさわしいブラウザ、といっても、フルスクラッチで書くのは馬鹿げている。

だから使えるものは使おうと。

Google Chrome の機能面

Google Chrome についてはもう実際に使ってる人も Web 上にいっぱい記事もあるんで機能面についてはさらっと書くと、

  •  アドレスバー一個で全部をまかなう
    • これまでの Web ブラウザURI を入力する場所と検索バーとツールバーの入力画面と……とたくさんあった
    • どれ使っていいかわからんがな!
    • omni box: bookmark + 検索エンジン + 履歴 + ……
    • ソースがどれであるかをユーザに意識させない
    • ナビゲーションクエリ: ユーザは行きたいサイトを知っているが URL を知らない→こういう場合に適切なサイトを推奨してくれる機能
  • リッチなスタートページ
    • 「よく行くページ」をプレビュー付きで表示
    • あとはきっとみんな知ってるよね? ということで省略 ;-)
Open プロジェクト
技術解説

主に Chromium からの引用なので、詳しくはそちらを参照のこと。

f:id:naruoga:20081120082644p:image

Chrome の内部構成は上図の通り (Chromium から似たような図を発見できなかったので手書き。Creative Commons 的にフリーです)。

WebKit はご存じ Konqueror のがベースで AppleSafari を作るのに大幅に手を入れたやつ。

そのレンダリングエンジンだけもらって、グラフィックエンジンは自前の SGL というエンジンに入れ替えたと。SGL は Android などでも採用されている軽量高速なエンジンで、もちろんオープンソース

Javascript の高速化はもう最近の潮流とも言えますが (イコール、Web アプリの高速化だものね)、ここもフルスクラッチV8 というエンジンを積んできたと。

ただし、Chromium をソースコードからビルドするときは、コンパイルオプションV8 ではなくて WebKitJavascript エンジンを使うこともできるとか。これは主にデバッグ用途を意図しているようです。

もちろん V8オープンソースであります。

そして最近のマルチコア、マルチプロセスの流れに従った内部構造。

http://dev.chromium.org/developers/design-documents/multi-process-architecture/arch.png

(see Multi-process Architecture on Chromium Developer Document)

メインプロセスには I/O スレッドブラウザ (各タブを統括するもの) がいて、タブが一個

起きるごとにタブ内のレンダリングをするプロセスが起きると。当然プロセスなので IPC が走るんだけど、Windows の場合は COM なんだそうで。

そいでレンダリングプロセスは特権なしで動作するので、Javascript エンジンとかバグっててもプロセス一個殺せばすむ。他のプロセスには影響を与えない。

プロセスが別々だからマルチコアの恩恵が最大限に生かされる。と、まあいいことづくめ。

もちろんメモリ食うって欠点はあるけどね。

ちなみにプラグインはどうなってるかっていうと、

http://dev.chromium.org/developers/design-documents/plugin-architecture/pluginsoutofprocess.png

(see Plugin Architecture on Chromium Developer Document)

こんな感じで、プロセスを完全に分けてるんだそうな。


プラグインというのはいろいろ地雷なので、プロセス分けて IPC で遮断するというのはまあすぐ思いつくとはいえ、パフォーマンスとの兼ね合いもあるからめんどうなんだろうね。


Chromium.org に加入しよう

Chromium というのは Google Chrome の開発プロジェクトというだけではなく、Chrome からライセンシーの非オープンなソースを覗いた別のブラウザでもあるらしいです。

もちろんエンジンや内部構造は Chrome そのものなので、Chromium の開発 ~= Chrome の開発なわけだけど。

そんなわけで Chromium.org には以下のコンテンツが用意されてるそうです。

  • ソースコード (前述のようにライセンシーが権利を持ってるソース以外)
  • 技術文書 (ビルドの仕方から内部構造まで)
  • フォーラム
  • BTS

...

特にフォーラムについては英語以外で唯一日本語のフォーラムが用意されているし、Google の日本人も見ているのでバグ報告などをどんどんあげてほしいとのことです。

また Chrome の普通のリリースは BETA ですが、Dev Channel というリリース形態もあって、これは Weekly Build をぽんぽん出すようなもので、ちょっとのバグの可能性には目をつぶってどんどんアップデートしたい人向き。

さらに Cutting Edge な人は Git で trunk 取ってビルドも可能です。

Windows 版は Visual Studio 2005 でないとビルドできないそうですが (WebKit 側の問題らしい)、ビルドしてしまえばデバッガで遊んだりいろいろできるので面白いですね。


ということで、なかなか面白いプレゼンでした。

残念ながら現行の Chrome はまだ若干不安定ですが、コンセプト自体はよいものがあるので、安定度を上げてのリリースが望まれますね。

また Linux 版を壱からビルドするのはめんどくさいので rpmdeb で早くリリースされないかなって思ってます。


KOF ツアー

お次は「オープンソースプロレスだ!」を標榜する法林さんがガイドを務める、KOF ウォーキングツアー。

ま、一回参加すればいいかな、って気がする。

法林さんのトークは好きなので、今回は後悔はしてないけど。


ステージ企画:「Ubuntu 8.10ほかもろもろ」&「2008/09 リリース予定 Debian 5.0 "Lenny" について」

うかつに「Ubuntu/Debian 対決」って書いたらやまねさんに速攻で突っ込まれた

Ubuntu の水野さんのプレゼンも興味深かったけど、プレゼンとしてはやまねさんの方が面白かった。

「対決」って言葉を使った責任として采配を勝手に振ると、Ubuntu の方が確かに集客力は上だったけど、おもしろさという意味では Debian の方が上ということで、引き分け! (ううむ、実に日本人らしい日和見だ)。


Ruby 1.9 の話

最後は Yugui さんの Ruby 1.9 解説。

Yugui さんちょーかっこえー。まさに理想のリリースマネージャ。管理される方は大変かもしれないけど、まさにマネージメントかくあるべしだと思った。

などという雑感はともかく、プレゼンの内容をサラッと紹介。

Ruby 1.9 とはそもそも何か?

特徴としては以下のとおり。

では一つ一つ見ていきましょう。

VM
  • 元々 YARV (やるぶ: Yet Another Ruby VM) と言っていたのだけど、本家に取り込まれたので止めよう……といいつつ、定着しちゃったのでたぶんこのまま*1
  • 実行スピードは約5倍*2
  • バイトコードレベルコンパチビリティを持つ。つまり x86バイトコードPPC 版に持っていったりしても動く。
  • ということは技術的には .class みたいなこと (= バイトコードコンパイルまではすませておいて、バイナリ配布) みたいなことは可能である (が、作ってる側の関心は薄そう)。
Native Thread
Fiber *3
  • ユーザレベルスレッドからコンテクストスイッチを取ったもの
  • だから気軽に生成して気軽に使えるけど、スイッチングは自前
M17N
# -*- coding: euc-jp -*-
文法の改訂

あんま細かいこと覚えてないのだけど、Block まわりの文法が複雑だったのが簡素化されてわかりやすくなったとかなんとか。

Rails との関係
  • たぶん速くなるとは思う。
  • まだ構想段階だけど、Rails みたいな規模が大きいシステムには Multi VM なんてのが効くんじゃないかって議論がある。
  • ただし YARV は eval が重いので、eval の山 (不要な所でも eval しまくり) の RailsYARV の効果と相殺になってしまうかも
  • 互換性については、そもそも今の Rails は 1.9 では動かない。
    • 主に Rails 自体が String クラスを大幅に拡張していることが 1.9 とのバッティングを起こしている
    • ただし Rails の開発チームは開発力があるので、1.9 が stable になったらすぐ追いついてくるだろう
Release Schedule
1.9.1 preview 2
2008-11-25
1.9.1 RC
2008-12-25
1.9.1 final
2009-1-25

RC と final が一月開いているのはクールダウンフェーズということだそうな。

Release Management

そもそも Yugui さんはリリースマネージャということだけど、そもそも Ruby におけるリリースマネージャとは?

  • 1.8.x の初期のころまではリリースマネージメントなんて存在しなかった
  • のでリリース予定近くになっても機能突っ込む奴とかいてグダグダ
  • 武藤さんキレる
  • ルール整備
  • それを改善しつつ踏襲して 1.9 のマネージメントルールを Yugui さんが決め今に至る

とかいってたような (なぜか手元にメモがない)。

今のリリースマネジメントはこんな感じらしい。

  • Support Level の明確化 (1.9 新規)
    • 環境によってサポートレベルを明確にする
    • 今は以下の5種類
Supported
メンテナが存在し、Daily Build の環境もあって、すべての機能が確実に動くことが保証された環境。現状 Debian i386 のみ。
Best Effort
メンテナが存在し、Daily Build の環境もあるが、一部機能に制約が存在するなど問題がある環境。Win32、FreeBSD など。
Perhaps
Ruby プロジェクトとしては公式にサポートしていないが、多分動くだろう、という環境。Mac OS X や、Debian 以外の Linux など。
Not Supported
文字通り。OS/2 とか MS-DOS とか?
  • メンテナーのアサイン
  • Feature Freeze
    • あるバージョンの新機能入れ込みに締切りを設けること
    • ていうか 1.8.x の初期には決まってなかったらしい。そりゃ切れるわ。
  • Cool down phase (1.9 から導入)
    • RC を出してからしばらく寝かせること。バグ報告待ちだったりなんだたり。
  • issue tracker
Migration について

HowTo としては:

  • Magic Comment でエンコーディングを明記する
    • 1.8 でも無害だから今のうちやっておきませう
  • Block の文法変更に伴って手直し必要かも
  • 文字列エンコーディング違いで例外吐かれるかもしれないけど、それは潜在的に文字化けを起こしかねないソースだったんで、諦めて直そう

適切な時期は?

  • Yugui さん曰く:

今の preview1 でショッピングサイトとか使ったら、たぶん私は使います。でもインターネットバンキングで1秒で億のお金が動くようなシステムを作るのは進められません。そういう品質だと思ってください。

普通には十分使えるレベルになっていると思います。

Q&A
Q
サポートライフは? とくに 1.8 系が心配。
A
1.8 系も次のバージョンが出ることは確定しているし、しばらくは続くと思う。
Q
1.8 と 1.9 で両方で動くソースを書くことはできるか?
A
iconv, kconv は互換のために残されているので、これでエンコーディングをうまく書いてやるしかないのでは。
Q
サポートライフを Ruby プロジェクトとして決めるつもりはないのか。多くの Linux ディストリビューションプロジェクトの様に。
A
今はまだ Ruby コミュニティにそこまでの余力がない。そういうものがあったらよいとは思う。
Q
マルチ VM って何がおいしいのか。プロセスが分かれて CPU のコアが活用できるということは分かるが。
A
まだ構想段階でありはっきりとしたことはいえない。1.9 のどこかで Selector Namespace の導入を検討しており、それとの組み合わせで機能提供されるのではないか。もちろん VM 間で情報のやりとりをするようなしくみは用意されるだろう。
Q
1.8→1.9 コンバータみたいなものは作れないのか?
A
Magic Comment で救えないものについては、何が正しいかを機械的に判断するのはムリ。

いやー、おもしろかった。

これにて KOF 2008 の全プログラムは終了。


Debian/Ubuntu 懇親会

そのあとなぜか、Ubuntu はタダのユーザだし、Debian にいたってはテスト環境を構築するぐらいのことしかしてないのに懇親会になだれ込む。

非常に面白かった。とりあえず「KDE の K は『北』の K」は笑った。

クルマなので飲めなかったのが少々残念。


まあとにかく、来年も必ずこようと誓ったのであった。

が、自走で行くかどうかは悩むところだ (^^;)

行きも帰りも眠くて眠くて、死ぬかと思ったからな。

でも次の日はこんなところで遊んでたから、ボート持っていって正解か?

f:id:naruoga:20061022125557j:image

2008.11.23 7:32 やっとタイトルから(仮)が取れましたよ。ふー。

関西オープンフォーラム 2008 初日

オイラが OSS と関連を持つ前に噂は聞いていた関西オープンフォーラム、略して KOF だと対戦格闘になってしまうので、K-OF と略したりするらしい。


そんなわけで勢いで参加しちゃったよ。関西オープンフォーラム2008

関東から車で頑張って運転して。

ほとんど完徹で運転したので到着したらへろへろだったけど、なんとなく昼飯食って、そのままなだれ込んでみたさ。

初日は開始後ちょろっと会場回っただけで、あとはずっとセミナー張り付き。

これだとなかなか新しい出会いってないんで、ちょっと後悔もしたけど、セミナーそのものの満足度は高かった。


FLOSS 論 via Debian

最初のセッションは「『あなた』とオープンソース/フリーソフトウェア、そして『Debian』(ver.k-of2008)」。

やまねさんの Debian を題材にした FLOSS 論。

いちおーオイラも引地夫妻の「Think GNU」とか読んでるクチなので、フリーソフトウェア論というのはそれなりにわきまえてるつもりだけど、ああやって説明されると、なるほど、という感じ。

ライセンスプロトコルだ」というたとえも非常にわかりやすかった。苦労してるだけに実感こもってますよね。

オープンソースで失敗する事例」ってのが強烈痛かった。ウチの会社はへたすっとその戦略になりかねない。そうならないように気をつけねば。

一方でオレも「一人で頑張っちゃうタイプ」にならないように気をつけねば (^^;)

2008.11.23 追記:やまねさんの日記プレゼン資料の PDF へのリンクが上がってるのでトラバ張っておきます。

勉強会の作り方

すっかり勉強会宣伝役と化している id:hyoshiok さんの「勉強会の作り方」は、id:hyoshiok さんの「カーネル勉強会」の事例をサカナにディスカッション形式でというもの。

もっと関西の人の成功体験を聞きたかったなー、オイラが社内勉強会やってうまくいかなかったって失敗談から口火を切っちゃったのがいけないのかなー。

でもやっぱり「主催してる本人、参加してるみんなが楽しんでる」ということが継続の力なんだな、というのは当たり前だけど思った。だからまずは共通の楽しいという基盤を持てるコミュニティを作るところなんだよなと。

今までオイラが社内の勉強会というのを何度か企画してうまくいかなかった理由は、やっぱりね、みんな気持ちは「お仕事」なんだよ。

「身銭切ってまで勉強したくねー」なんだよ。

ウチの会社のレベルが低いのか、大抵の人がそうなのかわかんないけど、「会社終わった後、どっか会議室でも借りて、ピザでもつまみながらやろうよ」って言ってもだれも乗ってこないもんな〜。

まずはそこんとこをなんとかせねばならんと思うのだ。「楽しい!」「プライベートの時間を割いても参加したい!」って思える雰囲気作り。社内の勉強会って話で言えばね。難しいのかなぁ。


ステージ企画:「超簡単、コミュニティ貢献」&「Samba最新動向」

お次はステージで、JM Project/Fedora Docs Project の岡崎さんの「超簡単、コミュニティに貢献してみよう!」って話と、日本 Samba ユーザ会の高橋さんによる「Samba最新動向」。

どちらもふむふむ。

前者は「もっと査読しようよ!」って話。

英語ができなくてもみんな日本語ならできるでしょう? 査読しないで放っておいて 2ch とかブログとかで悪口かくのやめようよ。活動してる人のやる気を削ぐしさ。だったら査読って形で翻訳プロジェクトに貢献しないかい? って話。

これは各コミュニティ共通の話題みたいだね。前の openSUSE勉強会の時もそんな話になったし。

Samba 4.0 はちょっと開発停滞してる感じみたいだけど、想像するに、開発者のモチベーションが上がらないんじゃないかなぁ。

だってさ、もともと「オレの LinuxWindows でファイル交換できたらなー」って目的はもう達成されちゃってるじゃない。今やってる拡張は、いわばビジネス性を上げる話じゃない? ニーズがあるのはよーく分かるけど、それって開発コミュニティモチベーションにつながるかというと微妙だなって思っちゃう。

いっそのこと MySQL みたいに会社組織にしてお金儲けしたほうがいいんじゃないかしら。

と、部外者かつ素人が勝手なことをいう。


OOo 3.0 は何が変わったの?

最後のセッションOpenOffice.org 3.0 で何が変わったのか?」は、びみょーって感じだった (ゴメン)。

プリンタ屋からするとさー、どうしても MS Office から OOo に乗り換えるときに問題になるのはデータの移行で、そこで揉めて印刷トラブルでウチに話持ってこられるのがツラいのよ。

だからそういう話をつっこんで聞きたかったんだけど、機能紹介、MS Office との機能比較に終始しちゃってて、そこがねー。

「これだけよくなったから、MS Office なんか捨てて OOo 使ってね」って言われても「いや、新規に作るデータはいいけどさ、今まで作ったデータがちゃんと読める保証があるの?」って問いに答えられなきゃいけないと思うのさ*5

だって DTP 屋とか CAD 屋なんて、未だに Mac OS 9 とか MS-DOS の環境残してるんだよ。データ移行して化けるのが怖いから。

オフィス文書はそこまでシビアじゃないけど、「機能では負けてないから乗り換えて」ってのは少々素朴過ぎる気がするのだ。プリンタの世界じゃ「この文字はこの文字に比べると見た目太く見える」とかいうクレームと日々戦ってるんだからさぁ。

せめて JEITA のテストデータ全部食わせるぐらいのことやってもいいと思うんだけどな。

というか、プリンタベンダなんかどこも JEITA のデータぐらい持ってるんだから、テストしてレポート上げてやればいいのに。ウチも含めてね。つーかごめんなさい、やろうと思って暇が取れないでいます (--;)

あ、でも JEITA のデータは有償だから、バグレポ上げてもデータが上げられないや。

OOo ユーザ会で JEITA に掛け合ってわけてもらうとかはできないかな?


まあでも、それぞれに面白くて、わざわざ関東から来たかいはあったかな?

翌日も楽しみだ。


そして懇親会は大盛り上がり。

というか食べ物多すぎ! 大量に残った食べ物を見て、なんかすげー負けた気がした……。

はてなダイアリー開設。

最近コミュニティの会合や勉強会なんかに参加したり、テクニカルな調べごとをプライベートでやったりすることが増えてきた。

そういう内容は mixi に書いてたんだけど、mixi だとトラックバックを張ったり張られたりができなくてイマイチなので、技術的な内容はこちらに書いてみようかなと。

まぁメインフィールドは mixi なので、コピペmixi にも書くと思うけど。

てなわけで、よろしくです。

*1:関係ないけど YARV のささださんはオイラの出身研究室の隣の研究室出身で、YARV は元々卒研テーマだったんじゃなかったかな?

*2:でも OSC/Fall Tokyo 2008 で聞いた限りでは、M17N で速度を食われてしまうのでそこまでは早くならないので、チューニングとして文字列ASCII だったら M17N をバイパスするとかしてるらしい。

*3:ちょっと前から NT 系 OS にも入ってるから知ってる人は知ってるよね

*4:オイラはこれを Ruby の一つの見識だと思っていて、エンコーディングの自動変換をすると FULLWIDTHTILDE / WAVEDASH 問題みたいなのにハマるから、変換はしたい人がプリプロセスなりポストプロセスで好きなようにやってくれ、そのための道具立ては準備するから、気に入らなかったら手を入れてくれ、ってのは正しい姿勢だなって思ってたんで、これも OSC/Fall Tokyo 2008 で聞いてみたら、「それだと非 CJK 圏の人が作った人間で日本語が通らないとかいうことになりうる。実際問題になっている」とのことで、ちょっと納得した。

*5トラバまで張ってもらったので補足。「MS Officeだってプリンタ変えたりバージョン上げたりすると文字の配置変わったりするのに、なんで OOo だけそういう問いに答えることを要求されるのか」と問われたときの答えは二つ。OOo の場合、インポートに失敗して文字化けすることがある。多分デバイスフォントがらみだと思うのだけど、ずれた奴は修正可能だけど、化けた奴は Office 捨てちゃったあとだと復元不可能でしょうってこと。もう一つは、バージョンアップと違い、マイグレーションは売り込んで行くものだから、売り込む側がそういうナレッジを持っているべきでしょうってこと。