這篇已經很久了 最早的mso2007sp1以前確實是這樣 之後的已經不是 而且如果你用相同的標準檢驗 其它宣稱支援ODF格式的辦公室套裝 其實都有類似的問題 因為根本沒有人規定OOXML跟ODF的支援要支援了什麼 才能稱自己有支援 就跟這個世界上沒有一個網頁瀏覽器 是100%支援W3C標準是同樣的意思 W3C只制定標準，但他可沒強制你一定100％ FLLOW 你應該把它看做是各家的渲染引擎對於語法的描述跟實作看法不同 如果真的那麼要求排版的正確性 你只有LaTeX這一個選擇

mso2007sp1以後的跟libreoffice相容佳？ 之前弄的office 2010好像還是gg
個人覺得w3c的誤差還在可容許範圍 如果真的有按照標準 ie當然就...
誤差很大那比閉源還糟糕 所以才認為它為了取得國際認證才假意的open
看來也的確只能靠latex...

MSO 2007 sp1 輸出的 ODF 真的相容超爛不是我在講，自己親手試驗即證。

個人認為微軟說的「相容某某」「支援某某」，只要不是自家專用的格式或功能（可以解讀為只要是他家公開的格式或功能），都要打點折扣。供大家參考個人經驗。

Jamespanda 寫到：
mso2007sp1以後的跟libreoffice相容佳？ 之前弄的office 2010好像還是gg
個人覺得w3c的誤差還在可容許範圍 如果真的有按照標準 ie當然就...
誤差很大那比閉源還糟糕 所以才認為它為了取得國際認證才假意的open
看來也的確隻能靠latex...

這樣要驗證也不難啊
你把有問題的OOXML檔
解開還原成XML原始檔
你看裡面是不是有屬於binrary而無法反解的組成
還是都是能以純文字呈現的方式閱讀？
然後再看看哪些標籤還是元素
是OOXML開放規格沒有提到的部份
就知道MS有沒有搞黑箱了
如果全部都是有公開的部份
那就是排版引擎RENDER的問題
你應該提BUG上報
而不是就是一定都是XXX或XXX暗弟裡搞鬼

我自己在公司不論是用windows或linux
都是用AOO.o編輯ODF或OOXML文件
給其它用MSO2010或2016的人
我們公司員工好幾百人，好像隻有我一個人在用AOO.o
至今沒有人跟我說過我交出去的文件有什麼相容性上的問題
因為我們公司每一個人的電腦都會有一套MSO授權
如果我自己心裡有疑問
自己打開來看看就知道了
不過我不會否認兩者間存在相容性問題
因為這些本來就是沒有最好，隻有更好

zerng07 寫到：
MSO 2007 sp1 輸出的 ODF 真的相容超爛不是我在講，自己親手試驗即證。

個人認為微軟說的「相容某某」「支援某某」，只要不是自家專用的格式或功能（可以解讀為只要是他家公開的格式或功能），都要打點折扣。供大家參考個人經驗。

這部份倒是沒有錯啊
因為MS本來就沒有說MSO2007可以完美支援ODF
都明確的告訴你是有限的支援了

2007年MS根本沒有理由要發展ODF
MS當年是為了移除眾人懷疑他們會
操縱OOXML以及惡搞ODF的疑慮
才覺得必須好好認真在相容ODF這一塊好好發展
因為你連ODF支援都做不好
那別人幹嘛要支援你的OOXML？
所以這是有目的性急策略性的支援
而且如果真這樣搞，那只不過是另一個DOC
成為一個公開，卻沒人跟的假標準
這不是ｍｓ要得，所以他們必須支援ODF
不然你覺得他們憑什麼讓ISO制定OOXML為開放文件標準？

而..
當年最早的MSO2007連OOXML 1.0都不支援
只能有限度的支援OOXML 0.x
因為開發MSO2007的時候根本就還沒有OOXML 1.0
連會不會成為ISO標準都充滿不確定性了

