アカウント名:
パスワード:
そういう点では、デファクトスタンダードである Microsoft Office Suite のドキュメントと全く互換性の無い (いかに変換をかけても埋めようの無い差のある) ODF は経緯を気にしていないことになるように思いますが、どうなのでしょうね。そして、それを満場一致で可決した JTC1 は経緯を考えていないのでは、と。村田氏に「細かく見ていたら通る訳がない」ものと言われてしまっていますし。
とりあえずオープンなものを、ということで 1 つの仕様書内ですら整合性がまともに取れていない ODF が通ってしまっているのは、まさに「企画書の体裁さえ整っていたらなんでも追認する」状況ではないですか。OOXML に対しては前例ができたので、とりあえずまともに評議しようとしている、と。
そういう点では、デファクトスタンダードである Microsoft Office Suite のドキュメントと全く互換性の無い (いかに変換をかけても埋めようの無い差のある) ODF は経緯を気にしていないことになるように思いますが、どうなのでしょうね。
その時点では、MSの文書は全くのブラックボックスだったのですから、互換性のとりようがありません。
MS Office文書の仕様は一部が開発者向けに公開されています。 (たとえば "Rich Text Format (RTF) Specification" [microsoft.com]) ですから全くのブラックボックスとはよくある誤解です。
非公開なのはそれぞれの機能に割り振るコードとか実装に深く関係する部分です。 そうでなければOffice互換ソフトなんて一から作れるわけないでしょ。
だからその、実装に深く関係する部分、が公開されないのが困るんでしょうが…
ODFでは始めからXMLとZipで実装するのだから、MS Officeの実装が分かったところで参考にならないと思いますけど。 何が困りますか?
おかげで、ワードファイルが肥大化して破損した場合、 なんとかできるようなユーティリティはHTMLやtexのようには存在しません。
プレインテキストに比べて構造に矛盾が生じやすいのは否定しませんが、復元手段が存在しないと言うのもまた誤解に基づくものです。
まず、破損したファイルの修復機能であればMS OfficeにもOpenOffice.orgにも最初から組み込まれています。試してみてはいかがでしょうか。 少しずつ改良されていますので、昔壊してしまったファイルも読めるようになっているかもしれません。
破損したHTMLやTeXを修復するユーティリティとはテキストエディタ+人力のことでしょうか。そのように低レベル操作を意図しているのであればCFX [coco.co.uk]はいかがでしょう。 それに限らずCompound Fileは構造もAPIも公開されていますので、オープンソースの実装もありますよね。Perlのモジュールとか。
まず、破損したファイルの修復機能であればMS OfficeにもOpenOffice.orgにも最初から組み込まれています。試してみてはいかがでしょうか。少しずつ改良されていますので、昔壊してしまったファイルも読めるようになっているかもしれません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
ODFは満場一致で賛成 (スコア:5, 興味深い)
これだけ読むとODFがすばらしく優れているように感じますが、実際はなんでもいいから文書フォーマットの標準化をとにかく急いで完成度を不問にした結果みたいですね。
はっきり言ってしまうと、ODFの仕様書は規格といってしまうにはいまいちなデキです。
コメントが短すぎたり、別の規格を参照する過程で解釈が分かれる部分などが散見されます。
おそらく規格どおりに作成しても互換性は保たれないので、ところどころでOpenOffice.orgの実装を参照しなければまともなオフィススイートはつくれません。
OOXMLの仕様書はサンプルを多く載せているのと外部参照を減らしているので多少はましな印象ですが、規模が巨大なためすべてを実装するのは体力がないと辛いです。
ということで、OOXMLの仕様書は私企業版にとどめておいて
ODF-OOXML間の厳密な変換方法を規格化すると少し楽しい未来になるんじゃないですか。
Re:ODFは満場一致で賛成 (スコア:1, すばらしい洞察)
> 対して、OOXMLは現時点で19カ国が反対を表明したそうです。
「標準規格を定めてみんなでそれを使おう。」
と各国がODFを(完成度の問題に目をつぶって)担いだ後で、
「標準規格をみんなで使いたいのか。よし、うちの製品の規格を公開してやるから、お前らで標準規格に認定して、それを使えや。by MS」
という流れだからねえ。心情的な問題も多少はあるんでなかろうか。
Re:ODFは満場一致で賛成 (スコア:1, すばらしい洞察)
そんなことはないと思いたいが、そうすると他の真っ当な理由があるはずで、ぜひともそのへんが知りたいところだが…
使い手としては中身が問題で、誰が作ったとかどういう経緯でできたとか、そんなことはどうでもいい。
Re:ODFは満場一致で賛成 (スコア:2, すばらしい洞察)
そういう「標準化に対する理念」を失って、企画書のフォーマットさえ整っていたら何でも追認するような団体こそ必要ないものです。
Re:ODFは満場一致で賛成 (スコア:1, すばらしい洞察)
そういう点では、デファクトスタンダードである Microsoft Office Suite のドキュメントと全く互換性の無い (いかに変換をかけても埋めようの無い差のある) ODF は経緯を気にしていないことになるように思いますが、どうなのでしょうね。そして、それを満場一致で可決した JTC1 は経緯を考えていないのでは、と。村田氏に「細かく見ていたら通る訳がない」ものと言われてしまっていますし。
とりあえずオープンなものを、ということで 1 つの仕様書内ですら整合性がまともに取れていない ODF が通ってしまっているのは、まさに「企画書の体裁さえ整っていたらなんでも追認する」状況ではないですか。OOXML に対しては前例ができたので、とりあえずまともに評議しようとしている、と。
Re:ODFは満場一致で賛成 (スコア:1, 興味深い)
それは、全く経緯を無視した指摘ですよ。その時点では、MSの文書は全くのブラックボックスだったのですから、互換性のとりようがありません。
今こういう議論ができる事自体が、JTC1の英断のおかげだと言う事を忘れてはいけませんよ。そういう意味では、意図が狙い通りに反映されている、と言えるでしょうね。
Re:ODFは満場一致で賛成 (スコア:2, 参考になる)
MS Office文書の仕様は一部が開発者向けに公開されています。
(たとえば "Rich Text Format (RTF) Specification" [microsoft.com])
ですから全くのブラックボックスとはよくある誤解です。
非公開なのはそれぞれの機能に割り振るコードとか実装に深く関係する部分です。
そうでなければOffice互換ソフトなんて一から作れるわけないでしょ。
Re:ODFは満場一致で賛成 (スコア:1, 参考になる)
ODFにお尻を叩かれてやっと動く会社ですから。
おかげで、ワードファイルが肥大化して破損した場合、
なんとかできるようなユーティリティはHTMLやtexのようには存在しません。
それに、標準化した後に独自拡張とかも考えてたりしそうですしね。
実際、外部のメーカーが互換ソフト作っても内部規格変更の度振り回されてるでしょうし。
# MARQUEE機能とか作ったら笑うけど…
Re:ODFは満場一致で賛成 (スコア:0)
ODFでは始めからXMLとZipで実装するのだから、MS Officeの実装が分かったところで参考にならないと思いますけど。
何が困りますか?
プレインテキストに比べて構造に矛盾が生じやすいのは否定しませんが、復元手段が存在しないと言うのもまた誤解に基づくものです。
まず、破損したファイルの修復機能であればMS OfficeにもOpenOffice.orgにも最初から組み込まれています。試してみてはいかがでしょうか。
少しずつ改良されていますので、昔壊してしまったファイルも読めるようになっているかもしれません。
破損したHTMLやTeXを修復するユーティリティとはテキストエディタ+人力のことでしょうか。そのように低レベル操作を意図しているのであればCFX [coco.co.uk]はいかがでしょう。
それに限らずCompound Fileは構造もAPIも公開されていますので、オープンソースの実装もありますよね。Perlのモジュールとか。
Re:ODFは満場一致で賛成 (スコア:1)
この復元機能ですが、いつも感じるのは、どこまで復元されているのか、怪しくて安心して使えない、
という点です。
Word などでよくあるのが、図や表を入れて、さらにそれを float させると、次第に理解不能の挙動を示すようになる。それを何とかしようといじっているうちに落ちる。で、次に起動して、復元らしき事が行われますが、そもそも不安定な挙動を示していたものなので、何がどこまで復元されているのか、意図したように復元されているのか、良く分からない。なので、こういうことにあうと、とりあえずテキストだけ保存し直して、ファイル作り直しをします。ロスはでかいですが、疑心暗鬼で作業するよりよっぽどまし。なお、当然、図を float させようなどというお恐れ多いことは考えないようにします。これまた不便ですが、挙動不審よりマシです。
プレーンテキストでなにがうれしいかというと、テキストエディタで表示されているものがファイルの内容そのものである点です。それは低レベルなのかもしれませんが、単純で分かりやすい構造です。
というわけで、Word を使わざる得ない場合には、
と心に決めております。
なので、Word に新機能なんていりません。Word 95 あたりで十分です。
# バグだけとってね