アカウント名:
パスワード:
今回は出力されるファイルがXMLなので、規格上の違反はしていないだろうと思われます。しかし、人間が容易に判読・編集できるような.odtを吐くかは別問題、ホームページ作成ソフトのいくつかがそうであるように、規格上誤りがないからといって、クソでないとは限らない……かもしれません。
人間が容易に判読・編集できるような.odtって、 もしかしてちゃんと階層ごとに white spase でインデントされて改行もキチンとしている XML を期待しているって事かな？
もしもそうであれば、そんな「XML→可読可能なフォーマット→人間が視覚的に理解可能なフォーマット」という古い考えは、もういい加減に捨ててください。複合ドキュメントは定型レイアウト×nレコードみたいなデータとは訳が違うのですから。
OpenPffice.org Writer が吐いた odt を解いて content.xml を1回見てごらん。
オプション/読み込みと保存/全般/XML形式でのサイズの最適化
のチェックをはずすと、適宜インデント＆改行入りの データを出力してくれるという機能がある時点で、 人間の可読性はやっぱり重要ってのは OpenOffice の中の人もわかってるんじゃないかなー
これを知る前に、odt 内部のファイルを直接 加工するツールをつくってて、エラーの原因を 調べるのに死ぬほど苦労したことが…
テキストファイル中で場所を特定する方法が、 一般的には「行番号＋桁番号」以外に共通して使える ものがない、ってのが悲しい現実だからねぇ。 2行目の45234桁 とかいわれても途方にくれてしまう。
スレに参加している面々で "可読" "判読" の具体的な姿に同一の理解がないような気がするので議論は意味が無いというか益がないというか。
ポイントはインデント＆改行で綺麗に整形されているかどうかって事なのか？ その辺、どうなのよ？そもそもの発端である#1015252 [srad.jp]は、巷の HTML作成ソフトが吐く謎めいて見た目に汚いデータのことを言っているのでそうだと思っているんだが、違うのかな？どうなんだろう？
もしもそうであればなんだが、オレは要素内容が可読できないもの（謎めいた符号化で理解不能とか
#1015617 [srad.jp] で tetsuyaさん [srad.jp]が作成した、一太郎（＋ODFモジュール）で出力した ODF（odf）を使って、こんな所を見てみた。
ざっとみてみたところ、差がありますね。
前者はテキストの中の半角空白で区切って処理されてる。たとえば文書末尾にある ( もっと読む… | 45 コメント ) という部分はこんな感じ（改行など整形は我がやった）
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
仕様を理解してるのかなぁ (スコア:0)
ジャストの作る標準化技術準拠モジュールの完成度が、どの程度のモノか、
なかなか興味深いモノがあると思うんだけどさ。
Re:仕様を理解してるのかなぁ (スコア:3, 参考になる)
Q&Aページを見ると、文字データ、文書スタイル、ヘッダ／フッタ、文字／段落飾り(スタイル)、罫線、レイアウト枠、が保存対象のようで、作図、画像枠、オブジェクト枠、段組等は保存されないようですが、これらがどう処理されるのか（単純に消されるとかなんか工夫されるとか）は興味深いところです。
一太郎をつかわなくなってはや10年、自分では検証できないkmpでした。
人間が容易に判読・編集できるような.odtっ (スコア:3, 参考になる)
人間が容易に判読・編集できるような.odtって、 もしかしてちゃんと階層ごとに white spase でインデントされて改行もキチンとしている XML を期待しているって事かな？
もしもそうであれば、そんな「XML→可読可能なフォーマット→人間が視覚的に理解可能なフォーマット」という古い考えは、もういい加減に捨ててください。複合ドキュメントは定型レイアウト×nレコードみたいなデータとは訳が違うのですから。
OpenPffice.org Writer が吐いた odt を解いて content.xml を1回見てごらん。
Re:人間が容易に判読・編集できるような.odtっ (スコア:1, 参考になる)
オプション/読み込みと保存/全般/XML形式でのサイズの最適化
のチェックをはずすと、適宜インデント＆改行入りの データを出力してくれるという機能がある時点で、 人間の可読性はやっぱり重要ってのは OpenOffice の中の人もわかってるんじゃないかなー
これを知る前に、odt 内部のファイルを直接 加工するツールをつくってて、エラーの原因を 調べるのに死ぬほど苦労したことが…
テキストファイル中で場所を特定する方法が、 一般的には「行番号＋桁番号」以外に共通して使える ものがない、ってのが悲しい現実だからねぇ。 2行目の45234桁 とかいわれても途方にくれてしまう。
Re:人間が容易に判読・編集できるような.odtっ (スコア:0)
> 複合ドキュメントは定型レイアウト×nレコードみたいなデータとは訳が違うのですから。
じゃあ、なんでテキストファイルになってるんだよ。
何たる無駄な構造。
Re:人間が容易に判読・編集できるような.odtっ (スコア:0)
意味不明なバイト群でツリー構造を表現される事に
比べれば、タグ自身に「名前付け」という方法で
もって意味を与えておけばテキストとみなした時に
その要素の意味を類推しやすい。
<paragraph> みたいにさ。
ただ、その事と適切な改行＆インデントによる
整形は別の話しだな。
XMLの設計思想の中には人間にとって読みやすく
理解しやすい的な文句はあったけど、適切な改行＆
インデントによる視覚的な整形を仕様として強制
していない単にある程度の厳密さを定めた
マークアップ言語全般の利点をうたっているだけに
等しいしな。
Re:人間が容易に判読・編集できるような.odtっ (スコア:0)
手打ちでPOP3やる人もあんま居ないと思うが
動作確認時以外
でもあれはテキストコマンドの羅列
Re:人間が容易に判読・編集できるような.odtっ (スコア:0)
人間が判読できるからこそだな。
人が判読できないXMLファイルにいったい何の意味があるか、
考えたことないんだろ？
"可読" "判読" の具体的な姿 (スコア:0)
スレに参加している面々で "可読" "判読" の具体的な姿に同一の理解がないような気がするので議論は意味が無いというか益がないというか。
ポイントはインデント＆改行で綺麗に整形されているかどうかって事なのか？ その辺、どうなのよ？
そもそもの発端である#1015252 [srad.jp]は、巷の HTML作成ソフトが吐く謎めいて見た目に汚いデータのことを言っているのでそうだと思っているんだが、違うのかな？どうなんだろう？
もしもそうであればなんだが、オレは要素内容が可読できないもの（謎めいた符号化で理解不能とか
Re:"可読" "判読" の具体的な姿 (スコア:0)
> 巷の HTML作成ソフトが吐く謎めいて見た目に汚いデータのことを言っているのでそうだと思っているんだが、
> 違うのかな？どうなんだろう？
そこじゃない。
#1015288> もしもそうであれば、そんな「XML→可読可能なフォーマット→人間が視覚的に理解可能なフォーマット」という古い考えは、
#1015288> もういい加減に捨ててください。
に対する指摘が、
#1015500> 何たる無駄な構造。
ここ。
で、その指摘に対する回答は、
#1015525> 意味的ポータビリティじゃない？
#1015525> XMLの設計思想の中には人間にとって読みやすく
#101552
Re:人間が容易に判読・編集できるような.odtっ (スコア:0)
コードを書く場合もそうだが、ツールの種類や運用性も含めてさ。
ポータビリティを目的とした文書フォーマットなら当然の選択でしょう。
Re:人間が容易に判読・編集できるような.odtっ (スコア:0)
Re:人間が容易に判読・編集できるような.odtっ (スコア:0)
可読可能、、、思わず可口可楽 [colawp.com]と空目してしまった。
Re:人間が容易に判読・編集できるような.odtっ (スコア:0)
Re:仕様を理解してるのかなぁ (スコア:2, 参考になる)
OOo Writerで開いてみたら、見出しの大、中、小の設定などはそのまま引き継がれていましたね。罫線は試してみませんでした。貼り付けたアイコン（画像）は単純に消えてしまったようです。
保存したファイルはここ [yahoo.co.jp]に置いてみたので、OOo使ってる人は開いてみてください。
一太郎（ODFモジュ）→ odt → OOo → odt の結果 (スコア:0)
#1015617 [srad.jp] で tetsuyaさん [srad.jp]が作成した、一太郎（＋ODFモジュール）で出力した ODF（odf）を使って、こんな所を見てみた。
ざっとみてみたところ、差がありますね。
前者はテキストの中の半角空白で区切って処理されてる。たとえば文書末尾にある ( もっと読む… | 45 コメント ) という部分はこんな感じ（改行など整形は我がやった）
(
<text:span text:style
Re:仕様を理解してるのかなぁ (スコア:0)
Re:仕様を理解してるのかなぁ (スコア:1)
サイズが小さい方が一太郎で保存した方で、Writerで作成した表のみが残っています。
Re:仕様を理解してるのかなぁ (スコア:0)
アプリケーションが処理しやすいように出力するほうが妥当だと思います。