IanHo 寫到：
提供另一個思考方向：
Apache openoffice和所有以AOO為基礎再延伸開發的
泛openoffice發行版本，對於MsOffice的支援不盡完美，
這個情境叫做"理所當然"。若有高百分比的支援(非百分之百)，
這個情境叫做"運氣好"。
除非，Apache openoffice和其泛openoffice發行版本
的開發團隊或公司，花錢，跟微軟買技術授權，
那麼就有機會達到百分九十九的相容性。
"以前"好像有一個novell的openoffice發行版，
"聽說"就是相容性性很高的版本？不過好像就沒有再繼續改版了？
想要"完整的/零問題的"編製MsOffice格式的檔案，
請回歸使用MsOffice。

Novell支援的OpenOffice好像就是LibreOffice，找到這篇：http://www.openfoundry.org/foss-news/8279

RUSIA 寫到：

IanHo 寫到：
提供另一個思考方向：
Apache openoffice和所有以AOO為基礎再延伸開發的
泛openoffice發行版本，對於MsOffice的支援不盡完美，
這個情境叫做"理所當然"。若有高百分比的支援(非百分之百)，
這個情境叫做"運氣好"。
除非，Apache openoffice和其泛openoffice發行版本
的開發團隊或公司，花錢，跟微軟買技術授權，
那麼就有機會達到百分九十九的相容性。
"以前"好像有一個novell的openoffice發行版，
"聽說"就是相容性性很高的版本？不過好像就沒有再繼續改版了？
想要"完整的/零問題的"編製MsOffice格式的檔案，
請回歸使用MsOffice。

Novell支援的OpenOffice好像就是LibreOffice，找到這篇：http://www.openfoundry.org/foss-news/8279

應該是會錯意了，我提的是更古早的版本，現在應該是找不到了？
例如：
OpenOffice.org Novell Edition for Windows
https://www.novell.com/communities/coolsolutions/available-now-openofficeorg-novell-edition-windows/

補充：
我會有這樣一個想法，微軟公司送規範到ISO組織是一回事，
微軟的文書套裝軟體的排版引擎怎麼解析檔案和怎麼生成檔案，
可以又是另一回事。使用微軟的文書套裝軟體所生成的文件檔，
有沒有百分之百符合微軟公司送到ISO組織的那些文件規範，
可以是第三回事。這三回事之間或許就有許多可以玩味的地方了？

已經是舊文了．．．
http://tech.qq.com/a/20070822/000203.htm
http://tech.sina.com.cn/it/2008-04-23/08242155744.shtml

OOXML規格推出時微軟自己的Office 2007實作都沒有完整符合它自己定的標準
貌似2010之後有符合

一樣的標準Render出來的結果不同還滿常見的

同樣一套HTML規格在不同瀏覽器上看起來不太一樣如是
同樣一套C、C++程式語言公開規範，每家編譯器編好執行檔的組合語言也不相同亦如是

如果Render可以完全相同，才是不正常、應該要懷疑是否source code都被搬過去了
規格和實作是兩回事，一套複雜規範在不參考別人實作的情況下可以做到完全相同，比零bug還困難啊

ＵＧＰ 寫到：
已經是舊文了．．．
http://tech.qq.com/a/20070822/000203.htm
http://tech.sina.com.cn/it/2008-04-23/08242155744.shtml

OOXML規格推出時微軟自己的Office 2007實作都沒有完整符合它自己定的標準
貌似2010之後有符合

一樣的標準Render出來的結果不同還滿常見的

同樣一套HTML規格在不同瀏覽器上看起來不太一樣如是
同樣一套C、C++程式語言公開規範，每家編譯器編好執行檔的組合語言也不相同亦如是

如果Render可以完全相同，才是不正常、應該要懷疑是否source code都被搬過去了
規格和實作是兩回事，一套複雜規範在不參考別人實作的情況下可以做到完全相同，比零bug還困難啊

嗯，這讓我想到幾個重點：
1.複雜到達一定程度的標準最終技術上會無法實作，這是必然的嗎，合理嗎？
現有的W3C標準還不夠複雜？或者已複雜到接近無法統一Render的結果？
我想「標準」在一定程度上是可以給予空間彈性讓APP自由發揮才對，例如我說建立一個論壇，完全沒提到論壇的配色、版面、字型等細節規範，那麼我只要建立一個符合最低限度「論壇」定義其它的就可以自行發揮，充份展現軟體設計工藝，這樣看來是好事，但反過來說，如果這規範不清的部份，會影響到使用，例如3頁的文檔變成5頁…嗯，是蠻有個性的，在我的國家它本來就是一份5頁的文檔，印成3頁不覺得太擁擠了嗎？嗯，好像合理，一套規範各自表述，但若這已造成使用者困擾，而各實作方案又沒有「違規」，是不是應該檢討是不是規範定的不夠嚴謹？因為結果與期待不符一定是這兩者之一有了缺失—規範不清楚或沒按照規範實作。

2.承1，規範如何成為「標準」了？這讓我想到前陣子食用油等類似的事件，已通過標準檢驗不見得「標準」？（或者該說「安全」？），與其說通過標準不如說通過「標準檢驗」更來的貼切，因為「標準」也只能依照一定的項目檢驗，若要做到百分之百的檢驗，可能跟重新設計一套標準差不多一樣複雜；有過寫程式經驗的應該能體會，要完全看懂別人的程式跟自己重新寫一套同功能的程式差不多複雜，當然更不用說還要從中找出錯誤了，那更非得完全看懂每一個細節不可。

3.回應「同樣一套C、C++程式語言公開規範，每家編譯器編好執行檔的組合語言也不相同」，編譯出來結果不同我想那是必然的，因為重點是執行結果，如何編譯才能產生更好的執行效率，結果又相符，所以重點應該放在「執行結果是否相符」而不是「編譯出相同的機械語言」，因為如何編譯出更有效率的機械語言這就是各家編譯器要角力的重點啊，光gcc自己就有「-O0 -O1 -O2 -O3 -Os」各種不同層級的優化組合，不同的編譯方式就會大大的影響到執行效率，當然還是必須以相同的執行結果為前提下去優化，程式作者會考慮實際需求，為求可靠，不見得選擇效率最高的執行方式。

RUSIA 寫到：
嗯，這讓我想到幾個重點：

你提到的這些，我想XXoffice的開發人員應該和你一樣希望達到這樣的理想，沒有作出來一定是因為有它的困難度吧！
當然如你所說技術規範還是可以更加精進完備，但是如何改進也要有具體想法才值得討論，討論的地方應該也要在開發人員論壇裡討論。
在這裡抱怨根本沒有效果，一不小心還會被人誤解為惡意批評。