威注音的幾個產品目標:
幾乎都是在做上游缺失的功能、修上游不修的 Bug:
本專案採用 MIT-NTL License 釋出,使用者可自由使用、散播本軟體,惟散播時必須保持軟體完整、不得修改版權文字。如若在此基礎上做出修改版軟體的話,除非威注音專案書面允許,否則請勿使用威注音(vChewing)的產品名稱。詳細資料請洽程式碼倉庫內的各種 Markdown 說明檔案(包含部分不在本頁面列出的 FAQ 常見問題解答)。
請參見《如何卸除威注音輸入法》一文。必要情況下,你可以持該文章向 Apple Support 求助。
更進階的常見問題解答可參見: GitHub § Gitee。
這裡分別解答一下:
威注音的圖示「ㄋ」取自 Komica 糟糕島流行的與劉寶傑有關的梗「貼ㄋㄟㄋㄟ救寶傑」。
因為安裝包內的輸入法主程式包含了針對 macOS 10.13 專用的 Swift 5 Runtime,且這套 Runtime 只有 Intel 版本。只要 pkg 安裝包當中有了這種純 Intel 的東西,macOS 就會主動要求使用者安裝 Rosetta。如果系統允許您跳過對 Rosetta 的安裝的話,您不安裝 Rosetta 也無妨,因為 macOS 11 開始的系統根本用不到 Swift 5 Runtime。
該故障並非發生於所有 mac 機種。兩點原因可導致該故障:
有個方法可以避開該故障:就是開啟輸入法偏好設定當中的鍵盤設定畫面,將基礎鍵盤佈局改成 ABC。
如果您的系統版本不滿 macOS 10.13 的話,系統內沒有 ABC 佈局,此時輸入法會允許您啟用 US 美規鍵盤佈局。
然而,這個故障無解。其背後的原因在於:諸如 SmartGit 這樣用 Java 等第三方方案寫的跨平台軟體,往往無法正確處理藉由 macOS 內建的「非英數類」鍵盤佈局傳入的 CMD+Z/X/C/V 組合熱鍵。打比方說 macOS 內建的大千注音鍵盤佈局,就會被這類軟體認成「CMD+ㄈ/ㄌ/ㄏ/ㄒ」。Apple 又沒有任何官方開發指引明令訓誡第三方軟體研發者「得做出針對這種情況的相容處理」,就很讓人既憤怒又無奈。
對於任何副廠輸入法,在遇到這個問題的時候,都請聯絡 Apple Support。這是「macOS 剛剛安裝完畢之後在 OOBE 開箱階段選擇了(包括中文在內的)某些介面語言之後、會自動開啟的某個特性」所致,但他們沒有想到「應該對第三方輸入法禁用該特性」,所以只能讓 Apple 的服務專員手把手教您怎樣關掉該特性。
威注音鼓勵每一位受此困擾的人向 Apple Support 求助,或者帶著您的電腦去 Apple Store 直營店求助。求助的人越多,Apple 也就越知道:這個預設啟用的選項給使用者帶來的更可能是困擾、而不是他們最開始的良性目的。
更新:威注音輸入法 3.4.8 版開始,找到了方法:將「敲兩下空格」取代成的字符由「一個全形空格」變成「兩個半形空格」,從而讓 macOS 的這一處綁架設計對威注音徒勞。是說 Apple 應該在 Xcode Documentation 當中將一款輸入法的 info.plist 的參數涵義盡數解釋出來、而不是什麼都不寫。如果有其它第三方輸入法也想實作這種對策的話,請將輸入法的 info.plist 當中的 TISDoubleSpaceSubstitution
這一項的參數值改為 ` `,也就是兩個西文半形空格。為什麼不砍掉這一項呢?因為你可能沒那個成本去測試這一項在每個 macOS 版本下的預設行為。
請摁 Ctrl+Command+Shift+P 來啟用ㄅ半模式。這在威注音當中被稱為「逐字選字模式」。
這裡僅討論威注音輸入法 3.6.1 版開始的情況,且僅建議您盡可能使用新版本的威注音輸入法。
威注音這邊沒有直接集成使用過「小麥注音的」候選字順序,而是使用了對ㄅ半輸入法使用者而言更具肌肉記憶之意義的「倚天中文 DOS 候選字排序」。該排序僅對逐字選字模式有效。
因為ㄅ半輸入法的使用者群體不太會再去適應新的排序,所以威注音輸入法從 3.6.1 版開始移除了對ㄅ半輸入法的候選字排序自訂功能。
至於小麥注音與 OpenVanilla 香草輸入法用的排序是不是也是倚天中文 DOS 排序,請自行詢問對應的輸入法團隊(雖然有一些現任成員是重複的)。
請在系統偏好設定內新增「威注音-簡」這個輸入法。只要系統內有安裝了威注音輸入法,就應該能在簡體中文輸入法分類下找到該輸入法。為什麼不像其它有些輸入法那樣直接做熱鍵開關呢?因為他們那樣無法做到在簡體輸出時讓 macOS 聽寫的內容「也是簡體中文」。
威注音不信任繁簡轉換與簡繁轉換,因為必然會有轉換錯誤發生。威注音的簡體中文模式使用單獨的原廠辭典、與繁體中文模式的辭典分隔開。然而,每次在新增使用者辭典時,威注音都會往另一個繁簡模式的使用者辭典內添入轉換過的結果。因轉換過的結果的正確性無法保證,所以任何轉換結果的所在行都會有行尾標記。
自 v3.4.7 版開始,威注音的繁簡切換熱鍵是 Ctrl+Command+Shift+D。更舊版的威注音輸入法沒有專門的繁簡切換熱鍵。
威注音只是允許輸入這些符號而已。至於這些符號怎樣顯示,則可能需要您系統內有安裝對應的字型。
打比方說「音樂」這個符號分類,就需要您安裝 SMuFL 標準的樂譜排版字型。如果您有安裝過 Steinberg Dorico 的話,您系統內應該已經有安裝 Bravura 這款字型。您也可以安裝 MakeMusic 出品的 Finale Maestro SMuFL 字型。
另外,「注音」符號分類下,可能會有至少四個缺字,需要您安裝任何可以支援粵語注音標準的字型(比如 NotoUnicode 或者 一點明體 I.Ming 都可以)。
此外,macOS 內建的字型對某些統一碼字元的顯示支援也會隨著 macOS 版本的不同而有異動。
田所選字窗現在已經支援這種多行橫版派列了。嚴格來講,這不是陣列排列,因為每一行的候選字數量的多寡取決於這一行的總體的繪製長度。
題外話:威注音輸入法已經自 3.5.4 版開始已經移除 IMK 選字窗。
筆者不推薦使用舊版本威注音輸入法。以下內容是針對 3.5.3 版為止的威注音輸入法的解釋:
您可能想說的是 IMK 選字窗,您可以在開發道場內啟用。該功能現階段僅在 macOS 10.14 Mojave 至 macOS 13.x Ventura 系統下測試過可用性。
IMK 選字窗是 macOS 內建的 InputMethodKit 輸入法開發套裝模組當中的 IMKCandidates 子模組所實現的東西。然而,IMKCandidates 在這十幾年以來一直都是沒有經過單元測試考驗過的爛貨、是能將賈伯斯氣得從棺材裡爬出來的殘次品。如果這個模組的研發團隊有設計過單元測試的話,他們自己明明就可以發現這些低級智障問題。但他們選擇了裝鴕鳥,給系統內建的輸入法用了一個 IMKCandidates 的克隆版本、僅供 Apple 內部使用(感興趣的話可以自行對 InputMethodKit 逆向工程)。至於給副廠輸入法開發者使用的 IMKCandidates 再怎樣殘障,他們這十幾年來一直都沒有在管。
由於 IMK 橫版陣列型選字窗的功能特性獨此一家,使得第三方輸入法開發者想在功能方面「複製體驗」簡直難比登天。迄今為止對此操作體驗複製得最接近的是 macOS 版微信鍵盤,但在選字窗內容非常多的時候會出現操作遲鈍的情況;其次是是搜狗拼音輸入法,但在使用體驗角度來看仍舊遠遠落後於 IMK 橫版陣列選字窗。
威注音輸入法自 v1.9.2 版開始,在偏好設定內引入了專門用來提供「出了錯誤不負責」的名為「開發道場」的實驗田,且在其中集成了威注音的 IMK 選字窗模式的開關、允許使用者在 IMK 選字窗與迄今為止的 Voltaire MK3 選字窗之間來回切換。之後,威注音輸入法在 v2.0.0 SP2 版當中將這個選字窗做得幾乎接近於能用的狀態。可以[點此閱讀使用說明](/manual/shortcuts.html)。然而,該選字窗仍舊至少有下述功能無法實現(詳見 v2.0.0 SP2 的發行日誌):
- Home / End 鍵不起作用。
- 在對應的漢字轉換模式或辭典簡繁模式下,選字窗內的字型無法出現對應的變化(比如給簡體模式使用「蘋方-簡」)等。
- 在縱排書寫模式下敲字時,選字窗會蓋住當前正在輸入的縱行。
結論:很多使用者都希望能在自己喜歡的副廠輸入法內用上 IMK 的矩陣選字窗(就是 macOS 系統內建的注音輸入法的橫版矩陣選字窗)。然而,經過這些天的研究,威注音輸入法團隊不得不認清(目前能推斷出來的)唯一可能事實:IMK 選字窗充其量也只是 Apple 用來滿足自家輸入法需求的產品部件、一開始就沒有讓副廠輸入法廠商用得爽的打算。第三方輸入法開發者們想要將 IMK 選字窗實作到企業級堪用的地步的話,往往需要使用私有 API 等強硬手段、也不見得就一定能做到這個地步。如果你們有誰認識在 Apple 的人的話,請他們關注 Bug Report #FB11300759,這樣 Apple 或許能稍微重視一下這些問題。至少,就 IMK 選字窗的功能實作而言,威注音已竭己所能。
另:從威注音輸入法 v3.3.9 版開始,當在未來某個 macOS 系統下因為執行了「被強制曝露的私有 API」而崩潰的話,會觸發威注音的選字窗安全保護機制,IMK 選字窗會因此自動停用。這樣一來,在作者釐清狀況做出應對之前,不會耽誤使用者正常使用威注音輸入法。
威注音自 2.8.7 版開始升級了 Apple 動態鍵盤佈局翻譯引擎。從這一版開始,只需要注意:
自威注音輸入法 v3.6.3 版起,威注音允許使用者使用終端機將當前輸入法偏好設定的絕大多數內容傾印成一份備份檔案。該備份檔案的實質是 Shell 腳本、需要在終端機內使用 pipeline 語句來指定寫到哪個新檔案當中(否則只會在終端機螢幕上顯示一遍腳本內容)。只需要將該腳本直接在終端機內運行、就可以將該檔案內的輸入法偏好設定恢復到電腦當中。命令用法參考範例:
~/Library/Input\ Methods/vChewing.app/Contents/MacOS/vChewing --dump-prefs > ~/Downloads/vChewingPrefBackup.sh
需要注意的事項有:
威注音 2.6.0 版開始,對這種不遵守 IMKTextInput 協定的應用,會啟用獨立的浮動組字窗(讀音數量上限 20)。
威注音會預設對 Steam 啟用該措施。如果想對其它應用採取該措施的話,請在輸入法選單當中的「管理客體應用」內添入這些應用(的唯一標幟「bundle identifier」)。
偏好設定內有相關設定,要求威注音版本至少 v1.9.0 SP1。
威注音鼓勵使用鍵盤右側的 Shift 直接切換至英數輸入模式。
如果您在用的基礎鍵盤佈局是「Apple 倚天傳統」或者「Apple 大千傳統」的話,還可以這樣:
請更新至至少 1.8.7 版。如果還有問題的話,請用下述的捕捉故障重現的方法抓取儀器資料、再用電郵提報過來,這邊會據此檢查故障原因。
每次輸入法閃退的時候,應該都會在系統內留下錯誤報告。請檢查下述目錄(包含子目錄)是否包含以「vChewing-案發日期年-月-日-案發時間戳.ips」命名的檔案:
/Users/你的使用者名稱/Library/Logs/DiagnosticReports
如果有的話,請將這些 ips 檔案打包電郵寄過來供偵錯所用,雖然用這個途徑抓到的資料(相比用儀器捉蟲而言)並不太便於偵錯就是了。
分這幾種情況:
如果您在用威注音 v3.4.8 開始的版本的話,您可以嘗試使用劉氏注音排列。
那是威注音輸入法的自動格式整理標記,正常情況下可以不用理會。如果遇到辭典檔案內容無法正常生效的情況的話,請砍掉這一行 Pragma Header 且存檔,此時輸入法會自動重新整理格式、且會在此之後補回這一行。
當且僅當組字區內沒有內容的情況下,摁 Shift+Space 可以連續輸入全形空格。該功能要求威注音版本至少 v1.8.4。
標點符號小鍵盤的功能沒有製作,因為製作成本與功能易用性回報相比實在不值得。請善用波浪符號選單,能提供與新酷音輸入法的波浪符號鍵選單近乎一致的體驗。如果將新酷音的 symbols.dat 放入使用者辭典目錄的話,則波浪鍵選單的內容會與新酷音完全一致。如果想用類似於小麥注音的符號選單的話,請摁「Option+波浪符號鍵」。如果您用的是 JIS 鍵盤的話,因為 JIS 鍵盤沒有波浪鍵,所以威注音會改認位於右手 SHIFT 鍵左側的「_」鍵作為符號鍵、以取代波浪符號鍵。
威注音 v1.8.8 版開始支援使用鍵盤右側的 Shift 鍵切換中英文,但僅支援 macOS 10.15 Catalina 及之後的 macOS 版本。至於左側 Shift 鍵其實也可以,前提是你在偏好設定內有啟用(預設啟用)。
威注音的「Shift 按鍵切換功能」承襲自 Qwertyyb 的業火五筆輸入法(MIT 授權),不依賴任何 macOS 系統進階權限,也就不會有對系統全局鍵盤事件的監聽行為與需求,請各大公司的資安主管們放心:反正你們也可以自己拿威注音的原始碼倉庫自行 build 自己的 binary 給自己公司員工的電腦使用。
有些 macOS 使用者的系統可能會有 CapsLock 反應遲鈍的問題,哪怕他們並沒有在系統偏好設定內的輔助選項當中啟用慢速按鍵。此時有兩個選擇:
根本原因是 JetBrains 的眾多 IDE 的設計使然(可能與他們對 JDK 的使用有關,我不懂 Java 就是了)。
至於為什麼 macOS 系統內建的注音輸入法不會誘發該問題,則是因為他們用了 Apple 自家的基礎鍵盤佈局(有著對應的螢幕鍵盤注音顯示支援)。與小麥注音不同的是,威注音可以藉由將輸入法偏好設定內的基礎鍵盤佈局改為「Apple 大千注音」「Apple 倚天傳統」來規避這個問題。
如果您在用許氏鍵盤等動態注音排列、導致您不得不使用 ABC 鍵盤佈局的話,唯有啟用系統偏好設定內「CapsLock / 中英鍵切換輸入法」的功能。如果你的電腦在使用「CapsLock / 中英鍵切換輸入法」的功能時出現時效延遲的話,請考慮安裝使用「CapsLockNoDelay」這款開源小軟體。
這與 Rayon 終端機應用內所用的終端機功能模組 xtermjs 有關、波及多款中文輸入法。該問題無解,唯有啟用系統偏好設定內「CapsLock / 中英鍵切換輸入法」的功能。如果你的電腦在使用「CapsLock / 中英鍵切換輸入法」的功能時出現時效延遲的話,請考慮安裝使用「CapsLockNoDelay」這款開源小軟體。
此乃上游的設計缺陷、被威注音繼承了下來(至 v1.9.3 版為止)。該設計缺陷波及市面上多款輸入法,詳見 GitHub 工單 #100。
威注音輸入法已於 v1.9.4 版修正了這個問題,請放心使用。然需注意:為了解決這個問題而引入的「先鞏固上下文、再覆寫節點」這種事前鞏固措施僅對「藉由選字窗的選字」有效。你用鍵盤熱鍵在組字區內就地輪替候選字時,不會有這種事前鞏固措施,因為有了的話會影響使用體驗。
預設的半衰記憶模組只有不到六天的有效記憶,且會有個別記憶觀測失效導致的「記不住」的情形。想要持久記憶的話,可以隨時用 SHIFT+前後方向鍵 來選中您想要手動記憶的詞彙、再摁 Enter 添入使用者辭典。
人家奇摩輸入法花大錢買 SinicaCorpus 的原始材料分析複元圖(ngram)詞頻資料來用,選字體驗當然比威注音目前只用單元圖(unigram)這樣要好了。
安裝的話,是沒辦法的事情,誰教 macOS 10-11 全版本的 pkg 安裝程式體系都有那種 bug。如果您在用 macOS 12 Monterey 及在此之後的系統的話,反而是最輕鬆的。至於 OpenVanilla 小麥注音那種安裝程式,自身還會再嵌入一份 Swift Runtime Library,會肥得很誇張。
卸載的話,只要你安裝過程沒問題,那麼卸載就不該有問題:摁住 Option 鍵的同時,點開輸入法選單圖示,就能看到卸除選項。有問題的話,輸入法 app bundle 內贈了可以在終端機內使用的卸載腳本,請參見上文。
威注音輸入法預設的選字窗可以修改選字鍵:在偏好設定的第二頁或者第四頁可以改(取決於你在用的 macOS 系統版本),輸入的選字鍵序列會被自動去重複、再做合規性判定。
偏好設定介面內的開發道場裡面的 IMK 選字窗是無法修改選字鍵的、且根本連預設的選字鍵都失效。因為 macOS 內建的 IMK 選字窗模組十幾年來都沒被修正的缺陷的存在,威注音的 IMK 選字窗無法實現這些功能。
請善用輸入法選單內的使用者語彙自訂功能。
這是威注音為了應對「有心人士蠱惑人心、散播與威注音在程式行為道德方面有關的不實謠言」的情況、而做出的進一步自我約束。不過威注音一開始就視使用者私隱為第一位,所以實際上也沒有差。
沙箱特性確實帶來了一些功能特性限制。詳情請洽 2.3.0 版的發行日誌。
請參照這篇文章的指引用電郵聯絡研發方。至於 GitHub 倉庫工單,則可能無法得到第一時間的受理。至於爛詞,雖然可以使用就地刪詞的功能屏蔽掉,但也歡迎提報。
有兩種情況。無論哪種情況,都可以藉由升級至至少 2.6.2 版來解決。
一、自威注音 2.5.0 版開始引入的全新的 FolderMonitor 模組(用來監視使用者辭典目錄的內容變化,以便就地重新載入)在嘗試監視的目錄不存在的時候被啟動的話,會崩潰掉輸入法。之前 Zonble 的 FSEventStreamHelper 有沒有這個特徵,我就不知道了,也沒測試過。然而,問題出在輸入法剛啟動時的檔案操作判斷邏輯上了:在尚未完成使用者辭典讀入的步驟的前提下,就開始了對使用者辭典目錄的「檔案變動事件有無變化之情況」的監視。
二、威注音 2.3.0 至 2.6.1 版的備用安裝程式「-alternative.zip」有做過多餘的處理,使得系統反而會將要安裝的輸入法塞入 macOS 門衛體系的隔離區、導致輸入法徹底失能。
如果 Console 系統監視程式內與 vChewing 有關的當機報告有說主程式路徑是以「/private/var/」開頭的話,那就是這種情況了。請在終端機內用 xattr 將威注音拽出 macOS 隔離區:
xattr -drs "com.apple.quarantine" $(HOME)/Library/Input\ Methods/vChewing.app
macOS 12.6 對任何沒有經過簽證與公證處理的 app 都好像有點喜歡塞隔離區的樣子。這種情況很少發生就是了,無非就是想從非營利的 devs 們身上也賺取 Apple 研發者會員年費。
拋去 MIT 軟體授權的免責特性先不談,其實軟體複雜了就容易鬼打牆。這個輸入法都是自家人每天都在用的,敢拿出來發佈的版本一定是在發佈的時候自己還沒親自測試出問題的。但這就像是整天面對一堆鬼、整天都在通靈、口唸「鬼門開是殺小啦」,Dev 這邊也是超無奈。這也就是為什麼每次看到有人吐槽說輸入法崩潰的時候 Dev 都會超想問當事人要 ips 格式的軟體崩潰錯誤報告檔案。
因為 Swift 語言在其它平台上的研發維護成本太大。目前威注音專案有在將輸入法本身的非系統特性依賴的部分用 C# 寫成一個「LibvChewingNT」的總成專案,但尚未完工。一旦完工,則或許可以拿來做 Windows 版本。
請洽本文開頭。
請參考 Megrez 原始碼: GitHub § Gitee。
請參考 libvChewing-data 倉庫內的說明檔案: GitHub § Gitee。
Copyright (c) 2021 and onwards The vChewing Project (MIT-NTL License).
Authors (macOS 版): GitHub § Gitee § 中文。