Topics

表情符號、特殊圖案等的點字定義方法 #點字

Sponge Jhan
 

Dear all,

Unicode 裡面有許多表情符號跟圖案,不過 zh-tw.ctb 目前完全沒有定義,因此在臉書等活躍的討論區經常摸到內碼
這裡想要提出一個定義的方式,跟大家討論看看是否合宜?

首先,我的考量是以下幾點:
1. 這種符號不會經常、大量出現,但是一出現就摸到內碼會讓讀者覺得有資訊遺失了
2. 這類符號在前後文中的意義,跟它的圖案外表通常強烈相關
3. 這類符號非常眾多,它缺乏「語言」的邏輯概念,無法用部件拆解的方式簡化定義

我提出的方案是,將每個符號取中文或英文名稱,並將該名稱寫成點字,前後使用特殊括號隔離,舉例如下:
☃ (U+2603) 看起來是雪人的形狀,意義可能表示下雪天氣,但是也可能僅美化文章之用
決定它的名字是「雪人」,點字定義為 ⢎⠑⠦⠈⠛⠥⠂⡱
⢎ ⡱ 就是特殊的括號,印象中 NVDA 都用它來表示核取狀態等資訊

不過,如何命名本身就是一個問題,每個字元其實都有其英文名稱,但是可能非常長與不好理解,所以我舉例用中文而非英文 snowman
然而用中文存再另一個問題,萬一名字沒有選好,有讀者想要知道用了哪些字,求其字形字義,在此行不通,因為它已經是整串點字而非中文字
歡迎各位提出意見,對於定義「圖案」有沒有其他的想法,或者對於圖案的命名提供些建議
現在才接近十月,如果近期有討論出較廣為接受的方案,就能在 12 月初下次 liblouis 進版時提交第一批表情記號的點字定義
Thanks!

  sincerely yours
   Bo-cheng Jhan

嘯傲俠羽
 

請問為啥這裡頭的點字字詞定義 ⢎ ⡱ 字詞解釋不顯示?
記得好多年前宗豪給我的,我只用在自己寫的詞姐檔案,剛好昨天更新忘記還原,此刻閱讀此信方才發現有第七與第八點的點字尚未放入字詞解釋檔?

我覺得用作隔離的括號最好用及特別那種,以免誤解為他是文件內容,反正想個看那一種「獨創括號」,一摸就曉得那是表情符號

2348 1567 這是我用作原本定意六角形括號的點位,
原本六角形括號定義 4412356 4423456
但其實六角形括號有兩種
(可能同類型但編碼不同的括號點位一樣的,還有其他相同的,還沒摸到罷了),

順代一題,像是冒號、引號之類具有方向行或者編碼不同卻少出現的符號點位,
其實我都挺建議特別處理,
現在定義都是同樣點位,
有時不小心打出來或者在文上摸到,
就不曉得自己有沒有打坐或以為那也是正常符號,
例如:
﹁大家永﹂

「大家永」
兩種引號點位定義相同,
但其實他在電腦畫面上的顯示也一樣,
摸到的時候根本不曉得
幸好它很少出現
使用正常六點書促哈也娃容易打出來
可是一旦出現了被眼精告知往往令人感到狐疑
其他還有一些點位一樣、視覺看起來也一樣,
但它統一馬定義不同,
用的卻是同樣點位符號
其實很少出現就少為人所知
加上點字定義沒有區隔就更少被人了解到了


謝謝

在 2018/9/30,Sponge Jhan via Groups.Io <school510587=yahoo.com.tw@groups.io> 撰寫:

Dear all,

Unicode 裡面有許多表情符號跟圖案,不過 zh-tw.ctb 目前完全沒有定義,因此在臉書等活躍的討論區經常摸到內碼
這裡想要提出一個定義的方式,跟大家討論看看是否合宜?

首先,我的考量是以下幾點:
1. 這種符號不會經常、大量出現,但是一出現就摸到內碼會讓讀者覺得有資訊遺失了
2. 這類符號在前後文中的意義,跟它的圖案外表通常強烈相關
3. 這類符號非常眾多,它缺乏「語言」的邏輯概念,無法用部件拆解的方式簡化定義

我提出的方案是,將每個符號取中文或英文名稱,並將該名稱寫成點字,前後使用特殊括號隔離,舉例如下:
☃ (U+2603) 看起來是雪人的形狀,意義可能表示下雪天氣,但是也可能僅美化文章之用
決定它的名字是「雪人」,點字定義為 ⢎⠑⠦⠈⠛⠥⠂⡱
⢎ ⡱ 就是特殊的括號,印象中 NVDA 都用它來表示核取狀態等資訊

不過,如何命名本身就是一個問題,每個字元其實都有其英文名稱,但是可能非常長與不好理解,所以我舉例用中文而非英文 snowman
然而用中文存再另一個問題,萬一名字沒有選好,有讀者想要知道用了哪些字,求其字形字義,在此行不通,因為它已經是整串點字而非中文字
歡迎各位提出意見,對於定義「圖案」有沒有其他的想法,或者對於圖案的命名提供些建議
現在才接近十月,如果近期有討論出較廣為接受的方案,就能在 12 月初下次 liblouis 進版時提交第一批表情記號的點字定義
Thanks!

  sincerely yours
   Bo-cheng Jhan



Sponge Jhan
 

Dear 嘯傲俠羽 & all,

不知道各位對「極特別」定義如何?有沒有其他建議?
目前以我所知,台灣點字裏還沒出現過 2348, 1567 的話希臘字母 Η 用過
不過,因為由左而右,一定先摸到 2348, 後面那個 1567 就應該是表情符號收尾而不會是 Η
如果需要兩方去定義一邊的括號,兩邊就四方稍嫌多了;我也希望它外形不要太不像括號
在此順便請教,以前 NVDA 好像用 123478 145678 當核取框兩邊的括號,後來改 2348 1567 有人知道原因嗎?
Thanks!

  sincerely yours
   Bo-cheng Jhan

