Running gcin on ezgo13 (kubuntu 16.04, qt5 問題)

雖然裝上了 gcin-qt5-immodule 但是發現 qt5 的程式一直都還是無法叫出 gcin

後來研究之後成功了
我的做法是：

1. 移除 fcitx (我不確定是否必要，但放多個輸入法在裡面反正是不會有好處) 並安裝 gcin，記得要安裝 gcin-qt5-immodule

2. 修改 /etc/default/im-config 中 IM_CONFIG_PREFERRED_RULE 把 fcitx 通通改成 gcin (我也不確定這個步驟是否必要)

3. 執行 im-config 選擇預設 default

5. 重點：/usr/share/im-config/data/26_gcin.rc 中，在 QT4_IM_MODULE=xim 下面加上一行

QT5_IM_MODULE=xim

重新登入，搞定！

不過我發現重新開機之後 KDE 第一次會無法登入，卡在 splash ，要切到 console 去重啟 sddm 才能順利登入。後來再爬了一下文，修改 /usr/bin/startkde 中
有一個決定 $qdbus 的地方，在 else 的地方
qdbus=qdbus 改成 qdbus="qdbus -qt=5"

至少剛剛重新開機有順利登入了！

pptpd server on debian

在 debian 設定 pptpd server 時，要注意除了 port 1723 要開之外，protocol gre 也要打開。

OOXML / 微軟舊封閉格式轉成 ODF -- 為何不要用微軟的 Office 來做這件事？

雖然國發會的說明會投影片中告訴大家微軟也支援 ODF，但是就幾個手上的例子，還有我跟國際社群實際接觸觀察到的現象，在此分享給大家。

先說結論：想要將微軟格式轉成 ODF，最好還是用新一點版本的 LibreOffice (5.1.x, 5.2, 5.3...) 轉出來的結果成功率較高。不要用微軟的 Office 來另存新檔。

進入正題：

1. 大約半年多前，我請目前台灣 ODF 第一把交椅的講師幫我用微軟 Office 2010，將幾個簡單到略微複雜的微軟 docx/pptx/xlsx 另存成 ODF 檔給我測試。不過當時因為國發會想要找到的是一個可以驗證 ODF 格式合法性的工具，所以我拿到這些檔案的主要目的是要測試這個：

https://odf-validator.rhcloud.com/

我拿這兩者做對照實驗：

第一組：講師給我的微軟 Office 原檔與直接另存新檔產生的 ODF 檔

https://goo.gl/qAGYlP

第二組：2016 年宜蘭縣政府 ODF 教育訓練公開招標文件，這時經過去年我們對宜蘭縣政府一年的教育訓練與工作導入輔導後，他們直接採用 LibreOffice 產生的 ODF 檔

https://goo.gl/y3vHxL

測試方式：選擇 ODF 1.2 Extended conformance 並開起 Log verbose

結果：

第二組中，LibreOffice 直接產生的 6 個檔裡有一個未通過。我以此發了一個 bug issue:

https://bugs.documentfoundation.org/show_bug.cgi?id=98520

測試結果：https://goo.gl/TH80vM

而第一組中，微軟 OffiCe 存成的 ODF 則全軍覆沒，沒有一個檔案通過。
（測試結果附在壓縮檔裡）

另外有興趣的朋友可以自己用微軟 2010 或 2013 來試試看。直接拿微軟開啟微軟自己產生的 ODF，跟拿 LibreOffice 開啟微軟產生的 ODF ，結果是否有所不同。我自己沒有微軟的 Office，所以沒做過這方面測試。但講師測過，結果相信也不需要我多說。

2. 去年九月微軟台灣葉光釗技術長在 COSA 舉辦的開放系統論壇上親自承認微軟存成 ODF 時有加料。我人在現場，也有懂這方面的社群朋友在場。雖然他的投影片裡並沒有放這部份，而是只講到這裡：

(來源： http://www.cosa.org.tw/images/104OSS/04-%E8%91%89%E5%85%89%E9%87%97MS%20ODF%20Overview.pdf )

實際上 ODF 並非 "provides no extensibility mechanism". 它們有一套流程，在你使用 extension 後必須與 OASIS 申請，經由數道程序的討論後，進入 ODF 標準中。這裡是 LibreOffice 目前所使用的所有 extension：

https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_Extensions

舉一個比較新的例子，大家可以搜尋 Core commit 9c2a80，對此 issue 經過一番討論之後，最後投票決定接受為 RESOLVED 並進入 ODF 1.3。

至於微軟有沒有遵循這個規範？

我剪一小段我跟另一位 LibreOffice 核心開發者，也是這次推動英國政府以 ODF / LibreOffice (GovOffice) 為規範的推手 Michael Meeks 跟我的一小段對話。因為英國政府曾經下令要求微軟儲存 ODF 時必須遵循英國政府所使用的 ODF 規範（含 extension），而：

Me: (And I'm very curious, do Microsoft *really* obey this list and export only the extensions list here?)

Michael: Certainly not =)

3. ODF Committee 成員 Jos van den Oever，也是荷蘭政府在 ODF Committee 的代表，跟我討論今年 ODF Plugfest 時說，微軟每年都會參加 plugfest，但從未下海做過任何測試。

這封信的部份原文（前面是關於我參加今年 ODF plugfest 的事）如下：

At the plugfest we usually have a talks part and a testing part. At thelast plugfest we wrote a long report with interoperabilty issues [1]. Weappreciate if attendees contribute tests. You can send them to mebeforehand and I'll make sure the issues will be discussed.Ideally, we'll run the issues through our testing system. If you havesoftware which you want to have hooked up into that let me know.If you join, it would be great to have talk by you of about 20 minutesabout the status in Taiwan. 

Microsoft employees have attended a few times but usually do not join inthe the technical part and neither do employees from Apple or Google.This is a clear message from them that they do not care aboutinteropability. 

Microsoft does attend the weekly ODF standardization teleconference.They are usually simply observing. You are right to advise people to notuse MS Office for ODF. Google Docs is even worse.

再拿葉技術長的投影片來打臉一下：

可知他們對所謂的 "主動舉辦和參與 ODF interoperability" 是怎麼一回事情。

其實我在所有我所主講的說明會場合都說得很清楚，撇開預算問題不談，只要微軟能確實遵循 ODF 1.2 規範，儲存成的 ODF 檔不會造成其他軟體讀取與編輯的困擾，那麼大家使用微軟另存 ODF 是沒有關係的。這是最理想的狀況，只是目前微軟並未採取此一友善政策。

所以，目前為止，還是請大家如果有轉檔需求，請直接使用 LibreOffice（新版的當然表現會比舊版好一點），而不要採用微軟 Office 另存新檔成 ODF 的方式。