Open PCMan opened 7 years ago
Hi! 目前以我的使用經驗,我覺得以下兩點對用戶有幫助,先提出:
@PCMan, 既然要用列規則的 code 比較好維護,這樣你覺得如何? 假設有 consonant.json, rhyme.json, tonal-mark.json 三個表,用來列出預設的注音,但是多重用途者則 13 只列 ㄍ, 26 只列 ㄝ, 356 只列 ㄟ 最後有個 rule.json 類似這樣: { "23-0": ",", "46-1": "α", "26-2": "ㄧㄞˊ", "356-3": "ㄧㄛ ", "(1|12|24|1245|125|245|15)-156-([^-]+)": "%c%t", "13-(16|1256)-([^-]+)": "ㄐ%r%t", "([^-]+)-([^-]+)": "%r%t", "([^-]+)-([^-]+)-([^-]+)": "%c%r%t", } 把它 load 進 OrderedDict, 前面的規則優先 key 用 regex, value 用 %c 表示要從 consonant.json 取值,%r 從 rhyme.json 取值,%t 從 tonal-mark.json 取值 這樣就不用把所有的規則列舉也不用全部寫在 code 裡,資料小很多 Ex1: 最後一條是 default, 三個 ( ) 就分別把對應的點字鍵入拿去查 consonant.json, rhyme.json, tonal-mark.json Ex2: 倒數第三條是 13 點當 ㄐ 的狀況,韻母雖用列舉但仍要查 %r Ex3: 倒數第四條是舌尖音狀況,聲母用列的,韻母 156 忽略,直接聲調查 %t 如上,應該能 cover 所有目前知道的狀況
在目前的 PIME 內已經有初步支援點字的 braille_chewing 點字酷音模組,但有些功能還是不符合現有視障朋友的使用習慣。以下開放討論,收集意見,以作為新版點字酷音開發的改進參考。