這樣要驗證也不難啊 你把有問題的OOXML檔 解開還原成XML原始檔 你看裡面是不是有屬於binrary而無法反解的組成 還是都是能以純文字呈現的方式閱讀？ 然後再看看哪些標籤還是元素 是OOXML開放規格沒有提到的部份 就知道MS有沒有搞黑箱了 如果全部都是有公開的部份 那就是排版引擎RENDER的問題 你應該提BUG上報 而不是就是一定都是XXX或XXX暗弟裡搞鬼 我自己在公司不論是用windows或linux 都是用AOO.o編輯ODF或OOXML文件 給其它用MSO2010或2016的人 我們公司員工好幾百人，好像隻有我一個人在用AOO.o 至今沒有人跟我說過我交出去的文件有什麼相容性上的問題 因為我們公司每一個人的電腦都會有一套MSO授權 如果我自己心裡有疑問 自己打開來看看就知道了 不過我不會否認兩者間存在相容性問題 因為這些本來就是沒有最好，隻有更好

我知道他的文件是可解析的 但就上網查詢 它的代碼在開源下不見得能夠渲染如一 尤其某些組件
採用特殊的解析工具 自己測試也是感覺如此 如果沒有相容問題 那只能說文件格式比較簡單
我是遇到不少問題 如pptx的各種版本(2010 2013)在ms office上讀取是很有問題的
libreoffice儲存為pptx 結果mso2010上說是2013的檔案
而不同系統上跑libreoffice效果是不一的 我是不清楚AOO的相容 但應該跟libreoffice差不多

Jamespanda 寫到：
我知道他的文件是可解析的 但就上網查詢 它的代碼在開源下不見得能夠渲染如一 尤其某些組件
採用特殊的解析工具 自己測試也是感覺如此 如果沒有相容問題 那隻能說文件格式比較簡單
我是遇到不少問題 如pptx的各種版本(2010 2013)在ms office上讀取是很有問題的
libreoffice儲存為pptx 結果mso2010上說是2013的檔案
而不同係統上跑libreoffice效果是不一的 我是不清楚AOO的相容 但應該跟libreoffice差不多

這個問題的原因有的時候很複雜
因為就連一堆自由軟體的辦公室套件也有ODF相容問題
http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet-interoperability.html#links
這個blog的作者是以前IBM Lotus的設計師之一
是我以前很喜歡看的一個blog
除了我貼的這篇，還有很多很有用的資訊
因為他既不是OO.o也不是LibreOffice人員
主要都是著重在OOXML跟ODF格式方面的問題探討

早期的OO.o還有ODF都是掌握在SUN手中
如今SUN已被甲骨文併吞，甲骨文對office suite並不感興趣
ODF的主要主導看起來貌似在AOO.o上
但它實則已經沒有什麼影響力，隻是保留這個傳統名號
這一兩年，更多開發者也回歸Libreoffice
其實這裡我用"回歸"這個詞意是比較奇怪的
因為技術上來說，他們本來就是在最初的那個OO.o團隊
隻是有更多原本的開發者跳槽到LibreOffice
所以原先選擇留下的人，陸續回歸到那個"原本"的團隊

事實上我沒有去查LibreOffice預設儲存的OOXML是第幾版
或許等我下班可以來查一下
不過我發現LibreOffice/OO.o大約在六七年前或更早的時候
預設儲存的ODF已經是1.2版了，當年或許叫做ODF 1.1 expand
事實上，ODF 1.2一直到去年2015年的時候才通過製定成為ISO標準
而MSO一直到2016才真正支援ODF 1.2，所以看出問題了嗎？

目前的LibreOffice是預設儲存成ODF 1.2 expand
而這也有可能成為日後的ODF 1.3

表面上windows平台上似乎常見的隻有AOO.o跟LibreOffice
但在linux平台上卻有一卡車的基於ODF的辦公室套裝
例如一個以前我也很喜歡用的kOffice
而大部分的這些基於ODF的辦公室套裝
都是跟隨ISO標準，你很難看到預先支援未來格式這種事情
事實上這種預先支援未來格式，在網頁瀏覽器上卻很常見

另外還有一點
就是MSO跟Libreoffice他們的排版引擎在處理某些函數的時候
它們的方法大大不同，這會導致在不同編輯器開啟時導致相容性上的問題
但是這並未違反ODF規範，因為ODF本來就沒有規範排版引擎應該如何實作的部份
這個我個人是傾向於MS故意亂搞的有意為之
因為他的排版引擎，在處理很多元素時，作法原理上跟LibreOffice排版引擎是完全相反
我個人很少使用簡報的部份，但這類問題很常出現在試算表上