--------------------------------------------
18/9/30 (週日),嘯傲俠羽 <crazy@...> 寫道:

主旨: Re: [nvda-tw] 表情符號、特殊圖案等的點字定義方法 #點字
收件者: nvda-tw@groups.io
日期: 2018年9月30日,日,上午5:56

請問為啥這裡頭的點字字詞定義
⢎ ⡱ 字詞解釋不顯示?
記得好多年前宗豪給我的,我只用在自己寫的詞姐檔案,剛好昨天更新忘記還原,此刻閱讀此信方才發現有第七與第八點的點字尚未放入字詞解釋檔?

我覺得用作隔離的括號最好用及特別那種,以免誤解為他是文件內容,反正想個看那一種「獨創括號」,一摸就曉得那是表情符號

2348 1567
這是我用作原本定意六角形括號的點位,
原本六角形括號定義 4412356 4423456
但其實六角形括號有兩種
(可能同類型但編碼不同的括號點位一樣的,還有其他相同的,還沒摸到罷了),

順代一題,像是冒號、引號之類具有方向行或者編碼不同卻少出現的符號點位,
其實我都挺建議特別處理,
現在定義都是同樣點位,
有時不小心打出來或者在文上摸到,
就不曉得自己有沒有打坐或以為那也是正常符號,
例如:
﹁大家永﹂

「大家永」
兩種引號點位定義相同,
但其實他在電腦畫面上的顯示也一樣,
摸到的時候根本不曉得
幸好它很少出現
使用正常六點書促哈也娃容易打出來
可是一旦出現了被眼精告知往往令人感到狐疑
其他還有一些點位一樣、視覺看起來也一樣,
但它統一馬定義不同,
用的卻是同樣點位符號
其實很少出現就少為人所知
加上點字定義沒有區隔就更少被人了解到了


謝謝

在 2018/9/30,Sponge Jhan via Groups.Io
<school510587=yahoo.com.tw@groups.io>
撰寫:
> Dear all,
>
> Unicode
裡面有許多表情符號跟圖案,不過 zh-tw.ctb
目前完全沒有定義,因此在臉書等活躍的討論區經常摸到內碼
>
這裡想要提出一個定義的方式,跟大家討論看看是否合宜?
>
>
首先,我的考量是以下幾點:
>
1.
這種符號不會經常、大量出現,但是一出現就摸到內碼會讓讀者覺得有資訊遺失了
> 2.
這類符號在前後文中的意義,跟它的圖案外表通常強烈相關
> 3.
這類符號非常眾多,它缺乏「語言」的邏輯概念,無法用部件拆解的方式簡化定義
>
>
我提出的方案是,將每個符號取中文或英文名稱,並將該名稱寫成點字,前後使用特殊括號隔離,舉例如下:
> ☃ (U+2603)
看起來是雪人的形狀,意義可能表示下雪天氣,但是也可能僅美化文章之用
>
決定它的名字是「雪人」,點字定義為
⢎⠑⠦⠈⠛⠥⠂⡱
> ⢎ ⡱
就是特殊的括號,印象中 NVDA
都用它來表示核取狀態等資訊
>
>
不過,如何命名本身就是一個問題,每個字元其實都有其英文名稱,但是可能非常長與不好理解,所以我舉例用中文而非英文
snowman
>
然而用中文存再另一個問題,萬一名字沒有選好,有讀者想要知道用了哪些字,求其字形字義,在此行不通,因為它已經是整串點字而非中文字
>
歡迎各位提出意見,對於定義「圖案」有沒有其他的想法,或者對於圖案的命名提供些建議
>
現在才接近十月,如果近期有討論出較廣為接受的方案,就能在
12 月初下次 liblouis
進版時提交第一批表情記號的點字定義
> Thanks!
>
>   sincerely yours
>
   Bo-cheng Jhan
>
>
>
>

=?ISO-2022-JP?Q?=1B$B9b=4082=22=1B=28J?=
 

這個話題可以參閱下面這篇國外的定義提案:
Unicode Emoticons in Braille
http://www.cbtbc.org/braille/emoticons

On Sat, 29 Sep 2018, Sponge Jhan via Groups.Io wrote:

Dear all,

Unicode 裡面有許多表情符號跟圖案,不過 zh-tw.ctb 目前完全沒有定義,因此在臉書等活躍的討論區經常摸到內碼
這裡想要提出一個定義的方式,跟大家討論看看是否合宜?

首先,我的考量是以下幾點:
1. 這種符號不會經常、大量出現,但是一出現就摸到內碼會讓讀者覺得有資訊遺失了
2. 這類符號在前後文中的意義,跟它的圖案外表通常強烈相關
3. 這類符號非常眾多,它缺乏「語言」的邏輯概念,無法用部件拆解的方式簡化定義

我提出的方案是,將每個符號取中文或英文名稱,並將該名稱寫成點字,前後使用特殊括號隔離,舉例如下:
? (U+2603) 看起來是雪人的形狀,意義可能表示下雪天氣,但是也可能僅美化文章之用
決定它的名字是「雪人」,點字定義為 ????????
? ? 就是特殊的括號,印象中 NVDA 都用它來表示核取狀態等資訊

不過,如何命名本身就是一個問題,每個字元其實都有其英文名稱,但是可能非常長與不好理解,所以我舉例用中文而非英文 snowman
然而用中文存再另一個問題,萬一名字沒有選好,有讀者想要知道用了哪些字,求其字形字義,在此行不通,因為它已經是整串點字而非中文字
歡迎各位提出意見,對於定義「圖案」有沒有其他的想法,或者對於圖案的命名提供些建議
現在才接近十月,如果近期有討論出較廣為接受的方案,就能在 12 月初下次 liblouis 進版時提交第一批表情記號的點字定義
Thanks!

  sincerely yours
   Bo-cheng Jhan

