パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

一太郎、OpenDocument対応モジュール提供開始」記事へのコメント

  • あのクソなHTML出力機能を平気な顔でほったらかしにしてる
    ジャストの作る標準化技術準拠モジュールの完成度が、どの程度のモノか、
    なかなか興味深いモノがあると思うんだけどさ。
    • 今回は出力されるファイルがXMLなので、規格上の違反はしていないだろうと思われます。しかし、人間が容易に判読・編集できるような.odtを吐くかは別問題、ホームページ作成ソフトのいくつかがそうであるように、規格上誤りがないからといって、クソでないとは限らない……かもしれません。

      Q&Aページを見ると、文字データ、文書スタイル、ヘッダ/フッタ、文字/段落飾り(スタイル)、罫線、レイアウト枠、が保存対象のようで、作図、画像枠、オブジェクト枠、段組等は保存されないようですが、これらがどう処理されるのか(単純に消されるとかなんか工夫されるとか)は興味深いところです。

      一太郎をつかわなくなってはや10年、自分では検証できないkmpでした。
      • by Anonymous Coward on 2006年09月09日 17時03分 (#1015288)
        今回は出力されるファイルがXMLなので、規格上の違反はしていないだろうと思われます。しかし、人間が容易に判読・編集できるような.odtを吐くかは別問題、ホームページ作成ソフトのいくつかがそうであるように、規格上誤りがないからといって、クソでないとは限らない……かもしれません。

        人間が容易に判読・編集できるような.odtって、 もしかしてちゃんと階層ごとに white spase でインデントされて改行もキチンとしている XML を期待しているって事かな?

        もしもそうであれば、そんな「XML→可読可能なフォーマット→人間が視覚的に理解可能なフォーマット」という古い考えは、もういい加減に捨ててください。複合ドキュメントは定型レイアウト×nレコードみたいなデータとは訳が違うのですから。

        OpenPffice.org Writer が吐いた odt を解いて content.xml を1回見てごらん。

        親コメント
        • by Anonymous Coward on 2006年09月09日 21時41分 (#1015458)

          オプション/読み込みと保存/全般/XML形式でのサイズの最適化

          のチェックをはずすと、適宜インデント&改行入りの データを出力してくれるという機能がある時点で、 人間の可読性はやっぱり重要ってのは OpenOffice の中の人もわかってるんじゃないかなー

          これを知る前に、odt 内部のファイルを直接 加工するツールをつくってて、エラーの原因を 調べるのに死ぬほど苦労したことが…

          テキストファイル中で場所を特定する方法が、 一般的には「行番号+桁番号」以外に共通して使える ものがない、ってのが悲しい現実だからねぇ。 2行目の45234桁 とかいわれても途方にくれてしまう。

          親コメント
        • > もしもそうであれば、そんな「XML→可読可能なフォーマット→人間が視覚的に理解可能なフォーマット」という古い考えは、もういい加減に捨ててください。
          > 複合ドキュメントは定型レイアウト×nレコードみたいなデータとは訳が違うのですから。

          じゃあ、なんでテキストファイルになってるんだよ。
          何たる無駄な構造。

          • 意味的ポータビリティじゃない?
            意味不明なバイト群でツリー構造を表現される事に
            比べれば、タグ自身に「名前付け」という方法で
            もって意味を与えておけばテキストとみなした時に
            その要素の意味を類推しやすい。
            <paragraph> みたいにさ。

            ただ、その事と適切な改行&インデントによる
            整形は別の話しだな。

            XMLの設計思想の中には人間にとって読みやすく
            理解しやすい的な文句はあったけど、適切な改行&
            インデントによる視覚的な整形を仕様として強制
            していない単にある程度の厳密さを定めた
            マークアップ言語全般の利点をうたっているだけに
            等しいしな。
          • きっとPOP3とかのプロトコル見たこと無いんだろうなぁ

            手打ちでPOP3やる人もあんま居ないと思うが
            動作確認時以外

            でもあれはテキストコマンドの羅列
            • 動作確認でtelnet host 110することはよくあるけど、
              人間が判読できるからこそだな。

              人が判読できないXMLファイルにいったい何の意味があるか、
              考えたことないんだろ?

              • スレに参加している面々で "可読" "判読" の具体的な姿に同一の理解がないような気がするので議論は意味が無いというか益がないというか。

                ポイントはインデント&改行で綺麗に整形されているかどうかって事なのか? その辺、どうなのよ?
                そもそもの発端である#1015252 [srad.jp]は、巷の HTML作成ソフトが吐く謎めいて見た目に汚いデータのことを言っているのでそうだと思っているんだが、違うのかな?どうなんだろう?

                もしもそうであればなんだが、オレは要素内容が可読できないもの(謎めいた符号化で理解不能とか

              • > そもそもの発端である#1015252は、
                > 巷の HTML作成ソフトが吐く謎めいて見た目に汚いデータのことを言っているのでそうだと思っているんだが、
                > 違うのかな?どうなんだろう?

                そこじゃない。

                #1015288> もしもそうであれば、そんな「XML→可読可能なフォーマット→人間が視覚的に理解可能なフォーマット」という古い考えは、
                #1015288> もういい加減に捨ててください。

                に対する指摘が、

                #1015500> 何たる無駄な構造。

                ここ。

                で、その指摘に対する回答は、

                #1015525> 意味的ポータビリティじゃない?

                #1015525> XMLの設計思想の中には人間にとって読みやすく
                #101552
          • バイナリ処理に比べてテキスト処理の方がはるかに楽じゃないか。
            コードを書く場合もそうだが、ツールの種類や運用性も含めてさ。
            ポータビリティを目的とした文書フォーマットなら当然の選択でしょう。
          • 色んなツールで読み込むであろうデータにはテキストが一番だからでしょ。
        • > XML→可読可能なフォーマット→

          可読可能、、、思わず可口可楽 [colawp.com]と空目してしまった。

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

処理中...