我在幾天前發現了一篇部落格文章提及 ODF 的字型設定方面與 OOXML 的差異：
作者在對比以後認為這是 ODF 的一大缺陷，況且 ODF 是 LibreOffice Writer 預設的檔案格式，不知道大家讀了以後有何高見？
我不覺得這是所謂 ODF 的缺陷耶。
從他貼的片段剛好符合去年 Italo Vignoli 在台演講時所提到的（可以參考這一篇：http://technews.tw/2017/08/16/the-big-secret-of-ooxml/ ）
ODF 中段落就是段落，它沒有把段落拆分成一個個的字或符號
而 OOXML 中把段落拆分（但從本例好像又看不太出什麼規則），或許有它的用意，但對要處理或產生 raw data 的資訊系統來說應該會很痛苦。
他所提到的問題明顯是 rendering 的實作部份，而不是格式。全形半形英文數字的判別，也不是由 ODF 而是由軟體來做。
另外，他用的是這個符號「 “ 」，這是西方文字的用法吧。我不太知道 CJK 使用者會不會常用到這個符號。
如果你前後引號用的是一般的「 " 」，或甚至中文習慣的「 」，則根本就沒有他說的問題存在了。
我查了一下維基百科，這種西方文字的前後引號也在簡體中文裏面使用，但是我還發現這在簡中字型檔裏面往往都是全形的，這或許是問題的關鍵。
另外我看了部落格以後，感覺「·」這個符號也受到了影響，比如在「喬治·W·布什」裏面。如果確實是這樣的話，那恐怕需要在 Writer 裏面創建一個算法來解決這個問題了。
實際試試就知道了。
·布什
:·布什
‧布什
:‧布什
在 Writer 裡都是正確的。
我仍然不認為這是 ODF 使用段落為區隔的做法造成的。照你的說法，反而可能是因為原本半形的字體在簡中環境下被顯示成全形的關係。
我試了一下，在 Writer 裏面可以複現，不過我在粘貼之前先替換成了 U+2027。
不知道 ODF 是否允許為整個文件設定語言，如果可以的話，那就容易實作，否則就有些困難。
我發現已經有人發了兩份相關的 bug report，不過看起來一直都是懸而未決。
https://bugs.documentfoundation.org/show_bug.cgi?id=66791
https://bugs.documentfoundation.org/show_bug.cgi?id=127491
不過我聽說文件基金會準備在 LibreOffice 中支援 ODF 1.3，不知道能不能找到辦法解決。
Tender for consultancy on implementing ODF 1.3 conformance in LibreOffice (#201911-01) - The Document Foundation Blog
是的，目前招標中，順利的話預計 LibreOffice 7.0 開始就會支援 ODF 1.3。
我看到 LibreOffice 7.0 已經有支援 ODF 1.3 了，不知上面那些 bug 還能否復現，如果問題依然存在，不知您是否還有更好的解決方案。
目前我所看到的：
- ODF 1.3 主要是解決 ODF 1.2 已知的問題，再來就是加入開發者在這幾年中開發出來的 延伸功能。
- ODF 1.2 在 LibreOffice 實作上的問題，會在 7.0 之後做一次清理。但就我所知上面兩者並未包括在內。
- 這部份應該還是需要 CJK 開發者在開發論壇或 irc 提出討論，（我目前看起來跟 ODF 本身無關，比較傾向是實作問題）。
噢，這個問題已經有人在討論了。我無意中發現一個論壇就在反饋這個，裏面有人抱怨「報告6年一直沒解決」，須要關閉本地化選項，不知您有何高見？
https://bbs.libreofficechina.org/forum.php?mod=viewthread&tid=2301
就我上一個回覆裡所說的，這一類問題本來就需要本地的開發者來投入啊。目前亞洲區的開發者很少，投入在 CJK 相關問題的也就幾位，需要有人願意投入研究，跟其他開發者討論（也許本來這樣設計是有其他作用，或是我們改了會有其他新的問題與 regression 產生）。
我看到 bug 134350 也在反饋這問題。開發者說他們在用 ICU 函式庫在詞界改變文本語言，但是他們不知道應該是針對特定字元匹配字型，還是改變閉詞界限。然後最後一個回復提出的是通過改變閉詞界限的方式解決。不知道您對此有什麼高見，可否找到辦法修復這個問題？