如果有這類相容性問題
我個人是建議可以排除MSO本身的ODF格式規範
試著用這個ODF SDK來做為ODF格式的編輯新增
http://odf-converter.sourceforge.net/download.html
不過我自己平常是不用MSO的，所以我其實也不清楚效果如何..

這個問題的原因有的時候很複雜 因為就連一堆自由軟體的辦公室套件也有ODF相容問題 http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet-interoperability.html#links 這個blog的作者是以前IBM Lotus的設計師之一 是我以前很喜歡看的一個blog 除了我貼的這篇，還有很多很有用的資訊 因為他既不是OO.o也不是LibreOffice人員 主要都是著重在OOXML跟ODF格式方面的問題探討 早期的OO.o還有ODF都是掌握在SUN手中 如今SUN已被甲骨文併吞，甲骨文對office suite並不感興趣 ODF的主要主導看起來貌似在AOO.o上 但它實則已經沒有什麼影響力，隻是保留這個傳統名號 這一兩年，更多開發者也回歸Libreoffice 其實這裡我用"回歸"這個詞意是比較奇怪的 因為技術上來說，他們本來就是在最初的那個OO.o團隊 隻是有更多原本的開發者跳槽到LibreOffice 所以原先選擇留下的人，陸續回歸到那個"原本"的團隊 事實上我沒有去查LibreOffice預設儲存的OOXML是第幾版 或許等我下班可以來查一下 不過我發現LibreOffice/OO.o大約在六七年前或更早的時候 預設儲存的ODF已經是1.2版了，當年或許叫做ODF 1.1 expand 事實上，ODF 1.2一直到去年2015年的時候才通過製定成為ISO標準 而MSO一直到2016才真正支援ODF 1.2，所以看出問題了嗎？ 目前的LibreOffice是預設儲存成ODF 1.2 expand 而這也有可能成為日後的ODF 1.3 表面上windows平台上似乎常見的隻有AOO.o跟LibreOffice 但在linux平台上卻有一卡車的基於ODF的辦公室套裝 例如一個以前我也很喜歡用的kOffice 而大部分的這些基於ODF的辦公室套裝 都是跟隨ISO標準，你很難看到預先支援未來格式這種事情 事實上這種預先支援未來格式，在網頁瀏覽器上卻很常見 另外還有一點 就是MSO跟Libreoffice他們的排版引擎在處理某些函數的時候 它們的方法大大不同，這會導致在不同編輯器開啟時導致相容性上的問題 但是這並未違反ODF規範，因為ODF本來就沒有規範排版引擎應該如何實作的部份 這個我個人是傾向於MS故意亂搞的有意為之 因為他的排版引擎，在處理很多元素時，作法原理上跟LibreOffice排版引擎是完全相反 我個人很少使用簡報的部份，但這類問題很常出現在試算表上 如果有這類相容性問題 我個人是建議可以排除MSO本身的ODF格式規範 試著用這個ODF SDK來做為ODF格式的編輯新增 http://odf-converter.sourceforge.net/download.html 不過我自己平常是不用MSO的，所以我其實也不清楚效果如何..

對於MSO上的ODF相容並不感興趣 畢竟在台灣這並不通用...
開源office上相容MSO問題這是很嚴重的 以上只是在證明MS很喜歡搞些假開源手段
表示要open就open 要close就close 模擬兩可的實在很討厭...
這也是我討厭MS的原因

Jamespanda 寫到：
對於MSO上的ODF相容並不感興趣 畢竟在台灣這並不通用...
開源office上相容MSO問題這是很嚴重的 以上只是在證明MS很喜歡搞些假開源手段
表示要open就open 要close就close 模擬兩可的實在很討厭...
這也是我討厭MS的原因

其實我的意思是MSO一樣可以儲存成ODF作為文件流通的方式

其實我的意思是MSO一樣可以儲存成ODF作為文件流通的方式

不可能要求別人也使用odf吧 這是問題點

Jamespanda 寫到：
不可能要求別人也使用odf吧 這是問題點

MSO如果你不要隨意轉換格式類型 如 ODF > OOXML 或反之
而如果是MSO自己流通的話，是不會有相容性問題

如果你只用Libreoffice，把預設儲存的類型改成ODF 1.1
就可以解決MSO 2016以下不支援ODF 1.2的問題
這點我其實前面有提過了