嘯傲俠羽
 

在某一段統一馬序列之間都用 「表示開頭與結尾」了符號包裹,作為「表情指標」例如 ⠨⠣xxx⠨⠜
跟我說「用及特別的括號」說法應該雷同。
它雖然前後包裹符號用到四格,
不過反在特殊場合才會出現,該可接受?
或者能不能像定義英文六點點字那樣「點連續出現打寫符號直到空格,前面自動加上兩個第六點」的定義,
出現一連串代表表情符號的統一馬,前後包裹一層這樣的括號?



在 2018/9/30,高生旺 <coscell@...> 撰寫:

這個話題可以參閱下面這篇國外的定義提案:
Unicode Emoticons in Braille
http://www.cbtbc.org/braille/emoticons

On Sat, 29 Sep 2018, Sponge Jhan via Groups.Io wrote:

Dear all,

Unicode 裡面有許多表情符號跟圖案,不過 zh-tw.ctb 目前完全沒有定義,因此在臉書等活躍的討論區經常摸到內碼
這裡想要提出一個定義的方式,跟大家討論看看是否合宜?

首先,我的考量是以下幾點:
1. 這種符號不會經常、大量出現,但是一出現就摸到內碼會讓讀者覺得有資訊遺失了
2. 這類符號在前後文中的意義,跟它的圖案外表通常強烈相關
3. 這類符號非常眾多,它缺乏「語言」的邏輯概念,無法用部件拆解的方式簡化定義

我提出的方案是,將每個符號取中文或英文名稱,並將該名稱寫成點字,前後使用特殊括號隔離,舉例如下:
? (U+2603) 看起來是雪人的形狀,意義可能表示下雪天氣,但是也可能僅美化文章之用
決定它的名字是「雪人」,點字定義為 ????????
? ? 就是特殊的括號,印象中 NVDA 都用它來表示核取狀態等資訊

不過,如何命名本身就是一個問題,每個字元其實都有其英文名稱,但是可能非常長與不好理解,所以我舉例用中文而非英文 snowman
然而用中文存再另一個問題,萬一名字沒有選好,有讀者想要知道用了哪些字,求其字形字義,在此行不通,因為它已經是整串點字而非中文字
歡迎各位提出意見,對於定義「圖案」有沒有其他的想法,或者對於圖案的命名提供些建議
現在才接近十月,如果近期有討論出較廣為接受的方案,就能在 12 月初下次 liblouis 進版時提交第一批表情記號的點字定義
Thanks!

  sincerely yours
   Bo-cheng Jhan




Sponge Jhan
 

Dear 高老師 & all,

文中提到使用 ⠁⠨⠣ 跟 ⠁⠨⠜ 標記表情符號,作用跟我原先的 ⢎ ⡱ 一致
不過仍有幾個一問要提出討論:
* 前後括號就用掉六方,這樣有沒有人覺得很浪費?不過如果英語用戶都能接受,可能這個問題比較不嚴重
* 大家覺得這種括號可以融入 zh-tw.ctb 不產生其他摸讀困擾嗎?關於這點,我可能比較傾向保留上面 1~6, 在下方追加 78 點以示區別

如上,感謝高老師提供很有用的資料

  sincerely yours
   Bo-cheng Jhan

--------------------------------------------
18/9/30 (週日),高生旺 <coscell@...> 寫道:

主旨: Re: [nvda-tw] 表情符號、特殊圖案等的點字定義方法 #點字
收件者: nvda-tw@groups.io
日期: 2018年9月30日,日,上午6:33

這個話題可以參閱下面這篇國外的定義提案:
Unicode Emoticons in Braille
http://www.cbtbc.org/braille/emoticons

On Sat, 29 Sep 2018, Sponge Jhan via Groups.Io
wrote:

> Dear all,
>
> Unicode
裡面有許多表情符號跟圖案,不過 zh-tw.ctb
目前完全沒有定義,因此在臉書等活躍的討論區經常摸到內碼
>
這裡想要提出一個定義的方式,跟大家討論看看是否合宜?
>
>
首先,我的考量是以下幾點:
>
1.
這種符號不會經常、大量出現,但是一出現就摸到內碼會讓讀者覺得有資訊遺失了
> 2.
這類符號在前後文中的意義,跟它的圖案外表通常強烈相關
> 3.
這類符號非常眾多,它缺乏「語言」的邏輯概念,無法用部件拆解的方式簡化定義
>
>
我提出的方案是,將每個符號取中文或英文名稱,並將該名稱寫成點字,前後使用特殊括號隔離,舉例如下:
> ? (U+2603)
看起來是雪人的形狀,意義可能表示下雪天氣,但是也可能僅美化文章之用
>
決定它的名字是「雪人」,點字定義為
????????
> ? ?
就是特殊的括號,印象中 NVDA
都用它來表示核取狀態等資訊
>
>
不過,如何命名本身就是一個問題,每個字元其實都有其英文名稱,但是可能非常長與不好理解,所以我舉例用中文而非英文
snowman
>
然而用中文存再另一個問題,萬一名字沒有選好,有讀者想要知道用了哪些字,求其字形字義,在此行不通,因為它已經是整串點字而非中文字
>
歡迎各位提出意見,對於定義「圖案」有沒有其他的想法,或者對於圖案的命名提供些建議
>
現在才接近十月,如果近期有討論出較廣為接受的方案,就能在
12 月初下次 liblouis
進版時提交第一批表情記號的點字定義
> Thanks!
>
>   sincerely yours
>
   Bo-cheng Jhan
>
>
>

Sponge Jhan
 

Dear all,

之前表情符號問題拖了一陣子,因為我也在忙自己研究上的事情
我所提出二個問題目前沒有收到其他回覆,這裡我先寫出自己的看法:

建議用 ⢈⣨⣣ (48-4678-12678) 與 ⣈⣨⣜ (478-4678-34578) 來寫外圍的括號
以 4-46-126, 4-46-345 為基礎,下面加上 78 點而成,不過開投故意只有 8 為了留空間給點字游標跳動
Unicode 表情或圖案中有些是塗黑 (black) 的,將不強調「黑」而是上述括號的 4678 改為 45678
因為沒有人給其他異議,括號用掉六方太多的問題視為沒關係
增加 78 點以後,可以避開第二個問題,摸點字就能知道這裡是表情或圖案的敘述
另外,我把第一方改成第四點而不用第一點,點的分配上它跟前面內容會有個緩衝空間

放在這裡約二週,如果以上的方式可以接受,月中我就會把第一批「圖案」用這種方式寫到 zh-tw.ctb
註:語音會朗讀那種表情符號 Unicode 都在 U+FFFF 以外,目前 NVDA 內夾帶的點字轉換庫 liblouis 版本沒有支援到 UTF-32, 所以還無法直接點譯它們,我會加進來的圖案主要落在 U+26XX 這段如太陽、雪人、電話等等
Thanks.

  sincerely yours
   Bo-cheng Jhan

=?ISO-2022-JP?Q?=1B$B9b=4082=22=1B=28J?=
 

1. 兩個問題是什麼不記得了。
2. 我的致力大退,看不懂你在說什麼。
3. 分隔符號加上敘述,佔用空間非常可觀,沒有更好的方案前建議暫時擱置。

On Sat, 3 Nov 2018, Sponge Jhan via Groups.Io wrote:

Dear all,

之前表情符號問題拖了一陣子,因為我也在忙自己研究上的事情
我所提出二個問題目前沒有收到其他回覆,這裡我先寫出自己的看法:

建議用 ??? (48-4678-12678) 與 ??? (478-4678-34578) 來寫外圍的括號
以 4-46-126, 4-46-345 為基礎,下面加上 78 點而成,不過開投故意只有 8 為了留空間給點字游標跳動
Unicode 表情或圖案中有些是塗黑 (black) 的,將不強調「黑」而是上述括號的 4678 改為 45678
因為沒有人給其他異議,括號用掉六方太多的問題視為沒關係
增加 78 點以後,可以避開第二個問題,摸點字就能知道這裡是表情或圖案的敘述
另外,我把第一方改成第四點而不用第一點,點的分配上它跟前面內容會有個緩衝空間

放在這裡約二週,如果以上的方式可以接受,月中我就會把第一批「圖案」用這種方式寫到 zh-tw.ctb
註:語音會朗讀那種表情符號 Unicode 都在 U+FFFF 以外,目前 NVDA 內夾帶的點字轉換庫 liblouis 版本沒有支援到 UTF-32, 所以還無法直接點譯它們,我會加進來的圖案主要落在 U+26XX 這段如太陽、雪人、電話等等
Thanks.

  sincerely yours
   Bo-cheng Jhan

嘯傲俠羽
 

關於 unicode 表情符號,

第一,是不是考慮,不要用「前後括號包裹」的方式定義點位?
改用「開頭與結束符號」表示,
定義怎樣的符號點衛士「開頭符號」,
怎樣的點衛是「結束符號」?
我在臉書經常摸到一堆連續出現的表情符號,
所以,符號與符號之間是否也需要加入「分隔符號」?
比較抱歉的是,在信件裡頭只描述點位定義,
也許也希望摸到實際的符號例子,
這樣可以比較容易理解「這樣的點為定義,摸起來的感覺如何?」
例如(我隨便舉個例子):
{ke8`gu1<2
{ke{"ct`, hv"ix`<2
「二四六、一三點」表示符號的開頭,
「一二六、二三點」,表示符號結尾,
(我記得音樂點字樂譜結束符號是「一二六、一三點」)。
如果兩個以上的表情連續出現,
「第三點、空一方」表示符號分隔,
以上兩個例子,第二個如果沒有分隔符號,
就會變成這樣:
{ke{"ct`hv"ix`<2

摸起來會以為只有一個表情符號。

第二點,不曉得是否可以確認表情符號落在 unicode 的那個範圍?
如此,在這些範圍內的 unicode 出現的時候認定其為表情符號,
前面呈現「符號開頭」,後面呈縣「符號結束」,
但就不曉得如果兩個以上表情符號連續出現,
怎樣讓點字表判斷,並且在符號之間加入「分隔符號」?

第三,假如點字表無法分辨服用區隔表達,
每個表情符號都要有開頭與結束,那就建議結束符號用「二三點、空白」,
「二三點」原本會被勿認為是逗號,
但只要知道、摸到表情符號開頭,
在摸到「二三點、空格」自然能理解那不是逗號,
例如下面這樣:

{ke8`gu12 {ke{"ct`2

假裝臉書動報有下面的這樣內從:

心情覺得有些門門的…{ke8`gu12 {ke{"ct`2 不過沒關係我可以決定自己怎樣改變心情…{ke{"ct`2 ~~~

以上三點分享與建議!謝謝!

ps. 我一直好奇 ueb 怎樣判定「連續大寫字母出現,
然後前面自動入三個第六點,
大寫字母格術以後還有結束符號。



在 2018/11/3,高生旺 <coscell@...> 撰寫:

1. 兩個問題是什麼不記得了。
2. 我的致力大退,看不懂你在說什麼。
3. 分隔符號加上敘述,佔用空間非常可觀,沒有更好的方案前建議暫時擱置。

On Sat, 3 Nov 2018, Sponge Jhan via Groups.Io wrote:

Dear all,

之前表情符號問題拖了一陣子,因為我也在忙自己研究上的事情
我所提出二個問題目前沒有收到其他回覆,這裡我先寫出自己的看法:

建議用 ??? (48-4678-12678) 與 ??? (478-4678-34578) 來寫外圍的括號
以 4-46-126, 4-46-345 為基礎,下面加上 78 點而成,不過開投故意只有 8 為了留空間給點字游標跳動
Unicode 表情或圖案中有些是塗黑 (black) 的,將不強調「黑」而是上述括號的 4678 改為 45678
因為沒有人給其他異議,括號用掉六方太多的問題視為沒關係
增加 78 點以後,可以避開第二個問題,摸點字就能知道這裡是表情或圖案的敘述
另外,我把第一方改成第四點而不用第一點,點的分配上它跟前面內容會有個緩衝空間

放在這裡約二週,如果以上的方式可以接受,月中我就會把第一批「圖案」用這種方式寫到 zh-tw.ctb
註:語音會朗讀那種表情符號 Unicode 都在 U+FFFF 以外,目前 NVDA 內夾帶的點字轉換庫 liblouis 版本沒有支援到
UTF-32, 所以還無法直接點譯它們,我會加進來的圖案主要落在 U+26XX 這段如太陽、雪人、電話等等
Thanks.

  sincerely yours
   Bo-cheng Jhan




Sponge Jhan
 

Dear all,

首先,我翻了論壇網頁,發現有二個「表情符號、特殊圖案等的點字定義方法」,而我說問過二個問題在以下連結:
https://groups.io/g/nvda-tw/topic/26426247?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,26426247
二個問題內容如下:
* 前後括號就用掉六方,這樣有沒有人覺得很浪費?不過如果英語用戶都能接受,可能這個問題比較不嚴重
* 大家覺得這種括號可以融入 zh-tw.ctb 不產生其他摸讀困擾嗎?關於這點,我可能比較傾向保留上面 1~6, 在下方追加 78 點以示區別
可是,放上去幾週了未收到任何異議
PS. 能否麻煩管理人幫忙把二個 topic 併起來?

然後,這是我的建議:
1. 用 2468 (⢪) 及 124568 (⢻) 代表表情、圖案敘述的頭尾
2. 圖黑者,頭 2468 之前加一個 4568 (⢸)
直接以大括號 { } 擴展而來,這樣應該可以簡單又好記住,一樣放兩週左右,希望這次訊息沒有再被任何夥伴遺漏

對於嘯傲俠羽提出的建議回應如下:
如果要說用太多方,建議內容使用的寫法可能還是太多,而且 23 空白需要往前摸讀才能確定符號是結尾還是正常逗號,另外如果用了頭、尾、分隔的觀念來實現規則,不知道點字游標將如何移動?
以上是觀念面的問題,技術上目前點字轉譯庫 liblouis 支援的語法方式不好實作
liblouis 有「類別」的觀念,也就是每個字元都有它自己的類別,如字元 (letter)、大寫 (upper)、數學符號 (math) 等
類別是由轉譯表的作者指定,如果正確標記這些類別,將可以正確使用某些有條件執行的規則,如:

begcapsword 6-6
endcapsword 6-3
begcapsphrase 6-6-6
begcaps 6-6-6
endcaps 6-3

這些指令取自 en-ueb-g1.ctb, 足以解釋為何 UEB 會自己判斷大寫而正確點寫
然而,沒有一個類別叫做「漢字」,我們只能將漢字都歸類為 letter
liblouis 有讓轉譯表自訂類別的語法,比如:

class ChiNum 一二三四五六七八九十
noback context %ChiNum["子"] @125-156-4

這樣,一到十的國字自成一個類別叫做 ChiNum
如果「子」前面出現 ChiNum 類別中的字,就要寫成三聲,比如「五子登科」
然而,表情符號落在 U+1F600~U+1F64F 共 80 個,也就是說我 class 後面要連續爆力列舉這麼多字
就不用說自己去定義一個「漢字」的類別了,不切實際

嘯傲俠羽
 

太感謝你了,每次閱讀你內容都會有收穫,雖然我不一定完全明白,但至少提供實做的路線,遇到問題,或許比較曉得怎樣請教!
看!除了說說自己的建議,又可以獲得回應與分享,多好!希望多一些人願意參與學習!
en-ueb-g1.ctb 這些指令,不曉得我能訴嗄稿得零白,遇到狀況再跟你討教!
你說的表情符號點位定義,我決這樣子很好,
至少高老師問出聊了,激發你想出這樣的點字定義方式,
挺好!看有人願意提出自己的想法!
我覺得大家樂於討論,總是好的,即使意見不同,至少具有啟發思維效果!謝謝!

在 2018/11/4,Sponge Jhan via Groups.Io <school510587=yahoo.com.tw@groups.io> 撰寫:

Dear all,

首先,我翻了論壇網頁,發現有二個「表情符號、特殊圖案等的點字定義方法」,而我說問過二個問題在以下連結:
https://groups.io/g/nvda-tw/topic/26426247?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,26426247
二個問題內容如下:
* 前後括號就用掉六方,這樣有沒有人覺得很浪費?不過如果英語用戶都能接受,可能這個問題比較不嚴重
* 大家覺得這種括號可以融入 zh-tw.ctb 不產生其他摸讀困擾嗎?關於這點,我可能比較傾向保留上面 1~6, 在下方追加 78 點以示區別
可是,放上去幾週了未收到任何異議
PS. 能否麻煩管理人幫忙把二個 topic 併起來?

然後,這是我的建議:
1. 用 2468 (⢪) 及 124568 (⢻) 代表表情、圖案敘述的頭尾
2. 圖黑者,頭 2468 之前加一個 4568 (⢸)
直接以大括號 { } 擴展而來,這樣應該可以簡單又好記住,一樣放兩週左右,希望這次訊息沒有再被任何夥伴遺漏

對於嘯傲俠羽提出的建議回應如下:
如果要說用太多方,建議內容使用的寫法可能還是太多,而且 23
空白需要往前摸讀才能確定符號是結尾還是正常逗號,另外如果用了頭、尾、分隔的觀念來實現規則,不知道點字游標將如何移動?
以上是觀念面的問題,技術上目前點字轉譯庫 liblouis 支援的語法方式不好實作
liblouis 有「類別」的觀念,也就是每個字元都有它自己的類別,如字元 (letter)、大寫 (upper)、數學符號 (math) 等
類別是由轉譯表的作者指定,如果正確標記這些類別,將可以正確使用某些有條件執行的規則,如:

begcapsword 6-6
endcapsword 6-3
begcapsphrase 6-6-6
begcaps 6-6-6
endcaps 6-3

這些指令取自 en-ueb-g1.ctb, 足以解釋為何 UEB 會自己判斷大寫而正確點寫
然而,沒有一個類別叫做「漢字」,我們只能將漢字都歸類為 letter
liblouis 有讓轉譯表自訂類別的語法,比如:

class ChiNum 一二三四五六七八九十
noback context %ChiNum["子"] @125-156-4

這樣,一到十的國字自成一個類別叫做 ChiNum
如果「子」前面出現 ChiNum 類別中的字,就要寫成三聲,比如「五子登科」
然而,表情符號落在 U+1F600~U+1F64F 共 80 個,也就是說我 class 後面要連續爆力列舉這麼多字
就不用說自己去定義一個「漢字」的類別了,不切實際



蔡宗豪 Victor Cai
 

Dear 博丞 & all,
謝謝博丞,著手處理 Unicode 表情符號跟圖案,目前沒有定義,點字用戶經常摸到內碼的問題。

高老師虔信提到:

分隔符號加上敘述,佔用空間非常可觀,沒有更好的方案前建議暫時擱置。

是否可能有兼顧摸讀效率與語意表達的設計?
NVDA 報讀符號有區別層級的作法。
點字定義是否可能新增一個「表情符號」的類別。讓用戶選擇控制顯示表情符號的開關?
對於使用二十方顯示器的用戶來說,一個表情符號,可能就用掉一個點字視窗。因此,才有前述的發想。

最後,是一點題外話。目前已將表情符號的點字定義,整併成一個討論串。過程中發現,2163、2164可能為重複張貼的內容。再請博丞確認後,告知是否需刪除哪一篇?謝謝。
討論串位置:
https://groups.io/g/nvda-tw/topic/27836633?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,27836633


Sponge Jhan
 

Dear 宗豪 & all,

Sorry, 2163, 2164 是我故意貼兩次,因為不明原因分兩串了,從高老師回應的內容我覺得之前寫的可能被遺漏閱讀,所以我不希望提案再被任何成員遺漏,才這樣做
既然合併了,可否麻煩宗豪協助砍掉一篇吧~~
Thanks.

點字定義是否可能新增一個「表情符號」的類別。讓用戶選擇控制顯示表情符號的開關?
這個提議目前無法實行,因為 liblouis 並未在 API 提供更多自由選項,NVDA 也無法在這方面設計 filter

對於使用二十方顯示器的用戶來說,一個表情符號,可能就用掉一個點字視窗。因此,才有前述的發想。
即使關掉「特殊括號夾住釋意」的顯示方式,表情符號仍會變成「亂碼」顯示出來
假設未來 NVDA 也將 liblouis 換成支援 UCS-4 的版本,未定義表情符號將顯示為 '\yXXXXX' 的格式,是只會佔掉螢幕一半沒錯
但是,無法增設選項的原因已經在剛才提過了
不過還有一個希望,是提出 issue 請 liblouis 修改,畢竟使用 UEB 的用戶也將遭遇同樣問題


  sincerely yours
   Bo-cheng Jhan

=?ISO-2022-JP?Q?=1B$B9b=4082=22=1B=28J?=
 

我的回應市表示時間太九或著說是我的記性太差,兒你們發信又習慣不引用前文,所以不記得。
我記得不用引文的理由前面有人提過,但是我認為郵遞論壇的設計主要就是用電由溝通,網站存檔只是備查支用,顛倒過來使用險得本末倒置。

蔡宗豪 Victor Cai
 

Dear 博丞 & all,

不過還有一個希望,是提出 issue 請 liblouis 修改,畢竟使用 UEB 的用戶也將遭遇同樣問題

謝謝博丞在 liblouis 提出 issue。
https://github.com/liblouis/liblouis/issues/664

即使關掉「特殊括號夾住釋意」的顯示方式,表情符號仍會變成「亂碼」顯示出來
假設未來 NVDA 也將 liblouis 換成支援 UCS-4 的版本,未定義表情符號將顯示為 ‘\yXXXXX’ 的格式,是只會佔掉螢幕一半沒錯

過去,也有用戶提到,希望能選擇隱藏那些點字對照表沒有定義的符號。實際執行,同樣呼應了博丞虔信的說法,需要從 liblouis 提出解決方案。有興趣了解的朋友請參考這則 NVDA issue:
https://github.com/nvaccess/nvda/issues/2949


Sponge Jhan
 

Hi all,

目前 issue #664 官方認為要用 table discovery 機制解決,但他們應該不會在 12 月初的新版增加這修改
考慮到版上有提出點字太長的問題,剛才放上來的 2018-11 版本就沒有追加那些圖案性質的字符

  sincerely yours
   Bo-cheng Jhan

Sponge Jhan
 

Hi all,

之前有說要讓 zh-tw.ctb 支援表情符號,我也跟 liblouis 進行過如下討論:
https://github.com/liblouis/liblouis/issues/664
然後,宗豪有替我找出 NVDA 點字方面一個重大更新,也就是將點字的處理擴展到 UCS-4 (32 位元) 的 Unicode 字元:
https://github.com/nvaccess/nvda/pull/9544
也就是說,現行 NVDA 使用 Python 2 與 UCS-2 版本 liblouis, 應該到了 2019.3 版時,NVDA 會採用 Python 3, 以及包括點字在內很多重大改革
官於表情符號以及 zh-tw.ctb 未來會有這些變化:
一、在 NVDA 搭載的 liblouis 更新至 3.10 版以後,將開始實驗 zh-tw.ctb 支援表情符號
二、表情符號的支援測試通過以後,而且 NVDA 搭載的 liblouis 也改以 UCS-4 處理字元之後,zh-tw.ctb 將拆成二個檔案:
1. zh-tw-chardefs.cti: 直接從現有 zh-tw.ctb 更名而來,包含所有基本字符、綁定規則
2. zh-tw.ctb: 包含表情符號這類 UCS-4 字元,並且 include zh-tw-chardefs.cti, 它仍是使用者直接面對的中文台灣點字轉譯表。此時也會在 zh-tw.ctb 標註所建議之點顯器寬度,但是否生效也要看應用程式 (如 NVDA) 採不採納建議了
拆檔的目的,是保留彈性空間,如果有別的應用程式真的必須用 UCS-2 版本的 liblouis, 仍然可以只使用 zh-tw-chardefs.cti, 不會因為 zh-tw.ctb 加入了表情符號而變成無法相容於 UCS-2 版本的 liblouis

以上,不過如果 liblouis 開發者有其他建議,進行的內容仍可能改變
Thanks!

  sincerely yours
   Bo-cheng Jhan

=?ISO-2022-JP?Q?=1B$B9b=4082=22=1B=28J?=
 

看了一下 2019.3 的 changelog, liblious 的確換成 3.10.0.
Changes for Developers 則還沒有提到要換 python, 蔗板應該還不會換。

On Sat, 22 Jun 2019, Sponge Jhan via Groups.Io wrote:

Date: Sat, 22 Jun 2019 17:12:32 +0000 (UTC)
From: Sponge Jhan via Groups.Io <school510587=yahoo.com.tw@groups.io>
Reply-To: nvda-tw@groups.io
To: nvda-tw@groups.io
Subject: Re: [nvda-tw] 表情符號、特殊圖案等的點字定義方法 #點字
Hi all,

之前有說要讓 zh-tw.ctb 支援表情符號,我也跟 liblouis 進行過如下討論:
https://github.com/liblouis/liblouis/issues/664
然後,宗豪有替我找出 NVDA 點字方面一個重大更新,也就是將點字的處理擴展到 UCS-4 (32 位元) 的 Unicode 字元:
https://github.com/nvaccess/nvda/pull/9544
也就是說,現行 NVDA 使用 Python 2 與 UCS-2 版本 liblouis, 應該到了 2019.3 版時,NVDA 會採用 Python 3, 以及包括點字在內很多重大改革
官於表情符號以及 zh-tw.ctb 未來會有這些變化:
一、在 NVDA 搭載的 liblouis 更新至 3.10 版以後,將開始實驗 zh-tw.ctb 支援表情符號
二、表情符號的支援測試通過以後,而且 NVDA 搭載的 liblouis 也改以 UCS-4 處理字元之後,zh-tw.ctb 將拆成二個檔案:
1. zh-tw-chardefs.cti: 直接從現有 zh-tw.ctb 更名而來,包含所有基本字符、綁定規則
2. zh-tw.ctb: 包含表情符號這類 UCS-4 字元,並且 include zh-tw-chardefs.cti, 它仍是使用者直接面對的中文台灣點字轉譯表。此時也會在 zh-tw.ctb 標註所建議之點顯器寬度,但是否生效也要看應用程式 (如 NVDA) 採不採納建議了
拆檔的目的,是保留彈性空間,如果有別的應用程式真的必須用 UCS-2 版本的 liblouis, 仍然可以只使用 zh-tw-chardefs.cti, 不會因為 zh-tw.ctb 加入了表情符號而變成無法相容於 UCS-2 版本的 liblouis

以上,不過如果 liblouis 開發者有其他建議,進行的內容仍可能改變
Thanks!

  sincerely yours
   Bo-cheng Jhan

嘯傲俠羽
 

我忽然有個疑惑,現在所定義的點字符號都只能在 nvda 操作下閱讀,
這當凡好,但如果使用其他閱讀軟體,
該讀屏假如野支援輸出入 unicode,
點字的定義會不會跟現在這些不一樣?
同樣的符號,會不會有不一樣的點位輸出狀況?
例如 focus 點險器可以操作手機的時候,
同樣的一篇文件,點字輸出因為點字定義表沒統一,
可能會有兩種點赤定義?
除非在手機上也能使用 nvda
當然我這都是空想,還沒使用 focus 操作手機的經驗,
謝謝!



在 2019/6/23,高生旺 <coscell@...> 撰寫:

看了一下 2019.3 的 changelog, liblious 的確換成 3.10.0.
Changes for Developers 則還沒有提到要換 python, 蔗板應該還不會換。

On Sat, 22 Jun 2019, Sponge Jhan via Groups.Io wrote:

Date: Sat, 22 Jun 2019 17:12:32 +0000 (UTC)
From: Sponge Jhan via Groups.Io <school510587=yahoo.com.tw@groups.io>
Reply-To: nvda-tw@groups.io
To: nvda-tw@groups.io
Subject: Re: [nvda-tw] 表情符號、特殊圖案等的點字定義方法 #點字

Hi all,

之前有說要讓 zh-tw.ctb 支援表情符號,我也跟 liblouis 進行過如下討論:
https://github.com/liblouis/liblouis/issues/664
然後,宗豪有替我找出 NVDA 點字方面一個重大更新,也就是將點字的處理擴展到 UCS-4 (32 位元) 的 Unicode 字元:
https://github.com/nvaccess/nvda/pull/9544
也就是說,現行 NVDA 使用 Python 2 與 UCS-2 版本 liblouis, 應該到了 2019.3 版時,NVDA 會採用
Python 3, 以及包括點字在內很多重大改革
官於表情符號以及 zh-tw.ctb 未來會有這些變化:
一、在 NVDA 搭載的 liblouis 更新至 3.10 版以後,將開始實驗 zh-tw.ctb 支援表情符號
二、表情符號的支援測試通過以後,而且 NVDA 搭載的 liblouis 也改以 UCS-4 處理字元之後,zh-tw.ctb 將拆成二個檔案:
1. zh-tw-chardefs.cti: 直接從現有 zh-tw.ctb 更名而來,包含所有基本字符、綁定規則
2. zh-tw.ctb: 包含表情符號這類 UCS-4 字元,並且 include zh-tw-chardefs.cti,
它仍是使用者直接面對的中文台灣點字轉譯表。此時也會在 zh-tw.ctb 標註所建議之點顯器寬度,但是否生效也要看應用程式 (如 NVDA)
採不採納建議了
拆檔的目的,是保留彈性空間,如果有別的應用程式真的必須用 UCS-2 版本的 liblouis, 仍然可以只使用
zh-tw-chardefs.cti, 不會因為 zh-tw.ctb 加入了表情符號而變成無法相容於 UCS-2 版本的 liblouis

以上,不過如果 liblouis 開發者有其他建議,進行的內容仍可能改變
Thanks!

  sincerely yours
   Bo-cheng Jhan




Sponge Jhan
 

Hi 嘯傲俠羽,

我覺得這是很有可能的,如果沒有搞錯意思。不過要看軟體本身使用的點字來自何處
要是 Android 跟 NVDA 一樣調用 liblouis, 符號就應該一樣的顯示方式,除非 Android 私底下有微調行為
但是 Mac OS 可能就是自己的點字處理方式,雖說是簡體中文點字,卻也跟 NVDA 的簡中點字不同

  sincerely yours
   Bo-cheng Jhan

--------------------------------------------
19/6/23 (週日),嘯傲俠羽 <crazy@...> 寫道:

主旨: Re: [nvda-tw] 表情符號、特殊圖案��的點字定義方法 #點字
收件者: nvda-tw@groups.io
日期: 2019年6月23日,日,上午6:55

我忽然有個疑惑,現在所定義的點字符號都只能在
nvda 操作下閱讀,
這當凡好,但如果使用其他閱讀軟體,
該讀屏假如野支援輸出入 unicode,
點字的定義會不會跟現在這些不一樣?
同樣的符號,會不會有不一樣的點位輸出狀況?
例如 focus
點險器可以操作手機的時候,
同樣的一篇文件,點字輸出因為點字定義表沒統一,
可能會有兩種點赤定義?
除非在手機上也能使用 nvda
當然我這都是空想,還沒使用 focus
操作手機的經驗,
謝謝!



在 2019/6/23,高生旺 <coscell@...>
撰寫:
> 看了一下 2019.3 的
changelog, liblious 的確換成 3.10.0.
> Changes for Developers
則還沒有提到要換 python,
蔗板應該還不會換。
>
> On Sat, 22 Jun 2019, Sponge Jhan via
Groups.Io wrote:
>
>> Date: Sat, 22 Jun 2019 17:12:32 +0000
(UTC)
>> From: Sponge Jhan via
Groups.Io <school510587=yahoo.com.tw@groups.io>
>> Reply-To: nvda-tw@groups.io
>> To: nvda-tw@groups.io
>> Subject: Re: [nvda-tw]
表情符號、特殊圖案等的點字定義方法
#點字
>>
>> Hi
all,
>>
>>
之前有說要讓 zh-tw.ctb 支援表情符號,我也跟
liblouis 進行過如下討論:
>>
https://github.com/liblouis/liblouis/issues/664
>> 然後,宗豪有替我找出 NVDA
點字方面一個重大更新,也就是將點字的處理擴展到
UCS-4 (32 位元) 的 Unicode 字元:
>> https://github.com/nvaccess/nvda/pull/9544
>> 也就是說,現行 NVDA 使用
Python 2 與 UCS-2 版本 liblouis, 應該到了 2019.3
版時,NVDA 會採用
>> Python 3,
以及包括點字在內很多重大改革
>> 官於表情符號以及 zh-tw.ctb
未來會有這些變化:
>>
一、在 NVDA 搭載的 liblouis 更新至 3.10
版以後,將開始實驗 zh-tw.ctb 支援表情符號
>>
二、表情符號的支援測試通過以後,而且 NVDA
搭載的 liblouis 也改以 UCS-4
處理字元之後,zh-tw.ctb 將拆成二個檔案:
>> 1. zh-tw-chardefs.cti: 直接從現有
zh-tw.ctb
更名而來,包含所有基本字符、綁定規則
>> 2. zh-tw.ctb: 包含表情符號這類
UCS-4 字元,並且 include zh-tw-chardefs.cti,
>>
它仍是使用者直接面對的中文台灣點字轉譯表。此時也會在
zh-tw.ctb
標註所建議之點顯器寬度,但是否生效也要看應用程式
(如 NVDA)
>> 採不採納建議了
>>
拆檔的目的,是保留彈性空間,如果有別的應用程式真的必須用
UCS-2 版本的 liblouis, 仍然可以只使用
>> zh-tw-chardefs.cti, 不會因為
zh-tw.ctb 加入了表情符號而變成無法相容於
UCS-2 版本的 liblouis
>>
>> 以上,不過如果 liblouis
開發者有其他建議,進行的內容仍可能改變
>> Thanks!
>>
>>   sincerely yours
>>    Bo-cheng Jhan
>>
>>
>>
>
>
>
>